What is a Discovery Workshop?
A discovery workshop is a short engagement — typically 2 weeks to 2 months — where a team learns enough about a client’s business problem to design a thoughtful, honest project plan with mitigated risk. Other names for discovery workshops include Envisioning Sessions, Project Kickoffs, Discovery Sessions, and Scoping Workshops. The goals are the same regardless of the name: understand the problem, run small-scale experiments, iterate on solutions, and deliver a roadmap with an executive summary, project timeline, cost estimates, risks, and a proposal for the actual work.
Most consultancies scope a 6-month project after 1 or 2 conference calls. That produces a rigidly scoped, fixed-fee SOW involving Project Managers, Business Analysts, and ETL (extract, transform, load) coders — and it almost never reflects what the client actually needs. A discovery workshop fixes that.
Objectives of a Discovery Workshop
A discovery workshop has 8 objectives: identify problems, reframe those problems as challenges, brainstorm solutions, decide what to execute on, make solutions actionable, define the action roadmap, identify target audiences, and improve workflows. Each session produces working output — not just documentation.
When to Hold a Discovery Workshop
Hold a discovery workshop at the start of any significant data project, product build, or digital transformation initiative — before scoping, before procurement, and before any development begins. Discovery workshops also apply when a company is experiencing significant growth, key leadership has changed, or teams need realignment around a single strategic vision. In agile contexts, hold a discovery workshop as late as possible before development begins on a new user story, to prevent details from being lost and give the team room to adjust plans when new information surfaces.
Who Should Attend?
A discovery workshop needs 3–6 people at a minimum. At minimum, 3 roles must be present — a product owner, a developer, and a tester, often called the Three Amigos. The product owner identifies the problem, the developer addresses how to build a solution, and the tester addresses edge cases.
For larger project kickoffs, the attendee list expands to include all business and technical stakeholders, the project sponsor, line of business (LoB) representatives, IT team members, customer experts from sales or support, and a facilitator. A notetaker and a whiteboard facilitator are the 2 roles needed from the consulting side. Everyone present needs to be engaged, open to all ideas, and ready to contribute.
How Long Does a Discovery Workshop Take?
A discovery workshop takes 25–30 minutes per user story for agile sessions, and 2 weeks for most project-level engagements. Sessions run 2 hours each, with a maximum of 2 workshops per day — a morning session from 10am–noon and an afternoon session from 2–4pm. The structure respects attendees’ other responsibilities and keeps attention high. If staff are checking email during the session, the session has failed.
For large projects, discovery can run up to 2 months, but this is rare. After 2 weeks, conversations begin to focus more on why the project can’t succeed rather than how it will. For truly large projects, a smaller minimum viable product (MVP) scope shrinks the discovery phase to a more productive length.
Why Bother? (Benefits of Discovery Workshops)
The purpose of a discovery workshop is to give all stakeholders — both technical and non-technical — a shared understanding of the work at hand. There are 5 specific benefits.
First, discovery workshops encourage cross-functional collaboration between business and IT teams who rarely share the same room. Second, discovery workshops increase feedback volume early, when changes are cheap. Third, discovery workshops surface incorrect assumptions before they become expensive mistakes. Fourth, discovery workshops produce a risk-mitigated project plan that both sides are confident in. Fifth, discovery workshops include working experiments — small-scale code and prototypes that validate ideas before full commitment.
Clients get as much value out of discovery as they put into it.
How to Conduct a Discovery Workshop
Discovery workshops run 2 workshops per day, each 2 hours long. A facilitator and a notetaker attend from the consulting side. The first 4 sessions — 2 days — follow a scripted baseline. After that, sessions are planned just-in-time based on what the team discovers. Every engagement is different.
Between morning and afternoon sessions, consultants transpose notes into documentation, convert whiteboard content into diagrams, discuss findings, build experiments, and prepare for review sessions. Review Sessions happen the day after each initial Discovery Session. Clients frequently change requirements or scope based on the analysis that comes out of those reviews.
Deep Dive: The Kickoff Meeting
Assemble the entire team — all business and technical stakeholders — for the kickoff meeting. The 2-hour agenda covers: why the team is here; introductions including names, responsibilities, and expectations (which produce a RACI chart); key objectives; team roles; decisions the team is trying to make; sample data, reports, and dashboards; potential data sources; how success is measured including KPIs and the MVP; and frank conversations about organizational politics including project sponsorship, prior attempts at the project, hostile groups, out-of-scope items, and off-limits technologies.
Deep Dive: The Business Stakeholder Meeting(s)
This is usually the second workshop and it involves LoB stakeholders only — no IT team. This session is called the WHATs Meeting. The goal is to understand WHAT the business problem is without yet discussing HOW to solve it. The facilitator listens.
The agenda is dynamic. Some clients arrive with a fully scoped RFP (request for proposal) and just need gaps filled. Others have a business idea and need help with execution. Questionnaires are sent in advance to help business stakeholders think through what they need.
The Biggest Challenge: Getting Business Stakeholders to Envision the Art of the Possible
Business stakeholders often see solutions only through the lens of the data they already have. This is a mistake. The right question is: If you had access to all the data you need, what questions would you ask? External data sources — including weather data, which is the most frequently requested data element by forward-thinking companies — can change how an organization makes decisions. Start small but think big.
Deep Dive: The IT Stakeholder Meeting(s)
The IT stakeholder meeting is usually the third workshop. IT attends alone. Topics include how IT handles data projects today, the IT landscape covering naming conventions and software frameworks, source control and code review policies, the organization’s propensity for change, specific project challenges, who will support the final product, and who the dedicated IT subject matter experts (SMEs) will be for the project.
These conversations determine which technologies to propose. No solution gets recommended without IT being on board.
Deep Dive: The Envisioning Review Session(s)
The envisioning review session brings both LoB and IT stakeholders together. The team reviews what was learned from each group separately. These sessions sometimes get heated — that’s fine. After the review, the team works toward organizational alignment and begins iterating on solutions together.
Solutions are presented as Reference Architectures — not just diagrams, but working code that can be deployed quickly to handle tasks that traditionally take weeks, including ingesting new data sources.
Discovery Workshop Agenda
A standard one-day discovery workshop agenda runs: Introductions (10 minutes), Product Vision (45 minutes), Press Release (45 minutes), Break (10 minutes), Elevator Pitch (30 minutes), Success Sliders (20 minutes), Pragmatic Personas (45 minutes), Lunch (30 minutes), User Story Mapping (90 minutes), Prioritization (30 minutes), Break (10 minutes), User Story Writing (90 minutes), Team Charter (20 minutes).
Customer Responsibilities During Discovery Workshops
Clients need to provide a conference room with a whiteboard and projector, a printer for handouts, good attendance at sessions, WiFi, and sample data sets or access to data sources where possible. Discovery workshops are best run on-site, at least initially. Face-to-face sessions produce better outcomes than remote sessions because interaction time is maximized and travel costs justify longer working days.
Competitive Differentiation of Our Discovery Workshops
The Data Science Approach: Top-Down
Most IT projects fail because they work bottom-up. They start with a vague understanding of requirements, search for data to fit a hypothesis, model the data, build dashboards, and present a solution months later that the business says is not what was asked for. The entire project focused on OUTPUTS — each phase producing a deliverable pointed at a pre-conceived solution.
Successful discovery workshops work top-down. The process starts by identifying potential business use cases, then identifies data that supports those cases — even if that data does not exist today — then determines the analytic requirements needed to make it real. Working top-down means the team may not immediately see all the lower-level steps. That is fine. Those are resolved in later iterations. The goal is to see the big picture first.
The Monetization Exercise
The most successful projects are the most profitable projects. The monetization exercise starts by understanding current product usage patterns and customer behaviors, then identifies what to do next to create complementary offerings that can be packaged and delivered profitably. When a project is conceived in terms of monetization, it almost always succeeds.
Discovery Workshop Feedback
“You got us to think like a data scientist.”
Discovery workshops run on small-scale experimentation and iteration. Teams learn from failure quickly. Clients report this as a genuine culture change — one that sometimes requires reinforcement when teams regress into old behaviors. It’s not important to get it right the first time. Getting it right the last time is what matters.
“We love how you do everything with scores”
Discovery workshops use simple scoring mechanisms — typically a 1–5 scale — to evaluate decisions and prioritize initiatives. Numbers build consensus faster than opinions. Scoring every option makes it easy to agree on what to do next.
Common Objections to Discovery Workshops
“You said sometimes you do 2 weeks and sometimes 2 months. That sounds like you are padding your time. Let’s do this in 2 days.”
Discovery workshops have run in 2 hours, 2 days, 2 weeks, and 2 months. Two weeks is the sweet spot for most projects. After 2 days, the most important facets of the business problem are understood — remaining time goes into developing the solution, not formatting documentation. The duration is the client’s decision. The goal is not to burn hours. The goal is to get comfortable enough to win the follow-on work.
“Discovery Sessions sound waterfall. We are agile and won’t waste time on huge up-front requirements gathering exercises”
Discovery is not waterfall. The goal of discovery is not to gather all requirements and document them — it is to learn enough about the problem to design a thoughtful project plan. Writing code and running experiments during discovery is agile by definition. Discovery workshops follow lean and kanban principles: develop quickly and fail fast.
“I’m not going to pay you to learn my business, I already have a scope document and RFP. Just do the work as we outlined it.”
Even a well-written RFP gets interpreted incorrectly in most cases. Discovery is risk mitigation. A month-long discovery engagement that ends in a poor fit costs far less than a 6-month project that fails after a year. Discovery protects both sides.
“A Discovery Engagement will never get through our procurement department. We need defined deliverables”
Discovery engagement SOWs always include at minimum: a roadmap architecture document with an executive summary and project plan; a SOW with rough order of magnitude (ROM) cost estimates for additional work; and working code from collaborative experiments. The deliverables can be scoped and worded to meet any procurement requirement.
Pitfalls
Clients often want to buy projects, not products. Buying a vendor’s off-the-shelf product usually means buying an antiquated approach with excessive vendor lock-in. The result is spending months modeling data to fit the vendor’s schema and ending up with the same solution as every other customer.
Data acquisition is the biggest reason viable data projects fail. Ingesting new data sources does not need to take weeks. Following the right architecture principles, new data sources can be ingested in hours or days. When that problem is solved, the risk profile of the entire project changes.
The Discovery Workshop Made Simple: A Step-by-Step Guide
A discovery workshop sets a project up for success by aligning the team on a common vision, ruthlessly prioritizing only what is needed, and moving from discovery to development in a single day. The step-by-step process covers product vision, press release, elevator pitch, success sliders, pragmatic personas, user story mapping, prioritization, user stories, and team charter.
Your Complete Project Discovery Kit
About this Guide
What is Product Discovery?
Product discovery is the process of determining how a product will improve the world, who the customers are, what success looks like, and what the minimum work is to build a product customers will actually use. A product discovery workshop produces all of this in a structured, one-day session.
Who is the Guide For?
The guide applies to Product Owners, project leads, Scrum Masters, agile coaches, facilitators, developers, and stakeholders preparing for a workshop — whether new to agile or experienced, whether developing software or other products, plans, or research programs.
What’s in the Guide?
The guide includes an example discovery workshop agenda, step-by-step instructions for running each activity, templates, example deliverables, alternative activity options, and facilitation tips.
Running the Workshop
The one-day agenda is designed to reach a point where development can begin the very next day. The agenda is a starting point — facilitators select the activities that best fit their project and pull in others as needed.
Product Vision
Who Delivers the Product Vision?
The Product Owner delivers the product vision, ideally alongside a senior leader or chief executive to signal organizational commitment. The presentation links the project to the organization’s strategic priorities.
Painting a Picture of a Better World
The product vision explains why the product is being built. A strong vision presentation describes a future state, makes it memorable through a real customer story, focuses on outcomes not features, gives the team a reference point for decisions, and gets the team engaged. The presentation runs 45 minutes and ends with a Q&A.
Press Release
The Press Release Template
The press release template follows Ian McAllister’s Amazon approach, covering the product’s headline, the problem it solves, how it solves it, a customer quote, a call to action, and a closing summary.
How to Run the Activity
Set the scene by asking participants to imagine the product is already live and a newspaper has picked up the press release. Divide the group into teams of 3–4, give each team a large sheet of paper and markers, distribute the template, describe each section, and give them 20 minutes to complete it. The conversation during the activity is as valuable as the output.
Example Press Release
Each team presents their release to the full workshop in 2 minutes. The group then identifies common themes, differences, surprises, and new opportunities. Facilitators photograph each release and, where teams like their result, a transcript is circulated internally.
What to Do With Your Releases
If multiple releases exist with no standout, the elevator pitch activity distils them into a single shared vision for the product.
Elevator Pitch
Elevator Pitch Template
The elevator pitch template follows Geoffrey Moore’s structure from Crossing the Chasm: For [target customers] who are dissatisfied with [current alternative], our product is a [new product category] that provides [key problem-solving capability]. Unlike [the alternative], our product [describes key features].
Example Elevator Pitch
For toast aficionados who are dissatisfied with bread you need to cut yourself, our product is a pre-sliced loaf that provides uniform slices straight from the packet. Unlike uncut bread, our product saves time and delivers a consistent toasting experience.
How to Run the Activity
Show the template to the full group, explain the purpose, walk through each element, collect suggestions for each element in turn, then finalize based on consensus. The activity runs 30 minutes.
Tips for Facilitators
The facilitator captures suggestions as the team calls them out and identifies consensus from the discussion. Watch for participants fixating on individual words — listen for the core idea and offer alternative phrasings to keep the session moving.
Success Sliders
How to Run the Activity
Set Up
Draw a grid of 6 rows by 5 columns on a whiteboard or poster. Label the 6 rows with success factors — common options include scope, schedule, budget, quality, team satisfaction, and client satisfaction. Number the columns 1–5 and place a sticky note in column 3 of each row.
Prioritise Your Success Factors
The team works together to assign each factor a priority value from 1–5. The total value of all factors must equal 18. Raising one factor requires lowering another. This constraint forces genuine trade-off conversations and produces agreed priorities that reflect real project constraints.
Online Success Sliders Tool
Mountain Goat Software provides an online Success Sliders tool accessible on a large screen, usable for remote or hybrid workshops.
Pragmatic Personas
Pragmatic Personas Template
The pragmatic personas template follows Jeff Patton’s approach, covering name, picture, context, about, and implications for each persona type.
Why These Personas are Pragmatic
Pragmatic personas are quick to produce, collaborative, use existing customer knowledge, and generate something the team can refer back to throughout development. Dense research data becomes accessible and actionable in 45 minutes.
How to Run the Activity
Pass around the template, brainstorm key customer types as a group, and select the top 3. Split into groups for multiple personas — one persona per group — then present each persona to the full workshop. Capture and display personas where the team and stakeholders can reference them.
Tips on Filling in the Template
Name
Use alliteration to make names memorable — for example, Tony Toastmaker.
Picture
Drawing the persona brings the character to life and makes it easier to reference throughout the project.
Context
Keep context to a few bullet points.
About
List only characteristics relevant to the product being designed.
Implications
Avoid listing features — this section describes implications for the design, not a feature list.
Example Persona
An example persona PDF is available as part of the complete discovery workshop kit.
Prioritising the Personas
Rank personas by importance as a group. Assign each persona a different coloured dot. These dots get applied to user stories later in the day to show which stories serve the most valued customer type.
User Story Mapping
How to Run the Activity
User story mapping produces a visual chart of all user stories organized by epic and user task, giving the development team a structure to guide their work.
1. Brainstorm All the User Tasks
Silent brainstorm. Each participant writes every step the user will take through the product on a separate sticky note, starting each with a verb. Focus on breadth, not depth.
2. Organise the Tasks into the Order the User Will Complete Them
Arrange all sticky notes in chronological order in a horizontal line. Duplicates go beside each other, not above or below.
3. Group the User Tasks into Wider Goals
Identify logical groupings within the task line. These groups become epics. Label each epic with 3–5 words starting with a verb, and place the label above the tasks it covers.
4. Break Down the Epics into User Stories
Second silent brainstorm. For each epic, participants write down everything the team needs to build to let the user achieve that epic’s goal. Each item becomes a user story stub.
5. Place User Story Stubs Under the Relevant Epic
Post user story stubs under the corresponding epics. Remove duplicates, choose the best version, and walk the full map looking for gaps.
Prioritise User Stories
Prioritise User Stories with Personas
Apply each persona’s coloured dot to the user stories that primarily benefit that persona. Stories serving the top-priority persona become the first candidates for the MVP.
Prioritise User Stories with MoSCoW and the MVP
Apply MoSCoW (Must, Should, Could, Won’t) categories to all user stories. Move Musts above the top line of tape on the wall. Move all other stories below, grouped into Shoulds, Coulds, and Won’ts. The collection of Musts at the top is the MVP.
The Secret to Prioritising User Stories
Be ruthless. The only question that matters is whether the customer can still achieve their goal without a particular story.
Next Steps
Record all epics and user stories. Non-MVP stories go into the backlog as stubs. This shared understanding of what is important guides the first development iteration.
User Stories
Capturing the Customer Benefits in User Stories
The user story formula is: As a [actor], I want [action] so that [achievement]. The actor is a user type or persona, the action is what the user wants to do, and the achievement is the benefit the user will gain. User stories for the MVP are the last activity written before development begins.
Team Charter
What to Include in Your Team Charter
A team charter covers values, behaviors, meeting details, technical practices, communication tools, and roles and responsibilities. It does not duplicate the product vision, definition of done, or technology choices. A charter too long to remember is too long.
How to Draft a Team Charter
The team — including the Product Owner — drafts the charter with the facilitator. Stakeholders from earlier in the day are not needed. The facilitator asks open questions rather than making suggestions: How do we know if someone needs help? How do we want to handle electronic devices in meetings?
Make the Team Charter Visible
Keep both a physical copy beside the project board and a digital copy for remote team members. The physical copy keeps the charter in front of the team every day.
Company Team Charter
In addition to a project-level team charter, organizations benefit from an overall team charter covering how the team works together as a unit across all projects.
You’re Good to Go
At this point, the team knows why the product is being built, who it is being built for, what the MVP looks like, and how the team will work together. Development begins the next day.
Learn More About Running Your Project Kick-Off Workshop
Additional guidance is available on each activity in the discovery workshop, including product vision presentations, press release templates, elevator pitch tips, pragmatic persona templates, user story mapping, story prioritization, success sliders, user story writing, and team charter creation.
Want Help Running Your Workshop?
A facilitated discovery workshop takes the planning load off the team and produces a structured session with proven activities. Discovery workshop facilitation is available for both in-person and remote teams.
Conclusion
A discovery workshop is the most reliable way to start a project correctly. Without one, teams run into miscommunications, miss unknowns that hamper delivery, and build solutions that do not match what stakeholders actually needed. With one, teams align on scope, agree on priorities, validate ideas before committing to them, and begin development with a shared, documented understanding of what success looks like. Every data project, product build, and digital transformation initiative deserves a discovery workshop before any other work begins.
