What are discovery sessions
If you’ve been reading KBPMedia for a while, you’ve probably picked up by now that I tend to focus on solving the right problem and ignoring 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 make sure you’re tackling the right problem and that you 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 be inclined to wince just a little bit. 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.
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 in an iterative fashion.
Why would you do discovery sessions?
Discovery sessions are appropriate when you have an idea that you want to explore. You may be planning to build an entirely new product, or you’re about to start a project to make a significant change to that product. In either case, discovery sessions as described below make perfect sense.
You want to determine whether it makes sense to pursue the idea. If it does make 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 for moving 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 just does not make 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 of the reasons 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, and whether it makes sense to solve the problem at this point in time.
In order to make these discussions truly effective, you want to have a variety of perspectives so that you can uncover key information that will help you make the decision to proceed and so that everyone who will be engaged with the project will 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 be building 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 make the decision and is usually the product person or someone brought in from the outside the group working on the product for a long term.
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 working 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 on KBPMedia.
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 make a decision about 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 make decisions about 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 of 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.
Explain the purpose of the session and have participants do introductions (Name, role with respect to the project) if they do not all know each other.
2) Problem Statement
In order to find out the real reason why 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 should be included and not included in (Project/Product).
3) Success Metrics
Next, create a limited number of outcome based success metrics. These success metrics provide a way of measuring success and provide a guide for decisions regarding what functionality to include or not.
Outcome based metrics are a way to quantitatively 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 gives an indication that 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 small number of decision filters. These are questions, usually expressed as “will this help us do x?” you use when you’re discussing possible options to decide which you will do, and which you won’t. If you ever find yourself in a discussion about whether to do something or not 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.
Summarize what the group determined and identify follow ups and next steps.
Purpose Based Alignment
The purpose of this session is to discuss 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 and process and feature designs around purpose. The purpose of some decisions and designs is to differentiate the organization in the market; the purpose of most other decisions is to achieve and maintain parity with the market. Those activities that do not require operational excellence either necessitate finding a partner to achieve differentiation or do not deserve much attention.
In practice, purpose alignment generates immediately usable, pragmatic decision filters that 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.
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. Use a 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, helps you to identify scope, identify potential stakeholders, and 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.
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 on a regular basis.
Process models can be used to 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 actually use the results of this exercise 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 that they face, categorize those risks based on impact and probability, and determine which risks to address first.
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.
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 course of 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 the course of that time. For each session, I describe the reason we did that session and the techniques we used.
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 make decisions about 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 necessarily 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 that we use to build a shared understanding of intent and to guide decisions in a distributed fashion. We came up with three decision filters, two that help us to determine what to include/ not include in the product backlog, and one that helps 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 quantitatively 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 a meaningful way. In the meantime, the decision filters provide sufficient guidance to help us make decisions.
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 find yourself writing one thing, and then changing 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 that 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 obtained 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 particular 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 in general 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 main 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.
As a result of this discussion, we were able to identify a set of risks that we needed to address in one way or another. We identified plans to address those risks and the people who were responsible for addressing them. A couple of the largest risks had to deal with external interfaces that were not present in the current system. We chose to start 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 gradually 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.
In between the discovery sessions, we did several other activities to further our understanding of the context, the problem, and our possible solution, as well as to prepare for development activities. Here are some of the main activities.
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 start noting 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.
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 be used to influence design of the information architecture and user interfaces.
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, with the hopes of hitting 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 start laying out the architecture and establishing their development environments.
We also used this time to start identifying how we would work together as a team. I’ll talk more about that in the next post
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 information when it comes to specifics. Not much about the product or processes is documented, so we have to rely on looking at the existing product and discussions with subject matter experts to fill in the gaps.
This approach is well suited 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 know who our users are. We know what problem we’re trying to solve. We need to find out all of 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 come from making sure we build a complete understanding of the processes, data and rules we need to care about. We have to make sure we build a product that the existing users will be able to use effectively and that new users can come on board with ease.
If you’ve been in a similar circumstance I’d love to hear about your experiences.
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 a whole 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 back from their prospects. As they tried to figure out what was going wrong, they decided they needed to take steps to understand their prospect better. One way they decided to do that was to start holding 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 is an activity where the team develops and maintains a high-level summary of the project’s key success factors, synthetic enough that it can be displayed on one wall of the team room as a flipchart-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.
Running discovery sessions can also be thought of as project chartering.
The items described below are artifacts that 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 no more than one page long, whose purpose is solely to provide a clear and concise definition of what success looks like for that project.”
Intercom uses project briefs labeled with the quirky name “intermissions” to start all of the projects on their products. Their Product Managers are responsible for figuring out how to explain, on a page or less the problem they’re trying to solve, how to measure success, and the scope of the project.
“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 took a look 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.”
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 either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.”
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 is later integrated into product documentation, whereas project briefs are generally archived or discarded once the project is complete.