Product workshop

What it is for

A backlog makes every idea look like work waiting to happen. Before adding to it, walk through what someone is trying to accomplish with the product. Where do they stop? What do they do outside it?

Bring the people who understand the users and the people who will build the answer. Use the session to choose which problem deserves attention first. If the evidence is thin, the next step may be to learn something before making something.

What the product is for — jobs, pains, and priorities.

Tools, in order

Here is where each tool helps. Use an equivalent you already work with if it fits the task and your project’s access requirements.

1. 01

   Before the session

   Notion · Paper or a shared workshop board

   Bring user evidence, support themes, and the constraints behind the current backlog. Put the decision you need on the first page. Agree on recording, transcription, access, and retention with everyone before starting; handwritten notes are a valid alternative.

   Carry forward A brief, a prepared board, and an agreed capture method.

2. 02

   In the room

   Notion AI Meeting Notes · Paper or a shared workshop board · Phone camera

   Use the recorder to support listening, not to replace a facilitator. Map the person's job and the moments where they get stuck; distinguish requests from observed needs. Write decisions and disagreements visibly; photograph the boards with permission. Pause recording whenever someone asks.

   Carry forward Authorized source notes, a transcript if agreed, and labeled board photos.

3. 03

   After the session

   Claude, ChatGPT, or Grok · Notion

   Check speaker names, quotations, numbers, and apparent agreements against the sources. Ask an assistant to draft a prioritized journey and a first-prototype brief, with a source ID for each decision and a separate list of open questions. Have participants correct the record before using it as a brief.

   Carry forward a prioritized journey and a first-prototype brief

Review the work with partners

We make and revise the work with Claude, ChatGPT, or Grok, then put selected versions on our Studio project pages for partners to review. Check the preview before sharing it. You can do the same with a private prototype or shared document; use a workspace that can access the files you need.

Name the version, say what changed, and ask the question you need answered. Keep feedback with that version and discuss conflicting requests before making the next changes. Confirm approval separately, and keep confidential work in a restricted space.

Delegate the routine work

Turn verified notes into a source-linked table, label board photos, or format the agreed action list. Give the agent only the relevant excerpts and a completed example.

Interpreting disagreement, choosing a direction, and deciding what participants actually approved stay with the facilitator and decision owner.

Sequence prompts, then delegateChoose a model for the design task

Prepare the room

2 × 90 min

Get the people who touch the product: founders, product and engineering leads, design, and whoever talks to customers all day: support, sales, success. They know what users actually say.

Keep it under ten people. Product discussions go deep quickly, and depth matters more than coverage here.

• A 90-minute block, whiteboards, stickies (40 per person), Sharpies, the same kit as the brand sprint.
• Bring evidence into the room: support tickets, churn reasons, usage numbers, sales objections.
• Set the frame before starting: we're describing what the product is for, not designing screens.

Step 1 · 30–45 min

Jobs & pains brainstorm

Use two sticky colors. On the first: every job users hire the product for — 'get paid faster', 'prove compliance', 'look prepared in the Monday meeting'. On the second: every pain around that job — what's slow, confusing, manual, or scary today. One job or pain per sticky, said out loud as it lands.

Push past features. 'Dashboard' is not a job; 'know if we're okay without asking anyone' is. Include provocations here too: jobs for users you don't serve yet, pains nobody wants to admit to.

Run 10-minute rounds until two full minutes pass without new ideas.

Step 2 · 30–45 min

Now, next, never

Three columns on the board: Now, Next, Never. Place every sticky as a group. Now means the product has to do this job well today; Next means it comes after Now is true; Never means the product is explicitly not for this, and writing that down is worth a lot.

Expect disagreement; that's what the sorting is for. When a sticky won't settle:

End the session with a photographed board. If the Now column holds more than a handful of jobs, the choosing isn't done yet.

When a sticky gets stuck

• Ask who feels this pain — if it's a segment you wouldn't take on, it belongs in Never.
• Ask what breaks if the product never does it — 'nothing' is an answer.
• Separate the job from the feature request — users ask for features but hire for jobs.
• Ask whether anyone would pay for this alone.
• Skip it and come back — a later sticky often settles it.

Step 3 · 30–45 min

Journey mapping

Second session. Draw the user's path across the board: arrive, evaluate, adopt, use weekly, renew or leave. Place the Now and Next stickies where they happen on that path. Clusters and gaps show up immediately: three stickies at adoption and nothing at renewal tells you something.

Name each stage in the user's words. Mark the moment of first real value and count the steps it takes to get there. Every step before it is a cost.

Step 4 · 30–45 min

Distilling into principles

Transpose the board into a document: the product principles (how this product makes decisions, four maximum), the Now list in priority order, the Next list with a trigger attached ('after 100 paying teams'), and the Never list with reasons.

Close with product comparisons in the same "more like ___ than ___" format, using products everyone knows, ideally outside your category. They anchor scope the way brand comparisons anchor tone.

Comparison examples

• More like a checklist than a dashboard
• More like Stripe than Salesforce
• More like a thermostat than a cockpit
• More like WhatsApp than Slack

What comes out

• A product brief: the principles, a prioritized Now/Next/Never list with reasons, and a journey map with the first-value moment and the gaps marked.
• It feeds the proposal directly: scope comes from Now, phases from Next, and the Never list keeps the engagement honest about what's out.

Leave the next person enough to work with

Write down what was decided and why, with links to the notes or examples behind it. Keep the open questions alongside the decisions. Someone joining the project should be able to tell which is which without asking you.

Project: [name]
Input sources: [references and permission]
Approved decisions: [choice, rationale, owner]
Assumptions: [what remains untested]
Open questions: [question, owner, due date]
Acceptance checks: [observable pass/fail criteria]
Next step: [person or workflow]
Approval: [name, date, version]

Before you move on

• Can someone who was not in the room understand the result?
• Are claims supported by evidence, with uncertainty labeled?
• Has the responsible person approved the decisions—not just received the document?
• Have you removed private information and checked rights to any assets?

If the summary says something was agreed and you cannot find that agreement in the notes, ask the person who decides before carrying it into the next task.