Analysis

See how the product must behave, and what could block it, before design. Use it after Discovery to settle behavior and technical questions before Scope.

Serras at Work · Episode 13 · Reviewed October 14, 2026

Book a demo

Analysis is one of 25 Shape workflows.

You give it

Your approved discovery
Your approved brand, if ready
Your codebase and Jira or Waypoint project, if they exist

You decide

You settle each material conflict: accept the recommendation, choose an alternative, or defer it.

You get

How the product behaves: roles, rules, permissions, states and failure paths
A systems view: data, APIs, integrations and security
A feasibility and risk review of any existing code
A conflict list that keeps each viewpoint and its evidence
One approved analysis with your decisions recorded

Find the expensive unanswered questions early.

Episode 13 of Serras at Work shows how the Analysis workflow settles how your product must behave, and what could block it, before design begins.

Open on YouTube ↗

What needs to be resolved between product discovery and scope approval?

Discovery tells you what a product is for and who it serves. Scope locks exactly what it must do. Between the two sits a set of questions that are easy to skip and expensive to find late.

Who can change a quote after the client approves it? What happens when a payment fails? Who is allowed to see billing details? Often nobody asks these until the build, and by then every answer costs more.

The Serras Analysis workflow asks them early. It shows how your product must behave, and what could block it, before design begins.

Start from what you already know

Analysis starts from your approved Discovery. If your brand is ready, it uses that too. A brand that is not ready does not block it.

If you already have code, or a Jira or Waypoint project, Analysis reads them as evidence of what exists today. It reads them only. It writes no code and no tickets.

Four lenses on the same material

Four AI agents study the same material. Each one looks through its own lens.

Behavior.How the product behaves: roles, rules, permissions, states and failure paths.
Systems.How its systems and data fit together: data, APIs, integrations and security.
Feasibility.What the existing code can support, and where the delivery risk is.
Coherence.Whether it all adds up to one product, without gaps, contradictions or scope drift.

Each lens owns one question. Each agent works on its own, and none sees the others' work until its own is done. So no one simply agrees with the first answer.

Disagreement is kept, not averaged

Different lenses often reach different answers. Take one question: can a team member edit a quote after the client approves it?

The behavior view says approved quotes are locked, and a change makes a new version.
The systems view says the approved total already went to accounting, so an edit must void it and send it again.
The code view says the code today edits quotes in place, with no history.
The product view says clients expect to see what changed before they approve again.

Analysis does not average these answers away. The conflict list keeps each answer and its evidence side by side, with a recommendation and the person who owns the decision. Here, the recommendation is to lock approved quotes, so a change creates a new version that the client approves again. This example is an illustration, not a real project.

The material decisions come to you

A decision is material when it changes things like scope, permissions, data or risk. Those decisions come to you, a few at a time, in Symphony's decision window.

Accept the recommendation.Use the resolution the analysis recommends.
Choose an alternative.Pick another answer, and your reason is recorded with it.
Defer it on purpose.The question stays open and visible, so no later stage assumes an answer.

Your answer is recorded with the evidence that led to it. Later, no one has to guess what was decided or why. Low-impact questions, such as wording, do not come to you at all.

One analysis, traced back to Discovery

Everything then comes together in one analysis. It covers roles, rules, permissions, states and failure paths, data, APIs, integrations and security. Open questions and unresolved disagreement stay visible instead of being quietly filled in.

Every capability in the analysis traces back to your Discovery, with its source evidence. Nothing is added without a reason.

An auditor that did not write it

Before the analysis is approved, an independent AI auditor checks it. The auditor is a separate agent, and it did not write any part of the analysis. It does not rewrite it either; it gives a verdict: ready, ready with warnings, or not ready.

Checked in both directions.

Every journey and value commitment you approved in Discovery must have a capability that supports it. Every capability in the analysis must show its evidence. A gap in a critical capability, one the product cannot deliver its main value or a required journey without, blocks the analysis. It is never waved through as a warning.

What you get

How the product behaves: roles, rules, permissions, states and failure paths.
A systems view: data, APIs, integrations and security.
A feasibility and risk review of any existing code.
A conflict list that keeps each viewpoint and its evidence.
One approved analysis, with your decisions recorded.

Scope, design and the build all start from it. They start from answers, not guesses.

What Analysis does not do

It does not decide for you. Every material decision goes to a person.
It does not change your code, your Jira project or your Waypoint project.
It does not hide disagreement between the lenses.
It does not lock scope. That is the next workflow, Scope, which builds on this analysis.

A short checklist before you approve scope

You know who can do what, and what happens when something fails.
You looked at data, integrations and security, not only screens.
If code exists, you know what it can support and where the risk is.
More than one view looked at the same questions on its own.
Every conflict is written down with its evidence and a decision.
Someone who did not write the analysis checked it against Discovery.
Every capability traces back to what you approved in Discovery.

Transcript

Read the transcript

0:04 The most expensive questions are the ones nobody asks until the build. Who can change a quote after it is approved? What happens when a payment fails?
0:17 See how the product must behave. Find what could block it. Settle the conflicts before design starts.
0:26 This is the Serras Analysis workflow. It shows how your product must behave, and what could block it, before design begins.
0:35 It starts from your approved Discovery. If you already have code, or a Jira or Waypoint project, it reads them as evidence of what exists today.
0:47 Then four AI agents study the same material, each through its own lens: how the product behaves, how its systems and data fit together, what the existing code can support, and whether it all adds up to one product.
1:04 Each works on its own, and none sees the others' work until its own is done. So no one simply agrees with the first answer.
1:14 Where they disagree, nothing is averaged away. Take one question: can a team member edit a quote after the client approves it? The conflict list keeps each answer and its evidence side by side, with a recommendation.
1:31 Then the decisions that change scope, permissions, data or risk come to you, a few at a time, in Symphony's decision window.
1:41 Accept the recommendation, choose an alternative, or defer it on purpose. Your answer is recorded, so no one has to guess later.
1:52 Everything comes together in one analysis: roles, rules, permissions, states and failure paths, data, APIs, integrations and security. Every capability traces back to your Discovery.
2:10 Then an independent auditor, who did not write it, checks the analysis against your Discovery in both directions. A gap in a critical capability is never waved through as a warning.
2:23 What you get is one approved analysis: how the product behaves, a systems view, a feasibility and risk review of any existing code, and a conflict list with your decisions recorded.
2:38 Scope, design and the build all start from answers, not guesses.
2:45 Let Serras help you answer the hard questions early.
2:51 See the example, and the Analysis workflow, at serras.ai.

Questions

Do we need Discovery first?

Yes. Analysis starts from your approved Discovery. It uses your approved brand when it is ready, but a missing brand does not block it.

Will Analysis change our code or our Jira or Waypoint project?

No. It reads existing code and your Jira or Waypoint project only as evidence of what exists today. It writes no code and no tickets.

Who settles conflicts between the lenses?

You do. Material decisions come to you a few at a time in Symphony's decision window. You accept the recommendation, choose an alternative, or defer it on purpose, and your answer is recorded.

What happens after Analysis?

Scope builds on the approved analysis, and design and the build follow. Deferred decisions stay open and visible, so no later stage assumes an answer.