Don't be trapped by your Healthtech Roadmap

What do a bunch of health tech companies I’ve examined over the past few years have in common? Quite a lot in fact. But one things sticks out – neat quarterly boxes filled with feature names, integration milestones, and platform expansion plans. They’re beautiful documents that bear no resemblance to reality. In other words ‘Roadmaps’.

Healthcare doesn’t follow software timelines. Regulatory approvals get delayed. Clinical studies produce unexpected results. Reimbursement policies change overnight. User behaviour shifts based on external health events (COVID). Yet we keep building roadmaps as if health tech operates in a predictable environment. I could argue that roadmaps in general exist as exercises in controlled fiction offering certainty in a world that rarely cooperates.

Why Health Tech Is Different

Traditional software can iterate rapidly because the cost of being wrong is usually low. Ship a buggy social media feature? Users complain but keep scrolling. I noticed recently for example that there was no difference in the CTA for Follow or Following on Instagram discovery pages. I couldn’t believe that such an oversight had made it into production – albeit a relatively minor issue. But it didn’t matter. Ship a buggy medication reminder? People miss doses and end up in emergency rooms.

This fundamental difference demands a different approach to product strategy:

• Validation cycles must include clinical outcomes, not just user engagement
• Regulatory requirements change faster than development cycles
• User behaviour varies dramatically based on health status
• Integration dependencies are controlled by external organisations with different priorities

The Alternative: Health-First Product Strategy

Instead of roadmaps, successful health tech product leaders are building what I call “Health Impact Frameworks” – these are dynamic strategies that prioritise patient outcomes over feature delivery. This means potential pivots early, pivoting and responding – not to mention suddenly dedicating resource to something that cannot be left alone for whatever reason (safety, incoming headwinds of a competitor for example).

The Three-Horizon Approach:

Horizon 1 (0-6 months): Behaviour Validation Don’t plan features, plan behaviour change experiments. Each experiment should test a specific hypothesis about patient behaviour and measure clinical outcomes, not product metrics.

Example: Instead of “Build medication adherence dashboard,” test “Can SMS reminders at optimal timing increase adherence by 15% for Type 2 diabetes patients?”

Horizon 2 (6-18 months): System Integration Focus on embedding your proven behaviour changes into existing care workflows. This isn’t about API connections, it’s about changing how healthcare providers work. I see this a lot in the NHS and believe there is a ton of work to be done to get more efficient patient outcomes delivered.

I see successful companies who try to partner with the NHS deliver their own outcomes within the creaking tech architecture of the NHS rather than trying to deeply integrate with it. This means that if you’re an external provider then think about how you can change doctors, nurses or other healthcare workers’ behaviour and how they do their daily jobs. If you build an app that helped diabetic patients remember to take their meds don’t try to send data to the doctor’s existing system. Change the doctor’s routine so they use the app insights to take action.

Horizon 3 (18+ months): Market Expansion Only after proving behaviour change and workflow integration should you consider scaling to new conditions, populations, or markets.

The CPO Mindset Shift

This approach requires fundamentally different skills from traditional product management:

1. Think like a behavioural scientist, not a feature factory. Your job is to understand what drives sustained health behaviour change.
2. Measure like a clinician, not a growth hacker. MAU means nothing if patients aren’t healthier. Focus on clinical endpoints.
3. Plan like an emergency room, not a software company. Build systems that adapt quickly to changing patient needs. And communicate this need to the team, allow for pivots.
4. Partner like a healthcare provider, not a tech company. Your stakeholders include patients, families, doctors, and insurers each with different success metrics.

The Practical Framework

Replace quarterly planning with monthly health outcome reviews. Ask these questions:

• Which patient behaviours changed in measurable ways?
• What clinical outcomes improved (or didn’t)?
• Which healthcare providers changed their workflows?
• What external factors affected our results?

Use those answers to adjust your next month’s experiments, not to update a roadmap that assumes predictability in an unpredictable industry. And remember, there are varying levels of success. You might first need to use your product to enact habit changes in lifestyles in your patients. Only then for example might you see real world PATIENT fed-back changes in their condition or initial problem. It’s nuanced and complex – act accordingly! And remember, would you rather save a few lives than deliver a product that reaches 10 million users but does nothing.