Some of the top reasons many startups fail are due to their inability to find sufficient funds, poor targeting or lack of quality research. Minimum Viable Products (MVPs) are the way to eliminate many of the risks before betting all the money on a healthcare product with an unclear outcome. It’s a step right between a prototype and a finished product. MVPs allow businesses to prepare a basic product fast with a few core features to be used by users. It will allow gathering early user feedback and using this basic software as a carcass for a future larger product.
Building a healthcare MVP adheres to a similar pattern as building any MVP, however, there are certain unique aspects present in this sector. There are also several common but critical mistakes healthcare companies make while building an MVP. We will discuss these below and how to avoid them pitfalls.
Healthcare MVP process
The whole MVP development process is relatively short, compared to full cycle of software development. Since the MVP’s purpose is to deliver the basic product to the customer quickly, tight deadlines and simplified approaches often take place. Any MVP bigger than a “two-button app”, the whole development can take anywhere from 2 to 9 months without any preparation. However, when some of the parts are done prior, it can take much shorter. It’s important to estimate the scope of the work correctly and do research. Healthcare MVP development also consists of 5 steps, which we will talk about in detail just below.
First things first, the MVP should be usable and well-architect in terms of security and data. The very base of a good MVP is great architecture, accessible design, security of data, clear logic of integration with EHR/EMR systems, but also a clear vision for what you are trying to achieve with your platform.
Research is the fundamental step to understanding how to achieve that. It will help you map the target audience, understand their problems and how your product will address them. It’s advisable to monitor the healthcare market and possible competitors for insights.
It’s also a good idea to have those compared to the products that the healthcare market already has. Maybe you want to create a modern voice bot but discover there are lots of successful health voice bots out there, and your niche lies somewhere else.
Since we’re talking about healthcare, there is one last thing to gather: your healthcare requirements. Compliance with HIPAA, healthcare privacy rules (for instance, CCPA and HITECH in US, PIPEDA and others in Canada, Data Protection Act of 1988 in the UK, GDPR and public health regulations in EU), healthcare application laws are indispensable to get a hold of before building a product for this market.
COMMON MISTAKE in this phase and TIP to overcome
The first common mistake made by many healthcare companies is not knowing the true problem and how to solve that problem. MVP development is NOT market research. One should first do their market analysis as well as cost to value comparisons before even beginning the MVP development process. One does not have to write finalized requirements but one must understand who the users’ will be why will they want to use the solution being developed, and what are the MOST BASIC functionality the users’ will find as game changer. Without such preparation by the business / product team, MVP development will drag on and cost far more than palatable. Unless you already have in-house Product Owner, hire or recruit an experienced Product Owner with expertise in healthcare industry product development full life-cycle. A CEO or business owner may feel he/she is an expert in their company but that does not equate to expertise in Product Development life-cycle skills.
Clinical, patient, management, or other workflows in healthcare are created to visualize how a user experiences the app or a process your app is supposed to augment. By understanding the full path, from thought to final objective, from patient to EHR (Electronic Healthcare Records), or from hospital to the app, you can foresee the possible difficulties they face and create a solution that addresses those. A neat diagram for representation of this journey often works best. Later, it can be used for back-end development and as a point of reference for why certain decisions are made.
A neat diagram for representation of this journey often works best. Later, it can be used for back-end development and as a point of reference for why certain decisions are made.
Define KPIs (key performance indicators) for your MVP, once launched, what performance indicators will you use to assess the success of your MPV. Your KPIs could include adoption rate, user feedback for each functionality, quality of user journey, how quickly a function is meeting the users’ needs, etc.
COMMON MISTAKE in this phase and TIP to overcome
Such diagram should be done by a seasoned and trained Business Analyst with feedback from Product Owner and other stakeholders including Technical Architects. Diagramming a journey requires several levels of vocational expertise that not just anyone without proper training can pull off. Mistakes and oversights in this critical artifact can lead to significant errors in fundamentals of design and implementation of an MVP resulting in delays and cost overruns.
All the previous research and understanding should have resulted in a clearer idea about what should be the core of the MVP.
Your final product may have large functionality, but you need to find the minimum possible features that you can go into MVP production with. On the one hand, comes the understanding of the product’s main value, meaning its business component. On the other hand, it is necessary to understand the development scope – what features can be implemented in the shortest possible time, what should be the starting functional, security, and data architecture for fast scaling.
Maybe you thought of building a great all-round healthcare AI (Artificial Intelligence) with text, voice and face recognition, but the majority of your customers are interested in a voice-bot now. Here’s your must-have. Or you wanted to develop a platform for a new government health program with finance management, numerous payment options and year-round support, but your clients would mostly like a well-made calculator for the benefits they get each year. That’s what you should focus on.
Clearly dividing the must-have, and nice-to-have, features in relation to your budget, customers and competition will get you a long way.
COMMON MISTAKE in this phase and TIP to overcome
Business leaders all too often fall in the trap of ‘biting too big of a bite’ in this stage. Most commonly, mistake is made by business leaders deciding what the customers want now vs. making a data driven decision through actual target customer feedback. Gathering actual customer feedback on their immediate needs is a must during research and understanding phase. MVP built on such data driven knowledge will ensure fast adoption and candid feedback from actual users.
MVP is often a relatively short project. Its purpose is to attract customers through its usability and appeal, but also solve their immediate problems. A Healthcare MVP sits neatly at a balance scale, don’t overload it with extra elements and data, but perfect it.
For the development process, choose the best pragmatic tech stack for scaling, think about integrations design (with EHR/EMR, laboratories, pre-existing hospital systems, etc.), look for the best security-compliant architecture that suits you. Depending on the complexity of the software, it might also be a good idea to create UX wire-frames.
COMMON MISTAKE in this phase and TIP to overcome
Select well supported libraries as well libraries that are proven to be secure. Give thought around internal technical skill-set in your company or readily and easily available technical skills in the market before selecting tech stack. An obscure or new tech stack will open you up to much consternation in adoption, supportability, cybersecurity and ultimately slow down scalability or expose you to cyber attacks. Using the most fashionable tech stack of the time or tech stack that has the industry buzz words, if it doesn’t fit the your initiative and company pragmatically; is not the right approach in any circumstance.
Build your MVP with scalability and security in mind. After all, this is a product to be expanded upon later and yet needs to absolutely secure any PHI or PII information.
- Back-end and data development. Raw data is at the core of every application, so building data lakes, clouds, servers are essentially step one in the back-end. These will provide a place for storage for raw but also processed information, to ensure secure data flow through levels of protection. Tools for cleaning, duplication removing and enhancing data are built at this stage too. APIs will help in other health services, apps, data sources integrations. Data processing and BI implement business logic to be presented by front-end tools.
- Front-end development and visualization. To ensure proper communication with the server, as well as usability, front-end development uses both tech and design in order to best present the software for its intended users. Depending on your product, you may want to plan the customer journey with user frustration in mind. At times, solutions are unconventional or even revolutionary. Provide the necessary materials for the first users (like a user book or another type of guidance) and allow them to ask questions through contacting the user support quickly and getting the answers they need.
- Testing. Continuous testing is a must throughout the process. Testing should be done not just of the application functionality but also as importantly the security protection of the information.
It’s now the right time to get lots of feedback about the MVP, ask users, be it patients or doctors. Measure effectiveness with predefined KPIs. Show the product to investors. Whatever works for your specific solution? Overall, get it out as much as possible. Measuring your success and, probably more importantly, things that need improvement is crucial for business and further development process.
COMMON MISTAKE in this phase and TIP to overcome
A common mistake made my healthcare companies in this phase involves concluding that MVP is unsuccessful if the volume of user feedback are negative is larger than positive. In fact negative user feedback are more valuable for an MVP as it shows the users are interacting with it often enough, and care enough about your MVP that they are providing feedback to make it better. Though positive feedback is good for morale, the negative feedback will ensure continued refinement and growth of your MVP.
Improving will require rapid cycle to change and therefore you will need to ensure your initial users have the correct expectation to need to see rapid changes that happen often. Users who are uncomfortable with frequent changes in your MVP may not be the ideal initial user base.