The Product Owner's Guide to Archgram Flow

Product owners make scope decisions under pressure. Stakeholders want more. Engineers say it is too complex. The sprint is two weeks long. In most delivery setups the PO makes those decisions with incomplete information — a Jira backlog, some user story points, and a vague sense of which features depend on which.

Archgram Flow gives product owners something they have never had before: a direct line of sight from a scope decision to the architecture it requires. Every slice — every vertical cut of functionality you plan to deliver — is linked to the diagram nodes it exercises. Cut a slice and you immediately see which components you no longer need to build for MVP. Add a slice and you see the blast radius across the architecture.

This article covers how product owners specifically use Archgram Flow — without needing to understand Mermaid syntax, read ADRs, or care about RAID logs.

Starting with the Problem, Not the Solution

The most common mistake in delivery planning is jumping to a solution before the problem is agreed. Flow enforces a different discipline. Before a single slice is created, a product owner opens Flow and creates an Initiative.

An Initiative is a one-page statement of the problem:

• What is the business problem? ("Our checkout abandonment rate is 12%. Competitors are at 4%.")
• How will we measure success? ("Abandonment below 6% within 90 days of launch.")
• What are the hard constraints? ("Must not require a native app rewrite. Budget: £200k.")
• Who is accountable? (RACI across PO, architect, and delivery manager)

Only once the Initiative is saved does the team attach architecture diagrams and begin creating slices. The Initiative is not a sign-off gate — it is a shared artefact that the whole team can refer back to when decisions get contested later.

The Slice Board: Delivery Tracking with Architectural Context

The PO's primary view in Flow is the Slice Board. Slices are vertical cuts through the architecture that deliver a unit of user or business value. Think of them as outcomes, not tasks. A single slice like "Guest Checkout" encompasses a sprint of engineering work across UI, API, and database — but from the PO's perspective it is one deliverable with one value statement.

Each slice has:

• Value statement — "As a customer, I can check out without creating an account, so that I can purchase faster."
• Acceptance criteria — the testable conditions that mark it Done
• Priority — MVP (must-have), Valuable (should-have), or Deferred
• Target milestone — which checkpoint this slice must complete by
• Linked architecture nodes — which components this slice exercises

The linked nodes are where the PO view becomes different from a standard Kanban board. When you hover a slice on the board, the corresponding nodes in the architecture diagram highlight. When you are deciding whether to defer "Apple Pay support", you can see immediately that deferring it removes the Payment Provider integration node from MVP scope — and ask the architect whether that simplifies the initial delivery.

Prioritising with Architectural Awareness

A common failure in MVP scoping is cutting features without understanding their architectural cost. Removing a feature from the backlog does not always remove its architectural complexity — sometimes the plumbing has to be built anyway.

Archgram Flow surfaces this problem explicitly. When you mark a slice as Deferred, the diagram shows which nodes are now only needed by that slice. The architect can then tell you whether those nodes can genuinely be deferred or whether they are foundational — a dependency of the remaining MVP slices even if not exposed in the first release.

This conversation — between PO priorities and architectural constraints — is what Flow is designed to enable. Not in a separate meeting with a separate diagram, but in the same tool, on the same Initiative.

Writing Acceptance Criteria That Architects Can Use

Acceptance criteria in Flow serve two audiences simultaneously. The PO writes them to define done from a business perspective. The architect links ADRs and NFRs (non-functional requirements) to the same slice, ensuring the technical conditions are also captured.

A well-written slice for a PO looks like this:

Slice: Guest Checkout
Priority: MVP
Value: As a customer, I can complete a purchase without creating an account.

Acceptance Criteria:
- [ ] Customer can enter email, shipping address, and card details without login
- [ ] Order confirmation sent to email within 60 seconds of purchase
- [ ] Cart contents persist for 24 hours in guest session
- [ ] WCAG 2.1 AA accessibility compliance on checkout form
- [ ] Payment processed in < 3 seconds at p95 under 200 concurrent users

Linked nodes: Checkout UI, Guest Session Service, Order Service, Payment Service
Target milestone: M1 — Payment Flow Live (Week 6)

The architect will attach ADRs about payment provider choice and session storage to the linked nodes. The delivery manager will add a RAID dependency on the payment gateway integration timeline. The PO does not need to manage any of this — it surfaces automatically in the same slice view.

Reading the Architecture Without Being an Architect

Product owners are not expected to read or write Mermaid code. In Archgram Flow, the diagram is an interactive surface — not source code. You interact with it by:

• Hovering slices to highlight linked nodes
• Clicking nodes to open the Flow panel for that component — showing its ADRs, RAID items, and slices
• Using zoom controls to navigate from system context (which external systems are involved?) down to container level (which services are required?)

The goal is not for POs to understand the technical design in depth. It is for scope decisions to be made with architectural cost visible — so "let's just add this feature" is answered with "here is what that touches" rather than a vague concern that gets ignored.

Tracking Delivery Progress as a PO

The Slice Board is the PO's delivery dashboard. Slices move through: Not Started → In Progress → In Review → Done. The board is grouped by milestone, so the PO can see at a glance whether the team is on track for each checkpoint.

When a milestone approaches, the PO reviews which slices are Done and which are In Progress or blocked. If a slice will not make the milestone, the PO decides whether to defer it to the next milestone (adjusting the timeline) or scope it down (reducing the acceptance criteria). Both decisions can be recorded in the slice, giving a durable record of scope changes and their reasons.

What the PO Gets at the End

When the Initiative closes, the PO's contribution is automatically included in the Handoff Pack. The delivery/slices.md file contains every slice with its value statement, acceptance criteria, final status, and the milestone it was delivered in. For the business, this is a plain-language record of what was built and the value intent behind each piece.

The AI-generated README in the Handoff Pack synthesises the Initiative's success criteria against what was actually delivered — so the PO can send it directly to stakeholders without writing a separate release summary.

Getting Started as a PO

• Ask your architect or delivery manager to create the Initiative and attach a diagram
• Write the problem statement and success criteria in the Initiative before touching slices
• Create slices with a value statement and at least three acceptance criteria
• Prioritise as MVP / Valuable / Deferred before the first sprint
• Review the Slice Board weekly — update slice statuses and flag anything that needs scope discussion

Full documentation for the Slice Board and Initiative setup is in the Archgram Flow guide.