e47 Discovery is more than user research

When working on a new opportunity, the first thing a product team needs to do is make some decisions about how they are going to solve it. Most probably, they won’t have all the information readily available, and they would need to spend a bit of time learning and understanding—that is, doing discovery. Designers are often expected to drive this process, and their usual reaction is to focus on user research. But it’s important to realize that discovery is more than that.

Photo by Amin on Unsplash

☕ Discovery is more than user research

Discovery in product development is a group of activities to help the team understand what is the right product to build. As Teresa Torres puts it: the work we do to make decisions about what to build.

What gets built is defined by decisions on multiple levels (like company strategy, legal requirements, current tech stack, and user need) by multiple people, so user research can’t be the only input to those decisions. This is why figuring out what the right product needs involvement from all members of a product team (the product trio approach), and thus a combination of activities.

Product discovery is paired with delivery, which makes sure the product is built right — the two parts of dual-track agile. Once the product team discovers what they want to build (as defined by prototypes, designs, specs, PRDs or other similar artefacts), they deliver the solution, caring about implementation, documentation, and design details. The beauty of the dual-track approach is, that while the two parts appear to waterfall, ideas from discovery inform delivery continuously, while learning from delivery drives further discovery, creating an interplay between the two sides.

Sometimes teams turn to the building and fail fast approach to delivering something directly in production. It’s important to realize, that discovery will still happen, but only after decisions are made and things have been built. This later understanding of risks is always more costly, as decisions will be harder to change both practically (for example technical choices were made), and mentally (sunken cost fallacy).

On a high level, the team looks at their basic questions and assumptions around an opportunity in discovery to address risks and gets insights about them. The tricky part is to cover all aspects, since assumptions come in many flavors and carry multiple types of risks within them.

When it comes to developing products, there are four types of risks product teams need to take care of: business fit, value, usability, and feasibility.

• Business fit (or viability) covers all things related to the broader business. Does the solution fit into the portfolio strategy? Are legal, financial, and ethical issues handled? Can it integrate with other products in the portfolio? Is this the right time to bring it to the market? Is there a budget available for go to market activities?
• Value is all about if there is a clear product-market fit with the potential users. Does the solution address a clear user need? How does it fit into the user’s existing context? Are there enough potential users to have a good return of investment? If this is a paid product, does the cost justify the functionality for the users?
• Usability covers all the experience-related questions. Is the solution easily understood and learnable? Does it fit with the users’ ways of working and expectations? Can it deliver what it promises? Is it much better than the current approach to justify the switching costs? Would the users want to switch to or use it?
• Feasibility is related to the implementation and technical constraints. Is the solution possible to build? Can the team build it? Does building it take a reasonable amount of time compared to possible value? How costly is it to deploy? How difficult is it to maintain? How much support will either the users or the implementation need?

As a side note, these aspects are related: for example, with high value previously unfeasible (for example too expensive) solutions can turn into feasible once the associated risks are understood and mitigation strategies tried during discovery. So working on each of these risks should be tightly connected.

User research is very helpful to address some of these questions, but it’s not the only activity the team needs to perform to completely understand the possible solution. Some of the above questions will need other activities (like making technical decisions or figuring out design constraints) and thus involvement from the broader team.

While discovery helps in making better choices, sometimes the problem is trivial, well-understood, or is firmly in a space the team already understands well (for example adding a new payment method to a checkout form). We want discovery to focus on more meaty problems, so in these cases, it can be omitted.

To make sure discovery is encompassing, discussing opportunities should start with a kick-off including the product trio, other relevant experts, and stakeholders. The goal is to give a better frame of the problems at hand, gather known insights, and make a list of assumptions the group has to drive potential solutions. During discovery, these points would be further expanded as the team learns and understands the problem space better. For each assumption, a learning path can be established (like talking to potential customers, creating technical POCs, doing root cause analysis, or sketching up prototypes).

If the outcome of discovery is the decisions defining what the product team needs to build, discovery activities need to cover all aspects of those decisions.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Product discovery is paired with delivery in a development process usually named dual track agile. Jeff Patton’s Dual Track Development is not Duel Track describes the origin of the term, the differences between discovery and delivery, and how product teams need to do both activities at the same time.

♠

Besides offering a good primer on discovery, The critical role of discovery in product development by Matthew Godfrey offers a view on collaboration in discovery. It’s typically led by the product manager, product designer and technical lead, while other disciplines can join temporarily the efforts.

♡

If discovery is building the right product, it’s important to understand how the wrong product could be built. This is where understanding the various risk types is helpful. Marty Cagan describes four types of risks in Product Risk Taxonomy: value, usability, feasibility, and viability. By covering each of these risks, product teams discover what product they should build.

♣︎

Chris Jones in Product Discovery: Pitfalls and Anti-Patterns categorizes discovery mistakes into 6 categories. These are: Confirmation-biased discovery (focusing on an already established solution), product-as-a-prototype discovery (mistaken delivery), partial-team discovery (doesn’t address all risks), one-dimensional discovery (focused on a single method or approach), big-bang discovery (lacking continuity), outsourced discovery (expecting others can learn instead of us). There are also some tips to get it right.

♢

The ultimate result of discovery is better outcomes for the users. This is the main reason for handling discovery as a team-level activity, rather than focusing only on specific aspects. In Doing Discovery Well: How to Measure and Guide Your Team, Teresa Torres shows that the good lagging indicator for discovery is how well the team reaches their desired outcome. As a more immediate measure, the cycle time between activities can be used, like how often the team talks to a user, runs an experiment or throws away solutions.