Discovery

Discovery answers the question: how do I explore a new problem space with a team?

Use this when you’re not ready to write requirements yet. Maybe you’re still figuring out the problem. Maybe you have more questions than answers. Maybe you need to align a team before anyone starts building. Discovery gives you a structured place to explore before you commit to expected behaviour.

Why Discovery Matters

Too often, product work looks like this: someone writes a spec in isolation, throws it over the wall, and hopes developers understand what they meant. Questions surface during implementation, context gets lost, and edge cases appear that nobody thought about.

Discovery flips this. Instead of documenting in isolation, you explore together. The goal isn’t to produce a polished spec on the first pass — it’s to:

• Surface unknowns early, when they’re cheapest to address
• Capture research and context that might otherwise stay in someone’s head
• Build shared understanding before anyone starts building
• Find the right problem before jumping to solutions

If you’re familiar with techniques like example mapping, discovery boards borrow from and build on those colloborative exploration practices. They encourage communication while providing enough structure to keep the conversation focused.

How It Works

Discovery uses boards with columns and cards. The structure is intentionally flexible.

Columns

Columns are buckets for organizing your thinking. What they represent is up to you:

• Rules — “Users must verify email before accessing paid features”
• Workflow steps — “Onboarding → Trial → Conversion”
• High-level acceptance criteria — “Search results are relevant”
• Themes — “Security concerns,” “UX questions”

The first column is always Context — a place to collect research, background information, and insights that apply across the whole board. This is where customer quotes, competitor analysis, and domain knowledge live. (We’re planning to add AI-assisted research here as well.)

Cards

Cards are the atomic units. There are three types:

Examples are concrete scenarios: “When a frustrated traveler searches for ‘flights to anywhere,’ they see inspiration results sorted by price.” Examples are powerful because they’re the best way to reach shared understanding — and they’re basically testable out of the box. When you eventually write a specification, your examples often become requirements.

Questions capture unknowns: “What happens if the user’s session expires mid-checkout?” Tracking open questions is wildly valuable during discovery. Even if a board does nothing but surface questions and turn them into answers, that’s useful work.

Insights capture context worth keeping visible: “The legal team requires explicit consent for marketing emails” or “40% of users abandon at the payment step.” Use these for research findings, constraints, and domain knowledge.

This “strict typing” of cards is intentional. It helps keep the conversation focused, which allows you to get more out of limited time together.

The Workflow

There isn’t a rigid process. But here’s a typical pattern:

1. Start with what you’re exploring

Create a board with a title and brief description. This can be a feature (“User authentication”), a problem (“Why do users abandon checkout?”), or a question (“How should we handle offline mode?”).

2. Collect context

Before diving into solutions, gather what you know. Customer research, analytics, constraints, prior art. The Context column is your research hub.

3. Explore together

Add columns as structure emerges. Add examples, questions, and insights as the conversation unfolds. Move things around. The board is a working document, not a deliverable.

4. Use AI to expand

The discovery assistant can suggest examples for scenarios, surface questions you might not have thought to ask, and help structure your thinking. (It’s a collaborator, not a replacement for the team.)

5. Refine until you’re ready

Keep going until the team feels like they understand the problem space. It’s a good idea to timebox collaborative sessions (25 minutes is typical), but boards can also evolve over weeks as research continues.

From Discovery to Requirements

Discovery helps you explore; requirements help you specify.

Once you’ve mapped out the problem space, you can synthesize what you’ve learned into formal requirements. The examples on your board often translate directly into the specific criteria that developers will test against.

This transition from discovery to requirements is coming soon as an AI-assisted workflow. For now, use the insights from your board to inform the requirements you write in the document composer.

When to Use Discovery

Good triggers:

• “We need to build X” but nobody’s aligned on what X actually means
• You have more questions than answers about a problem space
• A team needs to get on the same page before writing specs
• You’re doing customer research and need somewhere to collect findings
• You want to explore before committing
• It would be helpful to have structure for brainstorming

Next Steps

• Try it out — Create a board in the Discovery tab  and explore a feature with your team
• Learn the tool — See Discovery Boards for the full UI reference
• Write requirements — When you’re ready to specify, see Requirements