The Product Discovery Landscape

Lots of agencies have their own 'branded' version of Discovery. The same Discovery process that works for building Mission Control for SpaceX might not work as well for a game designed to kill time for teens. (Although some parts might be eerily similar!) In our quest to deliver value to users of 'serious' web interfaces, we pull from several different frameworks.

In our typical engagement, Discovery is happening at the same time as analysis of a business case. For validation of a business case, we often use Lean Canvas for our startup clients, and if our client hasn’t already gone through this exercise they often find it adds clarity to their problem statement. There are similar frameworks for established companies, but we haven’t had to go much farther than the Business Model Canvas (which is about the same as Lean Canvas). We’ve run essential BRIDGeS scenarios, but we haven’t found that it (BRIDGeS) takes us much farther than the basic Lean Canvas for either Enterprise or startups, in the space of our 'typical' engagements.

We like and emulate the shape of Design Thinking, but we think that the name alone isn’t enough to get people on the same page. We usually have to walk a client through all the activities we’re going to do before we intend to start producing designs and prototypes so that they understand what we are going to be spending our time (and their money) on.

In Discovery itself we tend to use whatever vocabulary is most familiar to our client. So we always go through iterations of something most people call Exploration / Validation. Sometimes we call the same process  ‘Ideate / Evaluate’. And sometimes if we’re doing something that passes for basic brainstorming we call it ‘Converge / Diverge’ to reflect the phases of group solution-finding. 

There are all kinds of Discovery frameworks out there. Design Thinking. Jobs To Be Done. Riskiest Assumption Test. Whatever we find works, we use. And as we go along we document our best Discovery practices.

Breaking Down The Product Discovery Process

If you think of Discovery as ‘everything that has to happen before your first development sprint’, then you can imagine that Lab Zero Discovery comes in three phases:

• Clarify the Why
• Define the What
• Prepare to Sprint

(Note: Discovery can and should continue in a repeating cycle during the engagement, but this part of Discovery that happens before development starts is especially visible to clients, and so we discuss it here.)

Clarify the Why

During this phase we ask a lot of questions, build empathy for our users, and examine secondary research. After this phase, you’ll have a clarified, problem statement with scoping. You’ll have a map of today and a set of learning goals that prototype testing with real users can and should fulfill.

Define the What

During this phase we explore solutions, and evaluate them according to desirability, usability and feasibility. At the end, you’ll have a map for the desired future end state and a design ‘sketch’ which might be a prototype or a framework that will give shape and structure to future designs.

Prepare to Sprint

Here we finish everything we need in order to be ready to start Engineering sprints. At the end, there is a prioritized backlog, with highest-value estimated stories in a ‘ready’ state for development work. (Check out our Definition of Ready.) In the event that the first two phases of Discovery tell us that there is no need to build a feature, the last phase also serves as a report-and-readout 'off-ramp'. (How can Discovery end happily, with no product design? Learn more about the Paradox of Wasted Effort.)

How effective is your Product Discovery?

We put a lot of weight on Discovery because we find that our engagements deliver more value when we help guide this process at the beginning. Are you in that 'almost-ready-to-build' space where you would benefit from a fresh set of eyes? Let's talk.