Faster Feedback Before Development Starts: Feasibility

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

While change, new discovery and learning are inevitable during any healthcare app product development process, and agile processes reduce the cost and risk of change, there is a significant cost associated with design controls for development, whether you are using agile methods or not.

In a typical product development cycle, a high-level product concept or set of new features is given to an R&D organization, which defines detailed requirements and specifications before development begins.

There is still a lot of risk during this stage*:

• Requirements Risk – the risk of extraneous, missing, or incorrect requirements and features
• Design Risk – the risk that features are designed in a way that does not meet user needs or is not easy for them to use or understand
• Technical Risk – such as the risk of architectural decisions, new technologies or algorithms, integration with underlying platforms, devices/sensors or third party software.
• Patient Risk – (caused by human factors, technical or other types of risk)
• Solution Risk – the risk that the product doesn’t meet its intended use, or is not effective.

If you generate requirements and specifications without discovering and mitigating these risks, you will probably be building on invalid assumptions and either make major changes during development, or compromise on product features and quality in order to make deadlines.

An agile/lean approach during this phase would spell out hypotheses and use fast feedback loops (“build-measure-learn loops”) to validate or invalidate those hypotheses, thereby dramatically reducing risk much more quickly and cost effectively than during full development. In agile, experiments that involve building something in order to reduce uncertainty are called spikes. Two types of spikes are typically employed:

• Functional Spikes are used when there is significant uncertainty as to how a user might interact with the system. This typically involves rapid prototyping – starting with low fidelity prototypes and moving up to higher fidelity prototypes allows you to get feedback from stakeholders and actual users and iteratively refine requirements and design, thereby rapidly driving down requirements risk and design risk, as well as human factors areas of patient risk.
• Technical Spikes are used to determine feasibility and impact of various technical approaches in the solution domain. Example uses include determining build vs. buy, performance or load impact of a new story, evaluating specific implementation technologies, or issues regarding integration with external hardware or software.

Just as with prototyping, technical spikes typically involve building just enough to validate or invalidate hypotheses, rather than building something that can be re-used and incorporated in the development process. For high risk areas, this saves significant amounts of time and money by avoiding costly rework under full design controls.

Just as agile development benefits tremendously from having cross-functional teams participating throughout the process, so do research and development efforts involving functional and technical spikes. Risk analysis should be done at an early stage, and functional and technical spikes can be used to discover and mitigate patient risk – the results can be used to iteratively build the risk file and improve risk mitigation. Similarly, technical and architectural feedback is important during the prototyping process – without it, you are likely to end up with designs that are more costly and time consuming to implement.

* In this discussion, I use risk more broadly here to include not just patient risk, but all risks to product effectiveness.