Start now
Back to Blog

Practical Guide•October 21, 2026•14 Min Read

Discovery Workshop Agenda: A One-Day Template That Works

Workshop agenda title card with sketch accents

A discovery workshop gives a client and delivery team time to turn a loose brief into decisions they can use: what problem needs attention, what they know about current work, which options deserve a closer look, and what remains uncertain. The 9:00 to 5:00 discovery workshop agenda below is a planning example for a creative or consulting project. It includes questions and a record of outputs, but a day in a room cannot verify every user need or settle every cost.

TL;DR

  • Choose the time and people around the decisions you need to make. For an AI-agent brief, use the AI agent discovery questions to surface boundaries; for an existing operation, use a process discovery guide to trace the work. Invite the people who can describe those decisions and constraints.
  • Use five working blocks in this sample: problem, users and current work, options, boundaries, and success measures with next steps.
  • Ask about specific past work. Record what the group knows firsthand and what still needs user research or a feasibility check.
  • Write down proposed inclusions, exclusions, assumptions, dependencies, and the person responsible for each open question.
  • Leave with a decision record and a path to a reviewed estimate. If major unknowns remain, price a discovery or staged next phase before quoting the whole project.

Table of Contents

What a discovery workshop is for

A discovery workshop is a structured working session before a team commits to a project plan and quote. It helps the client and delivery team name the problem, compare what different people know, test proposed boundaries, and assign the questions they cannot answer together. The output is a record for the next decision, not proof that the room speaks for every eventual user.

For a freelancer or small agency, that matters between the first brief and a proposal. A packaging project may need a decision on SKU count and who supplies approved copy. A motion project may need the number of cutdowns, footage access, and review rounds. Software work may depend on system access and technical feasibility. Each of those details changes the work breakdown, but a workshop can also reveal that some details are still unknown.

You might hear the session called a requirements workshop, kick-off workshop, or scoping session. The names overlap. Use the agenda to fit the decision at hand, and mark statements about users or their behavior as hypotheses until you have evidence from those users.

How long should it run?

Choose the duration after listing the questions the group must settle. Boost describes several workshop lengths; sketch the blocks you need, then allow time for the people whose perspectives matter, accessibility needs, breaks, and unresolved decisions.

For a contained brand deliverable with a clear approval route, a shorter session may be enough to agree a provisional boundary and assign follow-up research. A cross-team event or software integration may need separate sessions with operations, suppliers, or technical specialists. If you have 90 minutes, select the few decisions that matter now and schedule the rest. Do not rush uncertainty into a fixed quote simply to finish the agenda.

Before the day: preparation that decides the outcome

A little preparation lets the group spend its time on decisions instead of reconstructing the brief.

  1. Name the purpose and expected output. For example: "Map the current packaging approval process and identify what we still need before estimating the SKU rollout." That is more usable than "align on the project."
  2. Invite the perspectives the decision requires. Include someone who can decide, someone who knows the current work, and relevant delivery or technical expertise. If an affected group is absent, plan how you will hear from them afterward.
  3. Share the agenda and ask for changes. In its scenario-planning workshops, the IMF's strategic-foresight appendix asks a supervisor to agree and communicate the agenda. For a client session, send the draft to the decision-maker and participants early enough to catch a missing question or person.
  4. Read the material already available. Bring the brief, previous research, current process notes, examples of work, constraints, and unanswered questions. Separate evidence from assumptions before the session starts.

Ask someone other than the facilitator to capture decisions and unresolved questions where possible. A separate note-taker gives the facilitator more room to listen, probe, and keep the discussion moving. Agree where the record will live and who will check it after the meeting.

The discovery workshop agenda, hour by hour

This is one example of an eight-hour elapsed day, from 9:00 to 5:00, with lunch and two breaks. The working blocks add up to 6 hours 45 minutes. The one-day agendas from Koji and Boost are useful examples to compare. Change the timing or split the sessions when the people and decisions require it.

Time Block Purpose Output
9:00 to 9:20 Welcome and ground rules Confirm purpose, agenda, roles, and decision route Shared goal and decision route
9:20 to 10:30 Goals and problem definition Describe the problem and why it matters now Draft problem statement; disputed assumptions
10:30 to 10:45 Break
10:45 to 12:15 Users and current workflow Map what is known about affected people and current work Current-state map; user questions to research
12:15 to 1:00 Lunch
1:00 to 2:30 Ideas and options Compare possible approaches and dependencies Shortlist with reasons and unknowns
2:30 to 2:45 Break
2:45 to 4:15 Scope boundary and risks Draft what is in, out, dependent, or unverified Draft boundary; assumption and risk log
4:15 to 5:00 Success measures and next steps Choose useful measures and assign follow-up Decision record; owners and dates

Treat each output as a working draft. The questions below help the group distinguish a decision from a guess.

9:00 to 9:20: Welcome and ground rules

State the purpose in one sentence. Show the blocks and their intended outputs. Name who can decide each issue and what happens when that person needs more evidence. Ask participants what they need from the day; a short round often exposes different expectations before they turn into a late argument about the proposal.

Set a simple recording rule: note a decision, its reason, and its owner. Put unresolved questions on a visible list rather than letting them quietly become assumptions.

9:20 to 10:30: Goals and problem definition

Start with the problem rather than a chosen deliverable. A client may arrive asking for an app, a new visual identity, or an AI agent. Treat that request seriously, then ask what has been happening that makes it the preferred answer. ProcessCamp's workshop example is a useful prompt for examining a proposed solution before the group commits to it.

Questions to ask:

  • What happened recently that made this work urgent?
  • Which current task, approval, or customer interaction is difficult? Can someone describe a specific instance?
  • Who is affected, and whose account are we missing?
  • What has already been tried, and what did that reveal?
  • What would we need to observe later to judge whether the work helped?

Write a draft problem statement in the group's words. If people disagree about the cause or the affected users, keep those disagreements visible as research questions.

10:45 to 12:15: Users and current workflow

Ask people who know the current work to walk through a recent example from start to finish. ProcessCamp's process workshop illustrates that kind of current-state discussion. A stakeholder's account is valuable context, but it is still different from observing or interviewing an end user.

Useful prompts:

  • Who does this today, and who receives the result?
  • Where is work repeated, handed off, or delayed?
  • Which steps depend on a spreadsheet, email, supplier, or manual check?
  • What content, data, or approvals must be supplied, and by whom?
  • What do we know from actual work, and what have we only assumed?

Sketch the steps and owners in order. Mark places where the group lacks evidence. If user behavior is central to the project, plan interviews or observation after the workshop. Koji's customer-discovery workshop guide offers prompts for that planning; decide how much follow-up research is needed from this project's unanswered questions.

1:00 to 2:30: Ideas and options

Give people a few minutes to write options independently, then compare them together. A vote can help show which options the room prefers to explore; it does not establish what users need. For each option, ask:

  • Which part of the problem would it address?
  • Who would use or approve it?
  • What delivery work does it imply?
  • Which content, access, supplier, or technical dependency could change that work?
  • What would we need to test before choosing it?

For a software integration, bring someone who can identify system and access unknowns. Record a feasibility question when it cannot be answered in the room. Our guide to scoping and estimating a software integration covers that next step in more detail.

2:45 to 4:15: Scope boundary and risks

Draw three columns: proposed in, proposed out, and needs evidence or a decision. This is where a brand team can distinguish an identity system from social templates, or an event studio can separate design work from supplier production and installation. Woyce's AI-agent workshop example also raises out-of-scope cases. Ask how an excluded request would be handled before calling the first phase settled.

Record the assumptions that affect hours, timing, or price:

  • Client inputs: Who supplies copy, artwork, data, footage, or access, and by when?
  • Dependencies: Which approvals, vendors, or systems could hold up a phase?
  • Revision rounds: How many rounds are included, and how is feedback consolidated?
  • Decision route: Who signs off, and what has not yet been agreed?

Keep open items with an owner and a date. A draft in/out list makes the later scope conversation clearer, but it cannot guarantee that new requests will not arise. For a document structure, see the scope of work template.

4:15 to 5:00: Success measures and next steps

Return to the problem statement. Choose measures that could show whether the work helped, such as time spent on an approval, completed inquiries, or errors in a handoff. Note the current baseline if it exists, who can provide it if it does not, and when to review the result. A website team may find this guide to measuring website success useful as a separate example; choose measures for this project's actual problem.

Close with a decision log: what was agreed, what is provisional, what evidence is missing, and who will do what by when. Set a date for the written summary while the discussion is fresh.

What you should leave with

The useful output is a record that someone can act on and check. STX Next's software discovery workshop article describes a problem statement, a current-state map, boundaries, feasibility, and measures. Use those prompts to make the record specific to your project:

  1. A problem statement and decision log. Show what the group agreed and which statements remain disputed, so the proposal does not quietly present every opinion as settled fact.
  2. A current-state map. Note who does the work, where handoffs happen, and which user perspectives still need research.
  3. A draft boundary. Record proposed deliverables and exclusions, plus the decisions needed before either can become a firm commitment.
  4. Dependencies and risks. Give each unresolved access, supplier, technical, or approval question an owner and a date.
  5. Measures and next steps. Name what would count as progress, whether a baseline exists, and when the team will decide what to do next.

Then turn the supported parts into tentative phases, roles, and estimated hours. If discovery exposes an important unknown, a separate research or feasibility phase may be the honest next quote. For a first product release, use this walkthrough of startup product development steps to think through how the known scope could become an MVP plan while owners investigate the open questions.

Discovery workshop questions to keep on hand

Keep a few prompts near the agenda. Use them when an answer gets vague, and ask for an example before turning a statement into a project assumption.

Business and goals

  • What prompted this request now?
  • What deadline matters, and what creates it?
  • Is there a budget range to design the next phase around?

Users

  • What did someone try to do the last time this problem occurred?
  • Who has not yet been asked about that experience?

Constraints

  • Which brand rules, content, systems, or approvals shape the work?
  • What information or permission do we still need?

Delivery

  • Who will give feedback, and who makes the final decision?
  • What happened on a similar past project when work stalled or changed?

The last answer can reveal a concrete dependency, but check it against the current project's people and conditions before treating it as a rule.

Remote and hybrid versions

Online sessions can use the same decisions and outputs with a different pace. Miro's remote discovery template shows one way to split work into shorter sessions; use it if it fits participants' schedules and access needs. Prepare a shared agenda, space for each draft output, and an accessible way for people to contribute by speaking or writing. A camera should not be a condition for contributing. Record decisions as they happen and give absent stakeholders a clear way to review them.

Our perspective: price after discovery, not before

The point of this workshop is to make the next pricing decision more informed. A useful record separates known work from assumptions: approved packaging variants from still-pending copy, for example, or a motion edit from a shoot that has not been confirmed. That distinction helps a team decide what it can estimate now and what needs more discovery.

Workshop decisions and open questions lead to a reviewed scope and price after discovery

Write the proposed boundary, open questions, and decision owners while the group can check them. Then review the work breakdown and commercial inputs after the meeting. When an access constraint, supplier cost, or user need is still unknown, keep it visible or quote a staged next phase rather than presenting the entire project as settled.

A quote is easier to discuss when its phases, tasks, roles, hours, and assumptions can be reviewed together. Our guide to creative brief to scope of work and quote follows that path.

Turning workshop notes into a priced proposal

Use the decision record to prepare a proposal after the session:

  1. Clean up the notes. Keep agreed decisions separate from assumptions and questions assigned for follow-up.
  2. Draft phases and tasks. Include the deliverables you can describe and the dependencies that affect their timing.
  3. Assign roles and hours. Use the team's real cost and rate inputs, then review direct expenses and a contingency that reflects named risks.
  4. Check the quote. Review labor, overhead, direct costs, contingency, and target margin against the work and the client's stated budget.
  5. Export only after review. Make the scope boundary, assumptions, and revision rounds clear in the proposal. If the open questions could materially change the whole estimate, propose a discovery or feasibility phase first.

If your workshop notes are ready, paste the cleaned brief text into Roadbase or attach a PDF. It can draft phases, tasks, roles, estimated hours, and timing for you to review and adjust. Explicit budget, deadline, review-round, and exclusion language can be carried into that draft, so confirm those details before you price the work. Review the labor, overhead, direct costs, contingency, and target margin with your own rates, then export the reviewed plan and quote as a proposal PDF. Explore Roadbase to start with your brief; the plans and pricing page has current options. For the planning method, see the six-step AI project scoping playbook.

Common mistakes to avoid

  • Choosing a headcount by rule. Invite the people needed for the decisions and find another way to hear from anyone affected who cannot attend. A larger group may need a different format or more facilitation.
  • Starting with the deliverable. Ask what happened in the current work before the room settles on a design or feature.
  • Leaving decisions ownerless. Record who can approve a boundary and who will answer the questions the group cannot settle.
  • Hiding discovery effort. If the unknowns require interviews, supplier input, or a technical check, make that work a visible phase with its own scope and price.
  • Skipping the written follow-up. Check the record with participants, including assumptions and unresolved questions, before turning it into a proposal.

FAQ

What should a discovery workshop agenda include?

Include a clear purpose, the people and decisions needed, time for the current problem and work, a way to compare options, a draft boundary, and a closing record of owners and next steps. Give each block an intended output, and leave room to mark an answer as unverified.

How many people should attend?

Invite the people needed to describe current work, expose constraints, and make the decisions at hand. A process discovery workshop example may suggest a small group, but there is no universal number for every client session. If others need to be heard, gather their input separately or plan another session.

Is there a difference between a discovery workshop and a requirements workshop?

The terms overlap. A requirements workshop often concentrates on what a proposed solution must do. Discovery starts with the problem, people affected, current work, and uncertainty before shaping requirements. You can use this agenda for either purpose by changing the questions and outputs.

What questions should I ask in a discovery session?

Ask about a specific recent instance: "Walk me through the last time this went wrong." Then ask who was involved, what information they had, what they tried, and what happened. Add questions about deadlines, approvals, budget, and constraints, and note which answers still need user or technical evidence.

Can I run a discovery workshop in half a day?

Yes, if the decisions fit the time and the right people can participate. Select the most useful blocks, record what remains open, and arrange follow-up. A longer day is also only a sample format; complexity, accessibility, and unresolved research determine what happens next.

Sources