In this article you can learn how to successfully getting started with product discovery by following my FAST method.
The FAST method will help you overcome the main barriers for effective product discovery so you can get off to a good start.
Before describing my model, let’s first analyze the main obstacles that might prevent you from getting started with product discovery.
Obstacles to Effectively Getting Started with Product Discovery
Unclear product strategy
Product Discovery works on the basis of autonomous teams with a clear, compelling and actionable intent.
When product strategy is not clear product teams will waste a lot of time working on things that are not important to the success of the product.
Make sure your product vision, product strategy, OKRs and product roadmap are clear and understood.
Absence of structure and process
You are very unlikely to succeed with product discovery if you don’t get started properly with certain structure and process.
That’s the reason I recommend to get started with product discovery by adopting a product discovery framework which will provide you with structure, alignment and visibility for management and stakeholders.
Lack of trust by management
Product Discovery is essentially a continuous learning process. So, if your company’s culture doesn’t tolerate “failure” and measures progress and success based on productivity (output) you will have a hard time.
Management and stakeholders will be constantly interfering in your work, questioning your decisions, telling you what to do and pressuring for delivery.
Solution bias
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions” – Albert Einstein.
Regardless of the starting point of a given initiative, product discovery principles remind us to always take a step back and analyze the problem space. This is to precisely avoid the solution bias or innovator bias.
It’s human nature to think in terms of solutions rather than the underlying problems.
But one of the most important lessons I teach my clients is to fall in love with the problem, not the solution. Because, unfortunately, our initial solutions won’t solve the problem.
It usually takes trying out several different approaches to a solution before we find one that solves the underlying problem and enables a scalable and sustainable business model.
A small amount of time upfront understanding the problem to be solved can make a dramatic difference in the results.
Lack of access to users/customers
Frequent customer and user feedback is key to successful product discovery. So, you must enable the mechanisms for smooth recruitment of customers and users and to get them involved in your discovery and delivery process.
You cannot practice product discovery behind closed doors or just once in a while.
Now, let’s see in more detail the FAST method for getting started with product discovery.
Framework
The Product Discovery Framework consists of the effective integration of the two main activities required to make sure we are going to build something likely to succeed: Exploration and Validation.
Both cycles are connected as an infinite symbol and in the middle lies a decision point. Because, at every iteration of either loop you have to make one of the following decisions:
- exit (Kill or Build)
- iterate more of the current loop
- jump to the other loop.
We also need to make sure that Product Discovery is always responding to a business outcome, a business goal or a problem with your product growth. That’s the reason the starting point is always the Goal, by building alignment.
Once we understand the high level structure of Product Discovery and the typical phases involved, we need two more tools to orchestrate the efforts and provide visibility.
Impact Mapping
We use an adaptation of the Impact Mapping tool to connect the challenge (the goal) of the Product Discovery process with the experiments.
You can see all details in this blog post: Impact Mapping for Product Teams.
- The WHY level represents the challenge. This can be a business goal, a product growth problem, a problem in the marketplace or a theme in the product roadmap
- The WHO level represents customers and users but also other people or entities involved in the value chain: i.e. partners, channels or OEMs
- The HOW level represents the outcomes (needs/problems) expected from performing a job or the improvements in pain points. In other words the impact we want to create to the people on the previous level
- The WHAT level represents the solutions, prototypes and experiments
Product Discovery Meetings
When designing the meetings I work with my clients to define the best approach given their circumstances and product discovery goal. Every situation will require different lengths of the discovery cycles, but essentially the ceremonies will be the same. The only that will change is the frequency and duration.
Product Discovery requires a learning period, so don’t push people too hard at the beginning or you will fail. I typically use a service design process which ends with a prototype of the product discovery process.
The main product discovery meetings are the following ones:
- Liftoff – meeting to build alignment and to get started with product discovery
- Planning – plan team’s activities for the next days or weeks
- Daily – plan the day ahead, review of progress towards goal and impediments
- Learning – at the end of the planed cycle you must review results, interpret the evidence and turn it into action
- Strategic Review – typically at a longer cycle than the planning, you must keep stakeholders on the loop with regards to learnings and progress and discuss pivoting, persevering or killing
- Continuous Improvement – meeting for continuous improvement of the product discovery team, process and structure
In addition to the previous meetings, which are meant to keep everything moving and interconnected, there will be specific meetings such as ideation workshops or prototype design workshops.
Alignment
Some product discovery work doesn’t require a lot of framing or planning. We need to come up with a solution to a particular problem, and often this is straightforward, and we can proceed directly to delivery work. But for many efforts, this is not the case, and framing and true problem solving becomes critically important.
It is key to frame our discovery work appropriately to ensure alignment.
We must ensure the team is all on the same page in terms of clarity of purpose and alignment.
In particular, we need to agree on:
- the business objective we’re focused on
- the specific problem we are intending to solve
- which user or customers you’re solving that problem for
- how you will know if you’ve succeeded.
These should align directly to your product team’s OKRs.
In addition to product alignment we need to build organizational alignment if we want to succeed.
We seek organizational alignment at the beginning to be sure that the product team will have the autonomy required with regards to how they want to work and what they want to do.
Depending on the context and the type of initiative at hand you can use different tools for building organizational alignment and product alignment.
Support
One of the pillars of high-performance teams is having a supportive environment.
Teams need a supportive environment to explore new business opportunities, identify ways to achieve a business goal, deliver a theme in the product roadmap or detect hacks that can boost product growth.
The purpose of product discovery is to learn faster than the competition. So, teams cannot be held to a standard where failure is not an option.
Failure will occur, but failure isn’t the goal. Leaders need to intentionally design an environment where this can occur, otherwise even an ideal team configuration with the right behaviors will eventually stall out and give up.
Hence, companies willing to outlearn their competition and succeed with product discovery must provide the following:
- Agile funding
- Leadership
- Coaching
- Customers
- Resources
- Strategy
Let’s see those aspects in more detail.
Agile Funding
Modern product teams do not operate on the standard of preassigned yearly budgets. They operate based on outcomes. Which means they get more funding the more they reduce uncertainty and advance into a profitable solution for the current challenge.
Ideally, product teams would manage their own budget and decide how to invest it based on expected business goals.
It’s unrealistic to expect modern product teams to function without a budget or funding. Experiments cost money. You must be able to incrementally fund the teams using a venture-capital style approach, based on the learnings they share during reviews.
Leadership
Teams need an environment that has the right type of leadership support. A facilitative leadership style is ideal here because you do not know the solution. Guide with questions, not answers.
Modern product teams require guidance in the form of clear strategy and metrics, boundaries and help whenever there are problems. Everything else is their responsibility.
Coaching
Teams need coaching, especially if this is their first journey together.
Coaches, either internal or external, can help guide the teams getting started with product discovery or helping when they are stuck trying to find the next thing to do.
Customers
Teams need access to customers. We expect contact with customers on a frequent basis both in exploration and validation tasks.
Resources
Teams need access to resources in order to be successful. They need enough resources to make progress and generate evidence.
Resources can be physical or digital in nature, depending on the challenge.
Strategy
Teams need a direction and strategy, or it’ll be very difficult to make informed decisions on the new business idea.
Without a clear coherent strategy, you’ll mistake being busy with making progress.
By strategy we mean the elements of a well-crafted strategy, as well as goals, KPIs and constraints.
Team
Everything that applies to high-performance teams applies to modern product discovery teams.
Here, we just want to make sure you understand the specifics of product discovery teams setup.
Composition
A product team is composed by a diverse group of people with a broad set of skills, however if we talk about the people required for leading the product discovery effort we must make sure we have at least the following roles:
- Product Management
- Design
- Engineering
That’s what we call the Product Triad or Core Product Discovery Team. If the product is a new business idea that might be the whole team, but if your product is already in the market team members will have to distribute their time between discovery and delivery.
You need to make sure everybody is aware of that. And, you must also ensure support and collaboration with temporary discovery team members like UX, Research, Data Scientists, Legal, Marketing or Sales.
Autonomy
Teams need to be given space to own the work and determine their product strategy.
Do not micromanage them to the extent where it slows down their progress. Instead, provide them with intent, boundaries, constraints and frequent time to provide visibility and get feedback of how they are making progress towards the goal.
Commitment
Teams need an environment in which they can be dedicated to the work. Multitasking across several projects will silently kill any progress.
This also means that product discovery is part of the normal operation of the team; it is not something that happens once in a while.
Modern product teams perform both discovery and delivery work.
Want to Get Started with Product Discovery?
With our FAST method we support teams getting started with product discovery.
I can help you implementing the method in your unique context to make sure you get off to a good start.
Recent Comments