Reducing development investment risk using human-centered validation

Developing software is costly. Managing many moving pieces involved is difficult; complexity is added by complicated environments, architecture, testing, coding, design, business needs, and stakeholders with less technological understanding. Additionally, business units and stakeholders have varying and shifting needs and priorities, creating significant investment risk for the organization. This article explains how to mitigate this risk at minimal cost through human-centric development.

First, we need to acknowledge something often overlooked; we develop digital solutions for outcomes, not output. The product is a means to an end. Defining and creating output (such as features) is straightforward but achieving outcomes— external factors which influence behavior changes in our target population— is more complex. Often, we see organizations celebrate releases and focus on velocity, prioritizing output.

Second, we must differentiate between business outcomes and user outcomes. The organization targets business outcomes—investing to gain new value such as increased revenue or reduced costs. The product targets user outcomes—the reasons users change their behavior and adopt it, like saving time or accessing information. Two dependencies emerge: the first being that the product helps achieve user outcomes, and the second being that user outcomes lead to business outcomes. Both create risk.

Mitigating this risk involves creating a process of continuous validation during development. Stakeholder bias often causes overconfidence in a solution, leading to skipping thorough validation, accepting risk, and necessitating costly rework if issues are discovered later. This validation, achievable through human-centric design, should be viewed as due diligence.

Moreover, validation need not be expensive; it should be fit-for-purpose and evolve throughout the development lifecycle. At the project's start, it might be more hypothetical (e.g., qualitative feedback on concept descriptions), becoming more concrete and detailed later (e.g., usability testing of detailed prototype screens). Each step enhances our user knowledge and confidence in the solution, reducing risk as investment grows.

Images by Lola Lorite 
Figure 1. Risk reduces as investment increases

Human-centric design validates user outcomes, but not business outcomes. For instance, a solution that makes users more efficient may not significantly reduce operating costs. Additionally, validation often relies on experiments approximating reality. There can be many reasons for positive experimental feedback, while real-world adoption might differ.

To confidently assess our solution, we must clearly define KPIs for both user and business outcomes, quantify them, and release our product to a target population as soon as possible, even if only to (internal) beta testers or early adopters. Real user interaction provides insights into the actual impact on user and business outcomes, further increasing confidence as investment continues.

Feedback during development is critical for informed decision-making and a basic requirement for Agile development, though many organizations falter with vague KPIs, lack of consistent measurement systems, and decisions not based on achievement of outcome. Many large, corporate organizations struggle with Agile. They plan roadmaps based on timelines rather than outcomes, contradicting Agile principles and posing investment risks.

Large corporates often adopt Scrum but make waterfall decisions, a logical response given their complexity and need for pre-planning and stakeholder buy-in. Scaled Agile frameworks (SAFe), though intended to address these issues, are often misapplied.

This not only risks building the wrong solution but also risks overinvestment in overly-refined features. While extra features can add value, their development cost may outweigh the benefits. Tracking business impact helps us assess the value of additional functionality and when a simpler solution could achieve business outcomes more efficiently and with a better ROI.

How can we achieve the advantages of Agile in the corporate landscape? We propose the "stepped waterfall" method—merging waterfall's clear objectives for organizational alignment, budgeting, and scheduling with Agile's iterative build/measure/learn cycle, de-risking focus, and flexible investment.

The initial step involves human-centric design to broadly outline the solution, validating real user needs through research and creating a concept validated by high-level prototyping to ensure value addition and facilitating stakeholder communication and decision-making. This needs to be fit-for-purpose, focusing on establishing and validating the solution’s direction rather than on details. This prevents investing in potentially irrelevant problems.

Key screens may serve as illustrations, but their content is provisional and subject to change. Incorporating these extra initial steps like research, concept development, prototyping, and validation by a small design team's effort over several weeks is cost-effective compared to later expenses and effort of having a full development team redo coded features to correct for skipping this relatively minor expense. 

This process results in a defined product goal. An example could be a "know your customer" (KYC) portal for financial institutions that centralizes communication and documentation for all involved parties, offering a single source of truth. A prototype guides the presentation of the future state to employees and stakeholders, and provides the basis for a rough timeline estimate. As this estimate is based on an approximation of the solution, it prevents unrealistic reliability expectations.

Images by Lola Lorite
Figure 2. Model steps in detail

Step 1: The validated prototype will define the direction

Following the prototype, we refine to a first value iteration, stripping unnecessary features but focusing on core value. In our example, this might be a centralized forum for KYC discussions and document sharing. This lean feature set is then designed in detail using human-centric design, reliably estimated, and developed in multiple sprints.

Step 2: The first iteration is defined and designed in detail only after it has been decided what it is.

After release, the feature is tested to assess its effectiveness towards our KPIs. In the example, we could try it with select clients and test whether it speeds up KYC processes and gather feedback on the solution. This feedback helps define the next iteration, focusing on already anticipated needs or new insights, guiding investment decisions.

Each iteration's feedback informs the next value addition, while keeping development aligned with the original vision. This makes it a staged decision process on whether to invest more in the project, on realistic and clearly defined timelines and budget estimates. If our original concept is correct, we will develop towards that through investment gates – but if there is any issue, the solution can be adjusted where needed, based on new insights. This approach minimizes wasted investment on non-essential features, allowing for strategic pivoting or pausing, based on value addition rather than striving for a perfect user experience (UX).

Step 3: The next iteration is defined and designed in detail after we have feedback on a previous iteration. This means we invest in solving problems that are relevant and validated only.

In our experience, the more common decision taken is to pause development and de-prioritize the current domain or feature. We often find that we’re already adding sufficient user value, removing the need for perfect product. Adding a future iteration would be nice to have, but is not critical. This allows us to focus on more pressing value-adds and pick up our next iteration at a later time, or in some cases, never again.

In our KYC portal case, an example could be digital document signing. While nice to have, the additional security development effort might not be worth it. Sufficient value could come from having all copies in one place (so all parties have visibility), but keep the signing of documents offline. The additional development would not significantly speed up the process, and an acceptable workaround is established. Adding digital document signing would be postponed, and considered on its own individual merit, rather than as a decision lumped in as part of a more general go/no-go.

This model blends design (research & validation) and development (Agile feedback loops) to drive user and business success, avoiding unnecessary feature investments that don't add significant value. It de-risks the development process by correlating risk reduction with thoughtful investment. Essentially, it encourages a mindset shift rather than significant additional costs, where extra spending directly lowers risk. This approach merges the strengths of waterfall and agile methodologies, emphasizing the importance of integrating design and development feedback.

 Contact us to learn more or discuss how we can support your business needs.