![\"\"](\"https:\/\/www.clinipower.fi\/wp-content\/uploads\/2022\/01\/Innovation-process-1-1024x249.png\")
<\/figure><\/div>\n\n\n\nUnfortunately for a lot of companies it does. Journey of bringing a product idea to actual product release is a rollercoaster of enthusiasm and frustration (and occasional despair). There are some innovation rock stars who advocate complete freedom of ideation over processes. A star from the past – Pablo Picasso himself said: \u201cLearn the rules like a pro, so you can break them like an artist.\u201d<\/p>\n\n\n\n
However, there are steps and checkpoints which are critical to ensure that medical device innovation succeeds. This applies to startups as well as corporates.<\/strong><\/p>\n\n\n\n A lot of our customers have a challenge: “We have developed a product innovation <\/span>[insert idea here<\/em>]<\/span> and we need to do get a CE certificate to get our product released in [select 3 months or 6 months<\/em>]<\/span>. Help us do the documentation.”<\/p>\n\n\n\n In addition to all the regulatory and patient safety load (like: Have you analyzed patient risk? Is the clinical evaluation done? Is product proven to be safe and easy to use?), there are often other unanswered questions like: How does the product\u2019s intended use and device classification position the product, or impact its time to release? In which countries will the product be released first and how does the distribution channel and regulatory landscape look there? Does the product contain sensitive patient data, and is it handled safely? And above all: Would the early adopters love the product?<\/strong><\/p>\n\n\n\n Most of these questions could be answered before a single piece of code is written. A lot of these questions have significant impact to the product development, time to market, and overall, health of the business case: Does the product excel or fail?<\/strong><\/p>\n\n\n\n So why not clarify these questions early on?<\/strong><\/p>\n\n\n\n We at Clinipower have modelled the journey of a health tech innovation MVP<\/a>-version (Minimum Viable Product) from an idea to market.<\/strong> We call it the “health tech innovation cone”. It adapts the key concepts of lean startup<\/a>, design thinking<\/a> and design control<\/a> required for medical devices.<\/p>\n\n\n\n Front End Innovation<\/a>, which refers here to the upper part of the cone, is where product ideas, their feasibility, viability, and fit to company strategy are explored. After getting adequate assurance on the product idea and its market fit, the program, product, and business planning are further defined to start the actual Product realization phase. This phase is also the time where the regulated structure and design control kicks in. After product release, Post-market surveillance<\/a> is performed for continuous product strategy alignment and ensuring patient and user safety.<\/p>\n\n\n\n In this article we discuss three phases (or mindsets) of the front end innovation in health tech \u2013 here\u2019s how we see it:<\/p>\n\n\n\n Our earlier innovation article Medical device innovation \u2013 a combination of imagination and safety<\/a> described that in terms of an innovation, the customer need and supply should meet, creating value to its stakeholders.<\/p>\n\n\n\n According to our experience it\u2019s not uncommon to start solving an unimportant problem. This means that the supply would be there, but the need is not big enough, or timing does not fit the target market\u2019s healthcare ecosystem. Ideally this is figured out early in the game. At worst, the lesson is learned after product release.<\/p>\n\n\n\n This trap can be avoided by getting an understanding about the target market, customers, and key stakeholders early on. Who would be the early adopters, what motivates them, and are they able to invest in purchasing the solution? Tools to figure this out include initial market research, interviews, surveys, information from competitor products and overall technology use \u2013 just to name few. People are generally lacking the capability to forecast their future behaviors<\/a>, for example in terms of novel product ideas. Thus, the collected data needs to be carefully analyzed for the underlying root causes, behaviors, and trends.<\/p>\n\n\n\n “A problem well stated is a problem half solved.”<\/p>Charles Kettering<\/cite><\/blockquote>\n\n\n\n OK \u2013 so let\u2019s say that the need is there, and from customer perspective the challenge is painful enough for solving. Does this mean a \u201cGO\u201d decision for a product design? Not necessarily \u2013 as we still don\u2019t know would the customers actually buy a product that solves the customer challenge. Getting the above understanding is important in health tech solutions as live experiments cannot be run with lean startup\u2019s build-measure-learn loop<\/a>. In medical device business, these trials can be done by usability tests, clinical trials, and of course after release in actual use. In case of B-to-C products, it\u2019s also possible to confirm the demand by testing value propositions and statements through social media campaigns and calculate click rates, subscribers, or cold call success rates. Purpose is to get enough in-depth insights about customer needs and habits, and ideally actual statistical data about interests. All the above can be done before making a single code for prototypes.<\/p>\n\n\n\n At the end of the Opportunity development<\/em> phase, you should have identified the opportunity or opportunities for an innovation with understanding of magnitude, assumptions, and risks. There should also be some validation of the assumptions.<\/strong><\/p>\n\n\n\n Especially for startups there is pressure to showcase the value of investment by getting a working prototype done fast for funding purposes. It makes sense.<\/p>\n\n\n\n However, what if your product prototype misses out some patient safety considerations which drive device classification and safety measures, if found later, again prolonging your time to market by a year? Or if your prototype actually, well, sucks?<\/p>\n\n\n\n We encourage generating a lot of solution ideas, narrowing them down to few alternatives that best address the opportunity, prototyping fast and light, and validating the customer impact and feasibility with end users and other stakeholders. Finally, iterate this process until you have enough assurance that your idea has a valid chance to fly within health tech regulations, markets, and business culture.<\/p>\n\n\n\n Prototypes are tools for experimenting and should be built to explore assumptions related to solutions.<\/strong> Assumptions can be related for example to following aspects: 1) is there enough value for customers and stakeholders, 2) is technical feasibility of the solution known, 3) is the product amazing to use, or on the other hand, 4) is there a need to impress investors for next funding round. In the examples above, the second (and partly the last) requires a working prototype. However, in all examples the first set of experiments can be made by confirming hypotheses (asking questions like \u201cHow do you think solution like x would impact your daily work\u201d) or by smoke and mirrors.<\/p>\n\n\n\n One of the best lessons we’ve had happened during usability testing and interviewing a senior thought-leader physician about healthcare IT system\u2019s prescription module. We built a paper-like prototype in few hours to explore design directions. During the 1,5-hour usability test and related interview we understood which parts in the design concept are worth saving and which can be happily scrapped before spending any more effort, we convinced the customer about product strategy, and as an extra, got buy-in and continuous partnership with the customer. Not bad for a couple hours of work!<\/p>\n\n\n\n Outcome of the Solution creation<\/em> phase is that you have a feasible solution candidate accompanied with a business plan. Both the solution candidate and the business plan are validated with customers and key stakeholders.<\/strong><\/p>\n\n\n\n Yes, you are.<\/strong> However, when you are still exploring variety of different product and\/or business model concepts, you probably want to just pick the relevant aspects of regulatory strategy and DevOps<\/a>. They should be applied to impact the product vision and development timeline, and speed up the exploration – rather than go all-in. As an example, like mentioned in our previous article about usability testing<\/a>, it makes sense to plan feasibility and viability exploration activities carefully and take design control -documentation credit for example from early product usability tests.<\/p>\n\n\n\n When product and business idea maturity and feasibility are on adequate level, and the adequacy is confirmed by customer and stakeholder evaluations, it makes sense to start phasing down the explorations and start executing. This means putting rigor on the team setup, development practices, tooling, plans for risk management, clinical evaluation, usability, and rest of the things you need when starting to realize the product. This is one of the Design Input reviews also required for medical devices.<\/p>\n\n\n\n At this point, you should also have your market strategy at such level that you can start executing it. Don\u2019t wait too long: Remember that things will never be perfect, especially not if you prevent exposing your product to customers!<\/p>\n\n\n\n Goal for the Design and plan<\/em> phase is that your team has adequate clarity to start development. It\u2019s not a design freeze, but rather a program level agreement on practicalities, high level requirements, and design which enables continuing the incremental and detailed feature definition and development.<\/strong><\/p>\n\n\n\n Activities mentioned above require variety of skills.<\/strong> Already at the front end innovation phase (upper part of the cone \u2013 as a reminder) you need different views for example from subject matter experts, technology, business, product design, and regulatory.<\/p>\n\n\n\n Especially when dealing with disruptive innovations, figuring out the healthcare partners early on is important. Finding thought leaders smooths the way for clinical trial (if needed) in credible organizations, which again eases getting necessary proof for clinical impact.<\/p>\n\n\n\n You should consider whether to build, borrow, or buy<\/a> the resources. Teaming up with partners who have \u201cwalked the walk\u201d in the health tech saves time and money. Small companies or newcomers to health tech often don\u2019t have the resources, time or will to hire or grow full stack, full-time in-house health tech team immediately from the start.<\/p>\n\n\n\n One size does not fit all, and every model is a simplification of a reality. Application of Opportunity development, Solution creation, and Design and planning depends on the budget, number of knowns and unknowns, product, organization, state of the project, and foreseeable risks – just to name few.<\/p>\n\n\n\n As an example, an agile team already running product development would run small incremental explorations to detail out new potential features (\u201cmini-cones\u201d, if you will) during their day\u2013to-day feature clarification activities. Corporate running innovation and planning iterations<\/a> or innovation teams outside of customer committed product development would mostly concentrate on Opportunity development and Solution creation. Different teams would pull the working ideas to production after management buy in.<\/p>\n\n\n\n Sometimes for easy incremental add-on to existing product and market strategy, a 15-minute gut check of the underlying problem and concept might be enough before proceeding to design it further. If you have a novel product concept, and you are uncertain about the product-market fit, it makes sense to do a \u201cbigger gut check\u201d.<\/p>\n\n\n\n There are also tools to speed up the process. We are fans of Design Sprints<\/a> to build an evaluated initial paper-, Powerpoint-, or Figma<\/a><\/strong>–prototype from the problem statement within a week.<\/strong><\/p>\n\n\n\n Regardless of your phase, it\u2019s important to identify gatekeeping and success criteria also to front end innovation phase, so that decision to go forward, iterate, pivot, or exit is data-based, rather than feeling-based. Sometimes the best outcome during the research is to kill the project due to discovering lack of demand and spend the freed-up resources elsewhere.<\/p>\n\n\n\n This was a high-level view of our \u201cinnovation cone\u201d. Our next innovation themed article explores the opportunity development from business model perspective.<\/p>\n\n\n\n If you have any comments, questions, or need help in getting your innovation forward, let us know<\/a>.<\/p>\n\n\n\nStart early<\/h2>\n\n\n\n
Front end innovation<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.clinipower.fi\/wp-content\/uploads\/2022\/01\/Innovation-Cone-1-895x1024.png\")
<\/figure><\/div>\n\n\n\n1. Opportunity development – Understand the problem and ecosystem around a solution<\/h2>\n\n\n\n
2. Solution creation – Use experiments to validate assumptions<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.clinipower.fi\/wp-content\/uploads\/2022\/01\/Concept-creation-funnel.png\")
<\/figure><\/div>\n\n\n\nPrototypes don’t need to be pretty<\/h3>\n\n\n\n
3. Design and plan – But I am doing it all the time?<\/h2>\n\n\n\n
Team is the key<\/h2>\n\n\n\n
![\"Team](\"https:\/\/www.clinipower.fi\/wp-content\/uploads\/2022\/01\/Team-is-the-key-1024x443.jpg\")
<\/figure><\/div>\n\n\n\nTakeaways<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.clinipower.fi\/wp-content\/uploads\/2022\/01\/Kenka-small-1024x475.png\")
<\/figure>\n\n\n\nGot interested?<\/h2>\n\n\n\n