Discovery

Discover what your product can really be, then agree on it. Use it after Setup, before brand, analysis or design work begins.

Serras at Work · Episode 2 · Reviewed October 9, 2026

Book a demo

Discovery is one of 25 Shape workflows.

You give it

Your client’s documents, notes and links
Your existing codebase, if there is one

You decide

You approve the discovery, approve it with edits, or hold it for review.

You get

Product vision, users, journeys and scope boundaries
A product narrative and a market strategy that states how it could lose
Information architecture: key objects, vocabulary and navigation
An independent review that challenges the findings
One approved discovery for the stages that follow

Before you build faster, decide what should exist.

Episode 2 of Serras at Work shows how the Discovery workflow turns everything you have into one approved answer.

Open on YouTube ↗

How do you turn scattered ideas into a decision your team can act on?

Building is getting faster. That makes the first question more important, not less: what should you build? A fast build in the wrong direction only gets you to the wrong place sooner.

The Serras Discovery workflow answers that question before anyone designs or builds. It helps you discover what your product can really be, which is often more than one person would find alone. Then it helps you agree on it.

Start with everything you already have

Discovery starts with what you have, in whatever shape it is in. One document or hundreds: a brief, meeting notes, research, links, and the existing code when there is an app already.

Every source is read and recorded with a fingerprint of its exact contents, so any line in the result can be traced back to the file it came from. For serras.ventures, the source record lists 89 files, each with its fingerprint.

Five lenses, from the big picture down to the detail

Each lens is a full document, and each one starts from what the one before it found.

Vision.The big picture: what this could become, why it deserves to exist, who benefits, and what it must refuse to become.
Product.Who it serves and how it should work for them: the people, their jobs and pains, the capabilities, journeys and rules.
Narrative.How you will talk about it: the arc from problem to transformation, the proof each claim needs, and the claims you must never make.
Strategy.Where it fits in the market: how it can win, the real alternatives a customer has, and the conditions under which it would lose.
Information architecture.How it is organized and named: the object model, the vocabulary, the content hierarchy and the navigation.

Conflicts are recorded, never settled quietly

Sources disagree. A brief says one thing, an older document says another, and a lens finds a problem nobody had written down. Discovery records every conflict and settles none of them on its own.

28 conflicts recorded.

In the serras.ventures baseline: 16 found between the sources, 9 found by the lenses and 3 found when everything was brought together. Each stays visible in the approved baseline with its status.

One was a single word. In the brief, a partnership meant a founder's venture. On serras.ai, partners already meant development firms. Left alone, that word would have confused both audiences.

An independent review challenges the work

Before anyone approves anything, a reviewer who took no part in the work reads it cold and challenges it. For serras.ventures, the review returned 35 findings: none critical, 3 high, 16 medium and 16 low.

When there is an app already, the review reads the code too. In one existing app, a draft treated the users' mood notes as Apple Health data. The code showed that the app saves those notes itself, so the draft was corrected before approval.

The questions come to you, then you agree

As findings appear, the questions come to a person: a choice to confirm, a gap to fill, a preference only you can set. Each one arrives in the Symphony decision screen with the options and a recommendation.

The recommendation is advice, not a decision. For serras.ventures, the team chose a different main-button label than the one Serras recommended, and that choice went into the baseline as written.

When the questions are answered, one approval freezes the shared understanding. You can approve it, approve it with edits, or hold it for more review. Nothing moves to the next stage until a person approves it.

Written for people, and for machines

What comes out is one approved baseline: the vision, the people it serves, their journeys, what it can do, and what it must never do. Open questions stay visible in it, never hidden to make it look finished.

Symphony writes the baseline twice: once for people to read, and once as machine-readable files in which every statement has an ID, a status and a pointer to its source. In the serras.ventures baseline, all 354 statements carry those pointers. Every later stage reads from the same approved answer, so each one starts from exactly what you agreed.

What Discovery does not do

It does not decide for you. Every material choice goes to a person.
It does not hide disagreement. Conflicts, assumptions and research needs stay visible.
Approval does not prove how the product will perform. It records what you agreed to build and why.

A short checklist before you build

Every source has been read, and each claim traces back to one.
The idea has been looked at from the big picture down to the detail.
The conflicts are written down, not quietly settled.
Someone outside the work has challenged it.
If there is code already, it has been checked against the plan.
A person has made every material choice.
There is one approved answer that every later stage will use.

Transcript

Read the transcript

0:04 Building is getting faster. That makes one question matter more than ever: what should you build?
0:13 Start with the big picture. Discover what your product can really be. Then agree on it, together.
0:22 This is the Serras Discovery workflow. It helps you discover what your product can really be, which is often more than you would find alone.
0:32 Why not hand the idea straight to an AI and start building? Because it builds only what you asked for. Discovery shows you what it could be.
0:43 It starts with what you already have. One document or hundreds: the brief, the notes, the links, and the code, if there is one. Everything flows into one place.
0:58 Every source is read and fingerprinted, so any line in the result traces back to where it came from.
1:07 Then it studies everything through five lenses, from the big picture down to the detail. The vision: what this could become. The product: who it serves, and how it should work for them. The narrative: how you will talk about it. The strategy: where it fits in the market. And the information architecture: how it is organized and named.
1:33 Along the way, it records every place the sources disagree, and every new conflict a lens uncovers, and settles none of them quietly. For serras.ventures, there were twenty-eight.
1:48 Then a reviewer who took no part in the work reads it cold and challenges it. Here: thirty-five findings, three of them high.
1:57 If there is an app already, the review reads the code too, and corrects any draft the code does not support.
2:07 As findings appear, the questions come to you: a choice to confirm, a gap to fill, a preference only you can set.
2:17 Each one comes with the options and a recommendation, and the choice is always yours.
2:26 Then you agree. One approval freezes the shared understanding.
2:33 What comes out is one approved baseline: the vision, the people it serves, their journeys, what it can do, and what it must never do.
2:43 Symphony writes the result twice: once for people, and once as machine-readable files in which every statement points back to its source. Each later workflow starts from exactly what you approved.
2:59 Every stage that follows builds on what Discovery finds.
3:06 Let Serras help you discover what is truly possible.
3:13 See the example, and the Discovery workflow, at serras.ai.

Questions

What do we need to bring to Discovery?

Your client's documents, notes and links, and the existing codebase if there is one. It can be one document or hundreds.

Who answers the open questions?

You do. Each question comes with the options and a recommendation, and the choice is yours. A choice that is not ready can stay open, and it stays visible in the baseline.

What do we approve?

The discovery itself. You approve it, approve it with edits, or hold it for review.

What happens after Discovery?

Every later stage starts from the approved baseline. Discovery runs after Setup and before any brand, analysis or design work.