What are discovery sessions
If you’ve been reading InsideProduct for a while, you’ve probably picked up by now that I focus on solving the right problem and ignore everything else.
I’ve found that one, or a small series of, discovery sessions is an excellent way to identify what that problem is and also understand the constraints you have on your solutions.
This post explores discovery sessions and explains how you can use them to ensure you tackle the right problem and have sufficient information to get started on providing the right solution.
If you’ve worked in large enterprises, when you hear “discovery sessions,” you may wince a little. Your mind might go to those dysfunctional project kickoffs or months of endless requirements sessions.
I’m not advocating sessions like that.
Discovery sessions have a few specific purposes:
- Understand the problem you’re trying to solve.
- Determine if the problem is worth solving (if not, STOP!)
- Understand the key constraints, risks, and assumptions relevant to crafting a solution.
A successful set of discovery sessions helps you establish a broad view of the problem space so that you’re better positioned to do deep dives on specific portions of the solution.
Why would you do discovery sessions?
Discovery sessions are appropriate when you have an idea you want to explore. That idea may result in an entirely new product, or a significant change to an existing product.
You want to determine whether it makes sense to pursue the idea. If it makes sense to pursue, you want to build a shared understanding of the problem you’re trying to solve and what some constraints are on a solution.
Discovery sessions are effective when they help you build a shared understanding with everyone involved in a project and lay out an initial plan to move forward.
They are even more effective if you go into the discovery sessions willing to stop work if you discover during the sessions that solving the problem makes little sense under your current conditions.
Building a shared understanding and creating a plan forward is relatively easy.
Having honest conversations about whether a project makes sense is much more difficult but can provide much more value by avoiding work on a bad idea.
Who do you invite?
One reason to do discovery sessions is to provide a means for people with a variety of different perspectives to discuss:
- the problem you’re trying to solve
- what you’d like a solution to look like
- whether it makes sense to solve the problem at this point in time
A variety of perspectives makes these conversations more productive. That way, you can uncover key information to help you decide whether to proceed.
IT’s also helpful to include the people who are going to work on the product so that they start out with a shared understanding about what you’re trying to accomplish.
The people that should be involved in some, or all of the discovery sessions include:
- The key decision maker for the product. This is the person who determines what outcomes the product should deliver and whether it makes sense to proceed with the product and any projects related to it.
- Subject Matter Experts for the domain and technology that the product impacts
- The product team (the people who will build a solution) Hopefully this team is cross functional and includes people with user experience, development, and testing skills.
You’ll want someone focused on driving the discussion and getting to key decisions. For a further explanation of what this role might look like see the Driver in the DACI framework.
It’s best if this is not the person who actually has to decide and is usually the product person or someone brought in from the outside the group working on the product for a long term.
Discovery Sessions
The main point of discovery sessions is to have a series of focused conversations that each have a specific purpose and occur in a specific order.
You can hold the sessions altogether as a workshop during a focused 2-day period, or you can hold the sessions as a series of 1–2 hour discussions over the course of 2–3 weeks.
The choice of which schedule you use depends on how quickly you want to start work on the project and the availability of the key participants for each session.
Below is a description of each session. If you’d like more information about the techniques described in each discovery session, follow the provided links to technique briefs.
Outcomes
The purpose of the outcomes session is to make sure a shared understanding exists between everyone involved with the project regarding what you want to accomplish. Establishing this shared understanding is essential in order to decide whether it makes sense to continue.
This session also identifies measures of success for your project as well as identifies decision filters that embody your targeted outcomes in tools that help you decide what to include/exclude if you choose to pursue the project.
You’ll want to do the outcome session first since it sets the stage for all future discussions. You may use this session as a kickoff for all the discovery sessions since it’s the first one and should include everyone that is involved with all the sessions.
It’s probably a good idea to schedule this session for 1.5–2 hours. Be sure to keep the discussion moving so that if you get done early, you can give people some time back if you’re doing the discovery sessions as separate scheduled discussions.
1) Introduction
Explain the purpose of the session and have participants do introductions (Name, role in the project) if they do not all know each other.
2) Problem Statement
In order to find out the real reason you’re working on an internal product, do the problem statement exercise with your team. The problem statement is a structured set of statements that describe the purpose of an effort in terms of what problem it’s trying to solve.
It will ensure you have clarity on your desired outcomes, and it will help your team get a shared understanding of those desired outcomes.
Use the problem statement exercise to give everyone on the team an opportunity to describe why they think we’re rebuilding (Project/Product) and then build a shared understanding of the intended outcome.
The resulting problem statement will be helpful to bring focus to discussions and to guide decisions about what you’ll include in and exclude from the (Project/Product).
3) Success Metrics
Next, create a few outcome-based success metrics. These success metrics provide a way of measuring success and guide decisions regarding what functionality to include.
Outcome-based metrics are a way to tell whether you’ve delivered an outcome.
The metrics should measure something that has meaning to your organization’s customers or something of relevance to your organization that shows you are meeting your customer’s needs. It’s important to identify outcome-based metrics to avoid measuring progress and success based solely on output.
4) Decision Filters
As part of your discussion about outcomes, use the result of the problem statement exercise to determine a few decision filters. These are questions, usually expressed as “will this help us do x?” you use when you’re discussing options to decide which you will do, and which you won’t. If you ever find yourself in a discussion about whether or not to do something you can refer to these decision filters.
For example, an online university used the following two questions to help them decide whether to pursue certain activities:
- Does this promote personalized learning?
- Does this promote competency-based learning?
If the activity did not pass through the filters, they didn’t do it.
5) Conclusion
Summarize what the group determined and identify follow-ups and next steps.
Purpose-Based Alignment
This session discusses the nature of the activities that your project and product supports through the lens of the Purpose Based Alignment model.
The Purpose Based Alignment Model is a method for aligning business decisions, process and feature designs around purpose. Some decisions and designs differentiate your organization in the market. Other decisions help you achieve and maintain parity with the market.
Those activities that do not require operational excellence either require finding a partner to achieve differentiation or deserve little attention.
Those activities that do not require operational excellence either require finding a partner to achieve differentiation or do not deserve much attention.
Those activities that do not require operational excellence either necessitate finding a partner to achieve differentiation or do not deserve much attention.
Purpose alignment generates immediately usable, pragmatic decision filters you can cascade through the organization to improve decisions and designs.
The output of this discussion should provide some insights that can guide decisions about how we approach specific features.
Interfaces
Any product that’s worth building most likely interfaces with at least a few other products, and at the very least is used by multiple people or departments in your organization.
The context diagram helps you to identify potential interactions. You can also use the context diagrams to identify the key stakeholder groups you’ll need to talk to in order to get a better understanding of what information your product needs to provide.
The context diagram to identify potential interactions. You can also use the context diagrams to identify the key stakeholder groups you’ll need to talk to in order to get a better understanding of what information your product needs to provide.
A context diagram is a model that shows how your product interacts with outside people, organizations, and/or systems.
The context diagram helps you to:
- Identify the interfaces you need to account for
- Identify scope
- Identify potential stakeholders
- Build a better understanding of the context in which you are working.
During this session, create a context diagram to identify current state and future state and keep track of which interfaces we need to investigate further.
Processes
Internal products exist to support one if not more business processes. When you explore those business processes, there’s the way it is supposed to happen, and the way it actually happens. You want to understand the latter because that’s going to clue you in on how the product should actually operate. Using collaborative modeling to create a process model is the best way to get to that understanding.
- Identify and understand the key processes supported by [project/product]
- Understand how a solution will need to support key processes
A process model describes the flow of work or activities, usually in a graphic format, that contribute to accomplishing a specific goal. Process models are typically used to represent and analyze a series of activities that occur repeatedly and regularly.
Process models can model the flow of work in or between people and departments in an organization, or the flow of activities in a computer system or application.
Process models have a clear beginning and end, intended outcome, order of activities, and different results based on the decisions that you make through the course of the process.
The intent of the model is to provide a representation of the process that allows understanding, analysis, and decisions.
Risks and Assumptions
Use the risk management game to identify, categorize, and determine how to address the key risks you face. And make sure you use the results to guide your prioritization decisions. You’ll be glad you did.
- Identify and categorize key risks
- Determine how to address key risks
- Identify key assumptions
- Determine how to validate key assumptions
The risk management game is a collaborative way for your team to identify risks they face, categorize those risks based on impact and probability, and determine which risks to address first.
Scope
Regardless of what some overzealous agile coach tells you, DO NOT jump immediately to brainstorming backlog items without first doing the activities mentioned above.
Without the understanding those discussions bring, any effort at backlog creation is merely sticky note theater.
When you do have the insights from those exercises, you’ll have a good overview of the problem and possible solution so you can start synthesizing what you have learned and think about how you may go about breaking the work up into backlog items.
Story mapping can help you plot things out and think about how to group your backlog items in a meaningful way. It will at least help guide the conversation.
An example
I always appreciate the opportunity to test and refine the techniques I use with a new team in a new context.
Here’s the story of how a team I worked with did an initial discovery period to understand the outcome we’re trying to achieve and build an initial shared understanding of our solution. These activities resulted in a broad (but relatively thin) understanding of our solution that helped us organize our approach to doing deep dive on thin slices of the product as we move into an ongoing delivery/development cycle.
The aim of this project was to rebuild an internal product. The product team started with 2 developers, a UX expert, a delivery lead (that’s me acting as the resident product person on the team), and a scrum master.
During the discovery period, we added four more developers, a tester, and swapped out our UX experts. We also work with a Product Owner who mainly fulfills a decision-making role, and a group of subject matter experts and users.
The team started out the project with a period of about 3–4 weeks where we got familiar with the existing business process and product and clarified our intended outcome.
During that time we held a series of discovery sessions which ranged from 30 minutes–2 hours where we used a variety of techniques to clarify the outcome and build a shared understanding.
We went this route instead of having a single marathon workshop to avoid undue interruption to our Product Owner and Subject Matter Experts’ schedules and to give the product team a chance to do research and analysis in between the sessions.
Here are the specific discovery sessions we held over that time. For each session, I describe the reason we did that session and the techniques we used.
Outcomes
The purpose of this session was to establish a shared understanding about the outcome that we wanted to deliver and established criteria we use to decide what to include and exclude from the product backlog.
We used the problem statement to guide the outcomes discussion and give everyone on the team an opportunity to describe why they think we’re rebuilding the product and then build a shared understanding of the intended outcome. We didn’t create a concise problem statement, but everyone involved found the discussion extremely helpful to establish an agreement on our purpose.
The discussion also helped us establish decision filters we used to build a shared understanding of intent and to guide decisions in a distributed fashion. We came up with three decision filters, two that helped us determine what to include/ not include in the product backlog, and one that helped guide our technical decisions about how we approach the functionality we choose to deliver.
Ideally, we would have also identified 1–3 outcome based metrics to tell us whether we’ve delivered on our outcome. Since we’re rebuilding the product to reduce manual processes and reduce errors, we’re still trying to determine the best ways to measure those outcomes. In the meantime, the decision filters provide sufficient guidance to help us make decisions.
Interfaces
The purpose of this session was to identify the interfaces the current product has and may have with outside people, organizations, and/or systems. We used that understanding to determine which interfaces we need to investigate further and account for when rebuilding the product.
We used a context diagram to guide our discussion about interfaces. We identified all the current and potential providers or users of data (external agents) that our product interacts (or may interact) with and noted each with a sticky note.
Then we noted the specific interfaces each external agent has with the system by drawing them on the whiteboard. Using a whiteboard is helpful because you’ll often write one thing, and then change it as you discuss the specifics further.
The interface discussion was one of the first discovery sessions we did. It helped us to determine other discovery sessions we needed and to identify interfaces with external organizations or other groups inside the organization that needed further coordination and posed higher risks.
The context diagram also provided to be a helpful visual aid I referenced when I onboarded new members to the team.
Business Process Mapping
The purpose of these sessions was to map out the current state business processes related to the product. We took some time to discuss and map out the current state of the business processes and then discuss opportunities for improvement.
We used information we got during a demo of the existing product and some initial discussions to identify five high-level processes. We then scheduled a separate session to focus on each process. That gave us the opportunity to keep the group discussing any process to key individuals.
We used process modeling to help structure the conversations around the various processes. I would ask our subject matter experts to walk through the process, and I would note key steps or decisions with sticky notes on a whiteboard and write arrows in between the sticky notes to indicate a flow.
Using a whiteboard in these situations is key because you’ll often uncover new intermediate steps or have to change part or all of your flow when you ask that one question that uncovers a whole new set of understanding, or a much better idea of the process.
We used these process models to gain a better understanding of the business process and to identify key product backlog items. They were also helpful along with the context diagram in getting new team members up to speed.
Risks and Assumptions
The purpose of this session was to identify and categorize the major risks and assumptions facing the rebuild effort and identify how we might address those risks.
We used the risk management game to structure the conversation around risks and provide a structure for identifying, classifying, and prioritizing the risks that we faced.
Because of this discussion, we could identify a set of risks that we needed to address. We identified plans to address those risks and the people who should address them. Two largest risks had to deal with external interfaces that were not present in the current system. We started working on those interfaces first to make sure we could address the biggest risks facing the product as soon as we could.
Scope–Identify Epics and Features
The purpose of this session was to identify potential epics and features, organize them into priority groups, and identify the first feature to understand in more detail.
To prepare for this session, I took an initial pass at identifying four epics (which roughly mirrored the high-level processes we used to organize our business process discussions) and the corresponding features. I referenced the process models and context diagram to help with this exercise.
The product team then got together and reviewed the epics and features I identified in order to provide clarification, identify features that were needed, or remove features that weren’t needed. The product owner and one of the subject matter experts provided good clarification that also helped to clarify some misunderstandings on our part.
Next, I asked the product owner to group the features. First, I drew a line on the whiteboard and asked him to place any of the features (represented as sticky notes) below the line that were not needed by our target date. These items we considered as out of scope.
Next, I drew a line above the first and asked the Product Owner to put any features there which were nice to have by our target date.
Finally, I drew a third line and asked the product owner to put any sticky notes above that which represented the most important first things to work on to reduce risks or validate assumptions.
The top group we identified as now, the second group was next, the third group was future, and the fourth group we labeled out of scope. I created a roadmap of sorts to capture those groupings.
This way of grouping the features roughly followed Todd Little’s ABC’s of prioritization, although we didn’t go to the extent of sizing the features at this point.
Concurrent Activities
In between the discovery sessions, we did several other activities to further our understanding of the context, the problem, and our potential solution, as well as to prepare for development activities. Here are some of the primary activities.
Industry Research
Because I’m new to the organization and its industry, I spent a bit of time becoming familiar with industry-specific terms and common business practices. This was especially important because one aspect of this product is to help the organization manage how they performed an industry standard process.
To help with this effort, I started a glossary and started collecting industry-specific business rules.
Data Model and Data Dictionary
I also started a data model (via sticky notes and a whiteboard) and a data dictionary (in excel). The data model helped me think through entities, key attributes, and relationships based on information identified during discovery sessions. The data dictionary helped me to note metadata about entities and attributes including standard definitions of data elements, their meanings, and allowable values.
I did not attempt to “finish” the data model or data dictionary, rather I wanted to put an initial structure in place that I could build upon as we took a deeper dive into the various features we worked on throughout the course of the effort.
The data model also helps us to split features into smaller product backlog items. I’ll talk more about how we’re using the data dictionary to describe those product backlog items in the next post.
User Profiles
While those activities were going on, the UX expert met with the key users of the existing product and used those discussions to create user profiles. We used these profiles to identify the characteristics of key user groups to establish archetypes that can influence design of the information architecture and user interfaces.
Information Architecture
The UX expert also created an information architecture for the product in order to define the overarching structure and relationship between all areas of the product based on information determined during discovery sessions.
Setup Technical Infrastructure
Having developers involved in the discovery sessions from the beginning helped them to build an understanding of the problem we were trying to solve. It also gave the team the opportunity to discuss the problem from a variety of different perspectives and to make sure we were asking pertinent questions in the discovery sessions.
Their early involvement also gave them a head start on getting their development infrastructure setup, hoping to hit the ground running fairly quickly.
Although we were rebuilding an existing product, we were building it on a completely new tech stack, so the time in between discovery sessions was invaluable for the developers to lay out the architecture and establishing their development environments.
We also used this time to identify how we would work together as a team.
Keeping context in mind
The approach we took in this situation is based on the need to understand a complicated product where the problem is fairly clear, but there is a lot of missing specifics.
There were no documents about the current processes, so we had to rely on looking at the existing product and discussions with subject matter experts to fill in the gaps.
This approach works well for rebuilding an internal product, but may not be as meaningful if you’re working a new product or service that you’re going to sell.
We knew who our users were.
We knew what problem we’re trying to solve.
We needed to find out all the existing rules and data and figure out ways to make existing processes better and come up with effective ways to support new processes.
Our challenges came from making sure we built a complete understanding of the processes, data and rules we need to care about. We had to make sure we built a product that the existing users could use effectively and that new users can come on board with ease.
Additional Resources
The Benefits of Having a Product Discovery Phase with Your Dev Team
In the software development industry, it’s common for organizations to approach development agencies like the one Johanna Lozano works at with a product they want to create. Sometimes those ideas call for a huge product. Sometimes those ideas call for a fairly small product. Either way, there are still uncertainties such as potential users, the product functionalities, or monetization strategy. These uncertainties make planning and bidding difficult.
Johanna finds it a good practice to bring together different roles to better understand the product idea before embarking on an entire project. A benefit that you get from this phase is that you can define a baseline to compare against. That comparison will tell you if your product is accomplishing everything that was expected of it from the beginning.
In this blog post Johanna shares what the Discovery process is all about and why it is essential for a successful software development project.
Discovery session for the new project Step-by-step
Iryna Korkishko shared Syndicode’s experience with discovery sessions they provide for their new clients. Even if you aren’t planning on working with Syndicode, this explanation can be very helpful if you want to understand what a discovery session is.
Discovery Meeting: Why it’s at the heart of everything Solutelabs does
Solutelabs used to send proposals and quote a price and never heard from their prospects. As they tried to figure out what was going wrong, they decided they needed to understand their prospect better. One way they did that was to hold discovery meetings with potential clients.
Karan Shah explains why discovery meetings are worth the effort, how these meetings help turn complex ideas simpler, reduce uncertainties and pave the way for a ‘surprise-free,’ productive collaboration.
How to Run a Discovery Session to Get to Know Your Clients Quickly
Wil Brown explains how a discovery session allows you to zoom out and look at the bigger picture before dealing with the nitty-gritty details. It also allows you to understand the business context, operations, audiences and marketing techniques uses allowing you to find value-adds.
The discovery session blueprint
Simon Kelly explains that for independent web designers, the way to earn more money and grow your business is to stop talking about deliverables and start talking about outcomes. By focusing on outcomes, you help your client solve the right problem and position yourself as a business consultant.
Simon explains how you can use a discovery session to talk about outcomes. In a discovery session, your job is to guide your prospect / client to understand the business goals behind their projects. To do this, you need to dig deep and ask questions that may be a little awkward. But once you do, you can become a partner in the process and be someone they want to work with.
Project Chartering
Project chartering is an activity where the team develops and maintains a high-level summary of the project’s key success factors, synthetic enough to display it on one wall of the team room as a flip chart-sized sheet of paper. This description includes at least the major objectives of the project, scope boundaries, and reciprocal agreements between the project’s implementation team and external stakeholders.
You can think of running discovery sessions as project chartering.
The items described below are artifacts you can use as an input into discovery session, or you can start the artifact as an input and then use the activities in the discovery session to flesh out the project charter,
An Agile Project Charter
Michael Lant provided an example of what a project charter would look like when it’s stripped of unnecessary content and focuses on the information necessary to get your project started. The key to this approach that he learned from Gil Broza is to “create a project charter that is only one page long, whose purpose is solely to provide a clear and concise definition of what success looks like for that project.”
Intercom’s Intermission
Intercom uses project briefs labeled with the quirky name “intermissions” to start all the projects on their products. Their Product Managers figure out how to explain, on a page or less, the problem they’re trying to solve, how to measure success, and the project scope.
“The goal of the Intermission doc is to have a shared understanding of what we are building and why.”
Intermissions are described in a couple of different posts on the Inside Intercom blog. One post describes how Intercom started using job stories and includes an Intermission Template. Another post describes how Intercom incorporates Intermissions into their overall process.
The Design Brief
Chris Matts and Richard Warner looked at teams in a large financial services organization trying to use models such as the Vision Board to start projects and found that tool better suited for a startup than large enterprises.
They realized that the order in which you discover the aspects of the model drives different behavior in a startup versus an enterprise setting. Their hypothesis is: “Depending on your insight, you need first to establish the outcome, market and needs. Once you have these three, they form the design brief for the UX designer to design the feature.”
Opportunity Assessment
I’ve mentioned Marty Cagan’s opportunity assessment a few times before. It’s in this context of project chartering where it is most useful. Marty see opportunity assessment as an important responsibility for product managers. “The purpose of a good product opportunity assessment is to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are excellent opportunities, to understand what will be required to succeed.”
Feature Briefs
According to Susan Abate, A feature brief serves the same goal as a project brief, but is more appropriate for businesses (and roadmaps) oriented toward ongoing innovation for products, rather than operations, sales, and marketing activities.
Another relevant distinction is that the feature brief begins as a standalone document, but later integrated into product documentation, whereas project briefs are archived or discarded once the project is complete.
Working Backwards–the Press Release/FAQ approach
Another approach to describe success is to project into the future what a press release and FAQ for your product would look like once it’s done. As Cedric Chin explains, you start out by writing a press release, which follows a very particular structure. You move on to write an attached FAQ document, which addresses a bunch of internal and external issues. These issues include (but aren’t limited to) things like total addressable market, per-unit economics, bill of materials, P&L, key dependencies, and technical feasibility. The total document — both PR and FAQ — should not exceed six pages.
How to have a kick-ass kick-off meeting
PH, a product manager writing on Substack explains how to prepare for and conduct a kick-off meeting. You can generalize these key takeaways for other kick-off meetings. A friend and fellow PM used to mention that no development work would begin in his organization, until the project is initiated with a proper kickoff meeting. Starting an initiative on the right foot sets the tone for the team on how the project will run. This can be used anywhere to kick-start a project.