Keywords:
By Yves Wurmitzer
From top global instrument makers to smaller startups, life science companies face a challenge when developing and launching new IVD products in a fast-paced market. How do you create a product that meets market needs without overdeveloping it? You want a development effort that keeps costs in a profitable range while still delivering value to your customers. And you want to launch your new product within a window of time that makes it unique on the market.
Finding this balance is often the goal for instrument makers in order to get a product to market quickly enough. Pairing speed to market with a unique value proposition is the key and may be best achieved using an iterative approach to product development. Your product launch success may rely on understanding what the minimal viable product for your market is.
When launching a new automation product, taking an iterative approach with prototypes and betas can help you develop a minimal viable product (MVP) that expands gracefully with future updates.
What is a minimal viable product (MVP)?
A minimum viable product (MVP) is a concept from the Lean Startup methodology that focuses on the idea of including customer input from actual product usage into the product development process. Eric Ries, author of the Lean Startup methodology, defined MVP as:
A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The idea behind MVP is that you produce a version of your actual product that lets you observe customer behavior and get feedback on usage. Understanding how people would actually use the product is more reliable than just asking them what they might want a product to do.
Why would you want to do this?
Some reasons to start with a MVP include:
- So you don’t invest more in product development than you need to or add features that customers will never use
- So that you focus on solving actual problems customers have, and not just those you think might be interesting
- So you can get into the market place faster and gain a customer base that will look to you for new solutions
- So you can fill a market hole either where competitors don’t exist, or where they are not meeting customer needs adequately
What does MVP mean in an IVD environment?
The term MVP can be misleading, and it is important that you don’t just look at the “minimum” part of this equation, but also remember the “viable” part, as well. For an IVD product, it can help to break viability down into several categories. Your solution has to be viable in every one of these areas:
- Functionality – it fulfills the purpose that the user expects it to
- Reliability – it operates in a way that produces repeatable, trust-worthy results
- Usability – it’s easy to use and minimizes the chances of user errors
- Appeal – it’s designed in a way that users like to use it
- Value – its purpose fits the market, solves a user need and has a value that people are willing to pay for
- Compliance – it fulfills regulatory requirements
Preventing failures
If a product is not viable in one of these areas, it will fail even if it is viable or exceeding expectations in others. Some typical reasons products fail are:
Failing to understand user needs. Not knowing exactly who the product users are, how they work and what they need leads to ill-conceived products.
Failing to offer value. The product does not fit the market (for example: cost of ownership is too high, throughput not offered, degree of automation not appropriate, or process security is lacking).
Failing to outperform competition. The product is not as good or better than what’s already out there.
Read more: Why IVD product launches fail
But how can you judge what viability means in those categories? When is a product good enough?
Take an iterative approach
If you only start gathering feedback once your MVP is out in the market you are too late, as changes in launched IVD instruments are costly (remember the MVP is a sellable product). Therefore, it can be beneficial to work with internal or partial products first to gather feedback and improve until you know what the MVP should look like. Try to eliminate all your risky assumptions and replace them with validated hypotheses before you embark on a development project.
For example:
- To assess performance and functionality -> build prototypes
- For usability and appeal -> use 3D prints and mockups
- For market fit and differentiation -> conduct voice of customer studies
Each of those examples can be treated as partial or internal products and should be iterated and improved until you are confident that you know how the MVP product should look. Replace uncertainty with clarity on what it means for your product to be good enough.
It is only good enough if you can make it great
It is important to remember that developing an MVP is just the first step on a journey where you bring your product from “good enough” to great.
Many improvements on your product roadmap will be shaped by the feedback of your customers and the market response to the product. To accommodate features that were originally not anticipated, you need a system architecture that is:
Modular – You might need to remove existing features and replace them with others in the future (for example you might change from manual scanning of barcodes to an automated scanning)
Extendable – Adding new features or extending old ones should be easy (for example, you may start with a partially automated workflow and extend to full automation later, or start with an offline solution and add connectivity features)
As added benefit, a modular and extendable system architecture with clear interfaces can also improve testability and reduce documentation effort, making the product journey from good enough to great easier.
In summary:
When launching a new automation product, it is important to use iterations with prototypes and betas to learn what the minimal viable product looks like. After launching your MVP, you can expand the options and features offered in future versions based on market feedback. Choosing a modular system architecture that allows extensions without rework will make this process go more smoothly.
The right OEM partner can support this journey with products and expertise.
Through the Tecan Synergence™ program, you gain access to requirements engineering and expert consulting to help you shape your product using an iterative MVP approach. You might start with off-the-shelf products, transition to custom prototypes and finally to an OEM product.
Tecan offers a range of robust, reliable products to support your automation needs, along with flexible, modular hardware designed for future growth, such as Tecan Cavro® Magni Flex, and software, such as Tecan MAPlinx™. You can confidently launch a product using these modules that meet your market needs today and be ready for the needs of tomorrow.
If you’re considering outsourcing your next lab automation solution, there are a number of aspects to assess before starting a project with an OEM partner. To make sure you've got everything covered, download our complimentary self-assessment checklist.
About the author
Yves Wurmitzer
Yves Wurmitzer is a Customer Solution Development Manager at Tecan, Switzerland. He works intimately with OEM clients and end-users alike obtaining and clarifying their needs and market demands to enable the successful development of new cutting edge solutions. Yves has many years of experience in product and project management of OEM liquid handling automation with a key focus on innovative software solutions. Yves holds an MSc in Biology of the ETH Zurich and joined Tecan in 2016.