Three Roles, One Initiative: How Flow Aligns Product, Architecture, and Delivery

Imagine a Tuesday afternoon three weeks into a new initiative. The product owner has just decided to defer Apple Pay support to phase two. The architect realises that decision changes the payment provider abstraction they were about to design. That abstraction change eliminates a RAID dependency the delivery manager had logged against the Stripe SDK release date. One scope decision cascaded into an architectural decision that resolved a delivery risk — in ten minutes, without a meeting.

This is what Archgram Flow looks like when all three roles are working in the same Initiative. The PO, architect, and delivery manager each have their own primary view — Slice Board, Diagram, and Timeline — but they are all looking at the same underlying data. A change in one view surfaces immediately in the others.

This article covers how the three roles interact inside a single Flow Initiative — the shared ceremonies, the handoff moments, and the emergent conversations that only happen when architecture and delivery share one surface.

The Shared Surface

Archgram Flow has three primary views, each optimised for a role:

• Board (PO) — slices organised by milestone, with architecture node highlighting on hover
• Diagram (Architect) — the architecture with ADR and RAID indicators on each node
• Timeline (DM) — workstreams, milestones, and confidence scores across the delivery

The views are not separate tabs in different tools. They are three lenses on the same Initiative data. When the architect creates an ADR on the Payment Service node, a badge appears on that node in the PO's slice hover. When the DM logs a risk against the same node, the architect sees a risk indicator in the diagram. When the PO moves a slice from MVP to Deferred, the architect's node immediately shows the reduced scope.

The Initiative Kickoff: Three Roles, One Conversation

The most important moment in a Flow-based delivery is the Initiative kickoff. Before a single slice is created or a single ADR is drafted, the three roles sit together — physically or virtually — with the Initiative open in Archgram.

The PO writes the problem statement live. The architect generates an initial system context diagram using AI — 90 seconds for a first draft. The DM sets the milestone dates. By the end of a 90-minute session, the Initiative has:

• A problem statement and success criteria that everyone has read and agreed to
• A system context diagram showing the external actors and system boundaries
• Three or four milestone dates with initial confidence scores of 70–80%
• The first set of slices (MVP vs. Valuable vs. Deferred) linked to diagram nodes
• One or two Proposed ADRs for the most significant early decisions

This is not a long planning ceremony. It is a focused working session with a shared artefact at the centre. The Initiative document that results is the single source of truth for the delivery — not a slide deck, not a confluence page, not a Jira epic description.

How Decisions Flow Between Roles

The most valuable interactions in Flow happen at the boundaries between roles. Here are the most common patterns:

Scope decision triggers architectural decision

The PO adds a slice: "Real-time order tracking on mobile." The architect hovers the slice and sees it links to nodes that currently do not include a WebSocket server. The architect creates a new ADR: "Real-time communication: WebSockets vs. SSE vs. polling." The ADR is Proposed; the architect asks the PO to comment on latency expectations in the Consequences section. The PO adds a note: "Customer research shows 5-second update frequency is acceptable." The ADR is approved with a decision to use Server-Sent Events — simpler than WebSockets for a one-direction push.

Architectural decision triggers RAID item

The architect approves ADR-005: "Use Confluent Cloud for event streaming." The DM notices the linked node (Event Bus) and creates a RAID dependency: "Confluent Cloud enterprise account requires procurement approval — 3-week lead time." The DM logs it as a Dependency, links it to the Event Bus node, and sets the expected resolution date. The DM reduces the M2 milestone confidence from 80% to 65% until the procurement is confirmed.

RAID risk surfaces scope conversation

The DM logs a Risk: "Auth Service team unavailable for two weeks due to critical incident in production system." The risk is linked to the Auth Service node. The PO sees the risk indicator on the slice that requires Auth Service (User Registration). The PO defers User Registration to M2 and moves a lighter slice (Public Product Catalogue) to M1 instead — maintaining the milestone date without requiring Auth Service to be ready.

The Weekly Cross-Role Sync

With Flow, the weekly delivery sync changes from a status reporting meeting to a decision-making session. The three roles open the same Initiative and walk through:

1. Slice Board (PO leads, 10 min) — which slices moved to Done? Which are blocked? Any scope changes needed before the next milestone?
2. ADR review (Architect leads, 10 min) — any ADRs in Under Review that need a decision? Any architectural changes that create new decisions? Any nodes whose design has changed and whose ADRs need updating?
3. RAID and confidence (DM leads, 15 min) — open RAID items reviewed. Confidence scores updated live in the meeting. Any items that require escalation are flagged immediately.

The meeting ends with a shared view of the Initiative that is already updated. No minutes, no action items, no follow-up email. The artefact in Archgram is the record.

Navigating from Any Role to Any View

One of the quieter benefits of shared data is cross-role navigation. An architect reviewing ADR consequences can click through to the slice that motivated the decision and see its acceptance criteria. A PO questioning a deferred slice can click the linked node and read the ADR that explains why the component is more complex than anticipated. A DM setting milestone confidence can click a RAID risk to see which architectural node it affects and which slices depend on that node.

This navigation eliminates the most time-consuming part of cross-functional delivery: translating between the PO's language (user value, slices, priorities) and the architect's language (nodes, decisions, trade-offs) and the DM's language (risk, dependencies, dates). In Flow they are the same language, viewed from different angles.

When the Team Is Smaller Than Three Roles

Not every team has dedicated people in all three roles. Flow works well with combined roles:

• Architect-PO: common in early-stage startups. The architect also defines slices and prioritises. The key discipline is still to create the Initiative and problem statement first, before designing the solution. Flow's node-linking between slices and ADRs is especially valuable here — one person can see the full picture of what they are committing to build.
• Architect-DM: common in consulting and SI engagements. The architect manages both the technical design and the delivery tracking. RAID items linked to architectural nodes is particularly useful — the same person who designs the system is best placed to assess the risks against it.
• Tech lead as all three: for solo engineers or very small teams, Flow is usually more than needed. The simpler Archgram workflow — diagrams-as-code with AI generation and GitHub Sync — is typically sufficient without the full Flow layer.

The Handoff Pack as a Team Artefact

When the Initiative closes, the Handoff Pack is generated by a single click but it contains the contributions of all three roles:

handoff-checkout-v2/
├── README.md              ← AI narrative from all three roles' data
├── architecture.svg       ← Architect's final diagram
├── architecture.mmd       ← Mermaid source
├── decisions/             ← Architect's ADRs in MADR format
│   ├── adr-001-stripe.md
│   ├── adr-002-sqs-notification.md
│   └── adr-003-postgresql.md
└── delivery/
    ├── slices.md          ← PO's slices + AC + final status
    ├── raid.md            ← DM's RAID log (all items, including resolved)
    └── milestones.md      ← DM's milestone history + confidence charts

The README reads as a unified delivery narrative — not three separate reports stapled together. The AI synthesises the problem statement (from the Initiative), the key decisions (from ADRs), the scope that was delivered (from slices), the risks that were managed (from RAID), and the recommended next steps. A new engineer joining the team six months later can read this document and understand the delivery in 20 minutes.

Making Flow Work in Practice

The teams that get the most from Flow share a few common habits:

• The PO creates the Initiative before the architect draws the first diagram. If the diagram is drawn before the problem is written down, the team has already answered a question before they agreed on what it was.
• ADRs are written when decisions are made — not after delivery. An ADR written from memory three months after the decision is half the value of one written in the week the decision was made.
• The DM updates confidence scores weekly without exception. A confidence score that never changes is not a signal — it is noise. The weekly update discipline is what makes the trend meaningful.
• All three roles attend the Initiative kickoff. The investment is 90 minutes. The return is a shared artefact that eliminates weeks of misalignment later.

Archgram Flow is available on Pro plans. Read the full documentation or open the editor to start your first Initiative.