Our recipe for reducing risk of product failure - Mind the Product

Our recipe for reducing risk of product failure

BY Isabelle Berner and Katie Cladis ON SEPTEMBER 28, 2021

Agile product development is a learning mindset. It’s not about having all of the answers before you get started; it’s about optimizing and learning along the way, being able to change direction and respond to user needs, with a focus on delivering incrementally and prioritizing the work that will deliver the greatest value first. The (Def)inition Lab lays the groundwork for an agile project and is leveraged throughout the development process as the team identifies new user needs and determines the best solution to those needs. In this process, we align to outcomes and clarify our understanding of the most important user pains to address. Leveraging the scientific method, we validate potential solutions to de-risk the product and set priorities for iterative development.

I recently worked with a large property technology company with a feature set accumulating since the nineties. I spent weeks analyzing the features and entire products that had been built and looking at their usage data. Because the company never ran any sort of definition process before building a feature, over 40% of their feature set needed to be removed or heavily iterated on. This is a common pattern among companies who are unwilling, or unable to invest in product definition. Too often, companies build features and products that are not valued or adopted.

In this article, we will share the process that we use at Def Method to help our clients avoid this scenario and ensure that the products and features they build succeed.

Through software development, you can create real and meaningful change for your business or organization. Realizing that power, however, requires a strategy driven by a deep understanding and alignment around the product’s definition. A product’s definition encompasses the business outcomes to prioritize, the most important user pains to address, and a plan to develop the best product or features that will achieve these outcomes and address these pains.

The risks of failure with products

Software projects also carry significant risk; many products fail because they do not resonate with users, are not useful or usable, or do not effectively resolve users’ wants or pains. Nearly all failed projects have a common failure point: failing to identify and address key risks.

The function of the (Def)inition Lab is to identify and align on the client’s product definition: the features to build, the order in which to build them, and the initial milestones to hit to deliver value and mitigate risks as quickly as possible. At the end of the (Def)inition Lab, the client has honed in on the most important problems to solve first and tested solutions to that problem.

They have:

• Validated prototypes of a solution.

• A validated prototype is an important part of a product development process.  Once we have determined the user problem we want to solve, prototype validation gives the product team an opportunity to test and hone in on how to solve the problem. It’s a quick way to provide insights into how a user would interact with the product.

• A blueprint for their initial release.

• A blueprint for the initial release outlines the minimum set of features that should be included to provide value to users and the business, and also from which to learn. These challenging — but necessary — decisions and tradeoffs about what should be included ensure that your initial release creates an experience that is valuable, but also lean, and able to provide valuable learnings to inform future releases.

• A prioritized backlog ready for engineers.

• This short-term backlog represents a shared understanding of the scope and nature of each task to be done in development sprints. It includes a prioritized list of features, chores. and fixes, detailed in user stories (descriptions of features from user perspectives) that engineers can deliver incrementally. We follow the INVEST user story approach, which ensures each story can be shipped independently of others so there is no delay in learning from the working software.

• A user-centered strategic roadmap to guide development priorities moving forward.

• A roadmap is the visual representation of the client’s strategy. It puts the focus on outcomes and aligns the team and project with the product vision. It details the most important outcomes, the features to achieve these outcomes, and success criteria so the team can decide whether a feature requires iteration, maintenance, or sunsetting.

This process is run by a product manager, designer, and engineer, with the support and participation of the client subject matter experts and stakeholders. When applied at a project’s start, the (Def)inition Lab typically takes 3-5 weeks. If development has started, we apply select parts of the (Def)inition Lab process in parallel to development work to ensure the team continues to deliver value to users and the business.

The (Def)inition Lab includes three phases:

• Define opportunities
• Define solutions
• Define validation

An overview of the (Def)inition Lab phases, as described below: “define opportunities,” “define solutions,” and “define validation.”

Let’s take a closer look at each phase, and see how you might apply them to your product definition journey.

Phase 1: Define opportunities

During the “define opportunities” phase, we identify the most important user pains, prioritize desired outcomes, and look to understand the engineering constraints.

Prioritize outcomes

A project always starts with the desired outcome — a change in human behavior that, if reached, would create value for the business. Examples of desired outcomes include things like increasing conversion, retention, or referral rate. With many potential market opportunities, the team must first align on which outcome is priority, usually, the opportunity will drive the greatest immediate value for the business. While there may be many outcomes or objectives that are valuable for someday, the focus here is on moving the needle for the single outcome with the greatest impact potential.

Develop context

Through stakeholder and user interviews, we synthesize an understanding of current user pain points and business challenges. We map out the users’ context and journey, connecting pain points to experience points throughout their engagement with the product. A deep understanding of the status quo allows us to identify adjacent opportunities and enables the team to connect with users and build empathy, imperative to identifying and validating a solution that will be well-used and valued. Through research-driven insights, we surface the most important user pains, needs, or wants; those that, if addressed, will most effectively drive the business’s priority outcome.

Understand engineering constraints

In parallel, we study the engineering context and constraints, laying foundations for technical input into solution directions. By identifying important factors like data availability, architectural considerations, existing functionality, and more, we become better equipped to define the best possible solutions (Phase 2), because we have the space to reflect on and consider our technical strengths and limitations.

Phase 2: Define solutions

During the “define solutions” phase, we use brainstorming and design thinking tactics to identify promising solutions. Then, we refine the solutions until we are satisfied, and develop research and experimentation methodologies to test and strengthen the solution.

Ideate solutions

Through brainstorming and design thinking tactics, the team identifies promising solutions to address the previously identified user pains, needs, and wants. A solution could be a feature or collection of features, a fully realized product, or a database/spreadsheet. The (Def)inition Lab’s ideation tactics leverage visualization and are time-bound to drive creativity and force discussion. Ideation is a collaborative journey; where we aspire to explore problem and solution spaces together, building shared context through exercises in seeking the unknown. This process is challenging; it is uncomfortable to sit in the space of not knowing, but our deep understanding of the problem, of user pain, and of business challenges will ultimately lead to testable solutions.

Refine solutions

Just as the user pains we pursue are focused on the prioritized outcome, the associated solutions we pursue are focused on addressing the user pains. We consider technical realities, striving for feasibility and simplicity in the solution we choose to pursue. We take the leading solution concept and iterate on it until we are satisfied that it is technically feasible and likely to meet priority business outcomes while addressing top user pains. Next, we identify risks and assumptions, and we develop research and experimentation methodologies to test and strengthen the solution’s ultimate value and impact.

Phase 3: Define validation

During the “define validation” phase, we validate our refined solution through experimentation.

Test solutions

Before investing in development, we validate our refined solution through experimentation, a process where we seek initial evidence that we’ve identified valuable solutions. We develop a hypothesis that defines how we will support or reject our potential solution and lay out a set of assumptions to be validated for the solution to succeed. Testing in the Product (Def)inition Lab might involve lightweight prototypes or additional user interviews. For an existing product, we may experiment with “wizard of oz” features — rudimentary prototypes tested with role-playing scenarios — or “fake door” click tests designed to gauge interest in features before they are built, giving us quantitative support for whether to build a particular feature. If validation succeeds, we create additional plans to evolve the solution, and if the data does not support our hypothesis, the solution is varied and re-tested or possibly abandoned while we test other identified solutions that support our priority outcome. Invalidating concepts is a critically valuable part of the process; we save time and development resources by identifying dead ends early.

Prioritize solutions

In order to learn from working software early and often, we ship small, valued features to users frequently, getting input from them with each release. In the (Def)inition Lab, we identify the known factors and clarify the unknown, making a plan for how and what we will learn along the way. We use this phase to plan for incremental learning throughout development. To ground ourselves in the important roadmap milestones, we investigate the current infrastructure and review all remaining assumptions that can only be assessed through shipping working software to users. We answer:

• What assumptions kill the product if we get them wrong? What do we have the least evidence of?
• What decisions will be reversible? What will need extreme diligence?
• For existing products, what parts of the existing system can be salvaged?
• For brand new products, which technology stack is most appropriate?

High (Def)inition

At the end of the (Def)inition Lab, the team is aligned on a path forward, having developed and tested a lean, incremental, and iterative development plan for continually shipping thin slices of value until we have achieved the priority outcome and alleviated the priority user pains. The client and team deeply understand the users and the business’s core challenges. The client has honed in on the most important problems to solve first and has tested solutions; the first thing the client builds will have a higher likelihood of resonating with users. The client has a product roadmap and prioritized backlog so that their engineers, designers, and product managers can build with confidence.

Whether you’re building a product from scratch or trying to figure out the next most critical thing to build for your existing product, Def Method’s (Def)inition Lab can help. Contact us if you’d like to work together, or book a free product consult for advice on how to structure your own (Def)inition Lab process.

Discover more content on Product Development Process.