# How to Run a Product Discovery Workshop That Actually Defines Scope > A step-by-step guide to running a product discovery workshop that aligns stakeholders, surfaces real requirements, and prevents scope creep before a line of code is written. - **Published:** 2025-02-01 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** product-discovery, scoping, workshops, requirements - **Canonical URL:** https://clixo.sh/blog/how-to-run-a-product-discovery-workshop Most software projects drift off course before development begins. The culprit is rarely the engineers — it is the absence of a shared, written definition of what is being built and why. A product discovery workshop run before scoping closes that gap. This guide covers how to structure a discovery workshop that produces alignment, surfaces real requirements, and gives your engineering team something they can actually estimate from. ## What a Product Discovery Workshop Is For A discovery workshop is a structured session — typically two to four hours for a focused product, longer for complex systems — where the people who own the problem and the people who will build the solution get into the same room and answer hard questions together. The goal is not to design the product. It is to agree on the problem, the constraints, the success criteria, and the rough boundaries of what will be built. Without this session, teams work from assumptions. Assumptions diverge. Diverged assumptions become scope disputes mid-sprint. ## Who Should Be in the Room Pull in the minimum viable set of decision-makers: - **Product owner or founder** — can speak to business goals and user problems - **A technical lead** — can flag feasibility concerns and architectural implications early - **A designer or UX researcher** if the product has significant user-facing surfaces - **Any domain expert** whose constraints will shape the build (legal, compliance, ops) Keep the group small. More than six or seven people turns a workshop into a committee. ## The Workshop Structure ```mermaid flowchart TD A["Part 1: Problem Framing"] --> B["Part 2: User and Journey Mapping"] B --> C["Part 3: Constraint Inventory"] C --> D["Part 4: Feature Scope and Prioritization"] D --> E["Part 5: Open Issues and Next Steps"] E --> F["Written scope document"] ``` ### Part 1: Problem Framing (30-45 minutes) Start with the problem, not the solution. Ask the product owner to answer three questions in plain language: 1. What is the specific pain or friction your users are experiencing today? 2. What does failure look like if this product is not built? 3. What does success look like six months after launch — in observable terms? The technical lead's role here is to listen, not to propose solutions. The goal is to hear the problem without the filter of implementation ideas. Document every answer in writing during the session. Use a shared screen or whiteboard so the group can see the record forming. ### Part 2: User and Journey Mapping (30-45 minutes) Walk through the primary user types and their core journeys. For each user type, answer: - What brings them to this product? - What is the single most important thing they need to do? - What happens if they cannot do it? Keep the journey descriptions at a high level. You are not writing user stories yet — you are identifying the core flows that must work at launch. ### Part 3: Constraint Inventory (20-30 minutes) Constraints are as important as requirements. Document every constraint that shapes the build: - **Technical constraints**: existing systems that must integrate, languages or platforms already in use, infrastructure limitations - **Regulatory constraints**: data privacy requirements, industry-specific compliance, geographic restrictions - **Timeline constraints**: hard deadlines driven by contracts, funding rounds, or market windows - **Budget constraints**: explicit ceiling on development spend Constraints that surface during this session will not surprise you in week six. ### Part 4: Feature Scope and Prioritization (45-60 minutes) Now introduce a simple prioritization frame. List every feature or capability the product owner wants in the product, then sort each into one of three buckets: 1. **Launch-critical**: the product cannot ship without this 2. **Important but deferrable**: valuable, but the product works without it at launch 3. **Nice to have**: good ideas that should be logged for a later phase The technical lead can weigh in on relative complexity during this exercise. A feature that sounds trivial may carry unexpected integration cost. Surface that now. ### Part 5: Open Issues and Next Steps (15 minutes) End the session by listing every question that could not be answered in the room. Assign an owner and a deadline to each open question. These are the items that will block estimation if left unresolved. ## What You Should Have When the Workshop Ends By the end of a well-run discovery workshop, you should have a written record of: - The problem being solved and the user it serves - The success criteria for the first release - The core user journeys that must be supported - The constraints that will shape architecture and timeline - A prioritized feature list with clear launch-critical scope - A list of open questions with owners This is not a product requirements document — that comes next. This is the raw material a requirements author needs to write one quickly and accurately. ## Common Failure Modes **Starting with solutions.** If the first thirty minutes are spent describing the product rather than the problem, stop and redirect. A product described in terms of features rather than problems produces requirements that miss the point. **Letting one voice dominate.** If only the founder or only the tech lead is speaking, the workshop is not working. Facilitate actively. **Skipping the constraint inventory.** Teams skip this because it feels like a list of problems. It is exactly that — and the earlier problems are listed, the cheaper they are to handle. **Leaving without written outputs.** Memory is not documentation. If the outputs are not written down during the session, they will not match across participants by the following morning. ## Running Remote Workshops Remote workshops work well when facilitated deliberately. Use a shared document with the workshop agenda and output sections pre-built. Use a virtual whiteboard tool for the feature prioritization exercise. Record the session for participants who need to review it later. The same structure applies. The facilitation discipline required is higher. --- If you are preparing to scope a software product and want a structured discovery process that produces a buildable spec, [talk to Clixo](https://clixo.sh/#contact). We run discovery sessions as a standalone engagement and can take you from problem to scoped requirements in days, not weeks. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)