# Product workshop Map user needs and journeys to decide what a product should do. **TL;DR** Follow a real person through a real task, find the friction, and choose what the product should do first. A feature wish list is welcome to attend. It does not get the deciding vote. Status: Workshop method ## Before you start For: Product, design and engineering leads Use when: A feature backlog has obscured the work the product needs to support. Bring: User evidence, support themes, product constraints and someone accountable for prioritization. Leave with: A prioritized job list, journey and explicit exclusions. ## Worked example (fictional) A fictional inspection team requests a dashboard. The job is ‘find unreviewed images before sign-off’; the first prototype becomes a review queue with clear status. ## Check the result Every ‘now’ item names a user, evidence and a first-value moment. ## Limitations A room of stakeholders is not a substitute for observing users. Test the chosen priorities afterwards. 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. ## Prepare 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. ## Jobs & pains brainstorm · 30–45 min 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. ## Now, next, never · 30–45 min 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. - 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. ## Journey mapping · 30–45 min 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. ## Distilling into principles · 30–45 min 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. - More like a checklist than a dashboard - More like Stripe than Salesforce - More like a thermostat than a cockpit - More like WhatsApp than Slack ## Output 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. ## Handoff Record the input sources, decisions, assumptions, owner and acceptance checks. Have the responsible person approve the record before downstream automation. ## Tools, in order ### Before the session [Notion](https://www.notion.com/) · 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. ### In the room [Notion AI Meeting Notes](https://www.notion.com/help/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. ### After the session [Claude](https://claude.ai/), [ChatGPT](https://chatgpt.com/), or [Grok](https://grok.com/) · [Notion](https://www.notion.com/) 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. For this method: Can you complete the intended task, and where does the prototype ask you to guess? ### 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. Keep with a person: Interpreting disagreement, choosing a direction, and deciding what participants actually approved stay with the facilitator and decision owner. [Sequence prompts, then delegate](https://noord.dev/polder/delegating-with-prompts) [Choose a model for the design task](https://noord.dev/polder/choosing-design-models) Source: https://noord.dev/polder/workshop-product Public working material from Noord. Third-party code, fonts and assets retain their own licenses. Publication does not imply a license to redistribute third-party material.