Three checkpoints on the ProductBoard lifecycle. One of them is partly built: G1 runs today, but only the QA blade. This page is mostly about what the other three blades need.
Build the Product blade at G1: 6 new ProductBoard fields — Decider, Problem evidence, Success metric, Observation surface, Timeline, Out of scope (DRI reuses the built-in owner field) — plus the scored rubric. It answers all three questions at once: ownership becomes two named people, expectations become a metric and a range, and cross-department alignment becomes named stakeholders with a confirmation date.
| New idea | Ideation | — | e0eab182 |
| Discovery | Ideation | — | 6a1d1747 |
| Design | Ideation | G0 Shaping review | 4d834d90 |
| Candidate | Planning | G1 Planning readiness | f2d66261 |
| In Planning | Planning | — | 57f2c730 |
| Delivery | Build | — | 830b76f3 |
| Testing | Build | — | b65c94ed |
| Ready for Release | Release | — | 1e956d60 |
| Announcement | Release | — | 06a3088a |
| Released | Release | — | a43de77c |
| Blocked | off-flow | — | b641cac5 |
Risk & Compliance · Business · Design · 24 checks across 3 blades · Not built. Detailed once G1 is complete.
Blades in order: Product → QA → Engineering → Data. The first failure blocks, and is named. Back to Candidate. The card names the blade, and the missing field or the score.
| 1 | Product The proposal | not built | Not built. Needs 6 new ProductBoard fields — Decider, Problem evidence, Success metric, Observation surface, Timeline, Out of scope (DRI reuses the built-in owner field) — plus the scored rubric. |
| 2 | QA | live | Live since 2026-07-03 on Core CoE, Call Quality, Chat, Call Experience and Ads. Scores on arrival in Candidate, re-scores on the move to In Planning, reverts anything below 50. Publishes the score to a PB number field, keeps one note per ticket with the findings, posts a Teams card on a block, and logs every decision with a daily digest at 18:00 Dubai. |
| 3 | Engineering | not built | Not built. Needs 3 fields — engineering owner, approach link, estimate range — plus Engineering's own list and weights. The list below is a starting draft, not a decision. |
| 4 | Data | not built | Not built. Needs 3 fields — required events, metric definitions, dashboard — plus Data's own list and weights. The list below is a starting draft, not a decision. |
The proposalNot built. Needs 6 new ProductBoard fields — Decider, Problem evidence, Success metric, Observation surface, Timeline, Out of scope (DRI reuses the built-in owner field) — plus the scored rubric.
Product runs first: if the problem does not hold, the rest is not worth running. “Independently deliverable” and “platforms named” sit on the QA blade (V3, C3) — one check, one owner.
| Hard checks — all 7 required, missing any one sends the ticket back | |
| P1 | DRI One named person, not a team. “Product owns it” resolves to nobody. voted #3accountabilityassumed intent |
| P2 | Decider Who breaks the tie when there is disagreement. Also one person. voted #3accountabilityassumed intent |
| P3 | Problem evidence A link to the data the problem rests on — a dashboard, a support ticket, research notes. voted #1incomplete info |
| P4 | Success metric A metric, a threshold and an observation window. All three. voted #1voted #3 |
| P5 | Observation surface Which dashboard the result gets read on after launch. incomplete info |
| P6 | Timeline A range with a confidence level, not an exact date. voted #3priorities |
| P7 | Out of scope What this explicitly does not include. voted #3communication |
| Grounding 40 of 100 | |
| P8 | Problem before solution The user problem is named before anything to build. Solution-only scores zero. voted #1 |
| P9 | Magnitude A metric, a number and a time range. “Many users complain” earns nothing. voted #1incomplete info |
| P10 | Same measure throughout The problem's metric and the success metric are the same measure. voted #1 |
| P11 | Cost of not doing it What happens if this waits a quarter. No stated cost means anyone can displace it. priorities |
| Expectations 25 of 100 | |
| P12 | Guardrail metric What must not get worse. Prevents winning on one number by losing another. voted #3 |
| P13 | Stop condition What would make us cancel this. voted #3accountability |
| P14 | Confidence matches the commitment Not everything can be high confidence. If it all is, none of it is. priorities |
| Ownership & handover 35 of 100 | |
| P15 | Stakeholders named as people Named individuals with a confirmation date, not “synced with Risk”. voted #2communicationassumed intent |
| P16 | Decisions recorded A link to where the decisions taken so far are written down, so the argument is not repeated. voted #3assumed intent |
| P17 | Dependencies are mutual The team you depend on knows they are depended on, and their timing is visible. voted #2communication |
| P18 | One line for Support What a user will notice, in plain language, ready to hand to CS. communication |
Live since 2026-07-03 on Core CoE, Call Quality, Chat, Call Experience and Ads. Scores on arrival in Candidate, re-scores on the move to In Planning, reverts anything below 50. Publishes the score to a PB number field, keeps one note per ticket with the findings, posts a Teams card on a block, and logs every decision with a daily digest at 18:00 Dubai.
In production today, on this exact transition, unchanged.
| Hard checks — all 3 required, missing any one sends the ticket back | |
| Q1 | Something testable exists No acceptance criteria and no use case scores a straight zero. |
| Q2 | No conflict with a shipped requirement Flagged only when the story itself states a conflicting hard number. |
| Q3 | Not a placeholder Body empty, or most sections still TBD. |
| Completeness 20 of 100 | |
| C1 | Story format Role, capability, benefit. |
| C2 | Criteria cover the description Nothing described is left unverified. |
| C3 | Scope boundaries and platforms |
| C4 | Dependencies and preconditions communication |
| C5 | Non-functional and design references |
| Clarity 20 of 100 | |
| A1 | No vague qualifiers “Fast”, “properly”, “as needed” all cost points. |
| A2 | No TBD or placeholders incomplete info |
| A3 | Unambiguous references |
| A4 | Explicit quantities and formats |
| A5 | Consistent terminology |
| Testability 20 of 100 | |
| T1 | Every criterion is verifiable |
| T2 | Happy path |
| T3 | Error and negative paths |
| T4 | Edge cases and boundaries |
| T5 | Criteria are atomic |
| Soundness 15 of 100 | |
| F1 | No internal contradictions |
| F2 | States can be reached and left |
| F3 | Error handling per failure mode |
| F4 | Data lifecycle complete |
| Consistency 15 of 100 | |
| X1 | No conflict with board requirements |
| X2 | No conflict with documented behaviour |
| X3 | Not a duplicate |
| X4 | Consistent patterns and terms |
| Atomicity 10 of 100 | |
| V1 | A single capability |
| V2 | Explicit user value |
| V3 | Independently deliverable and testable |
Not built. Needs 3 fields — engineering owner, approach link, estimate range — plus Engineering's own list and weights. The list below is a starting draft, not a decision.
Draft — Engineering set the weights.
| Hard checks — all 3 required, missing any one sends the ticket back | |
| E1 | Named engineering owner One person accountable for the build. voted #3accountability |
| E2 | Approach written down A design note or decision record, linked. Not held in one person's head. voted #3incomplete info |
| E3 | Estimate as a range with confidence A single number pretends to a precision that does not exist. voted #3priorities |
| Engineering readiness weight to be set | |
| E4 | Interfaces and contracts specified API changes and versioning. |
| E5 | Migration and backward compatibility |
| E6 | Failure modes and rollback path |
| E7 | Load and scale assumptions stated |
| E8 | Reuse considered before building An existing service or component that already does this. |
| E9 | Auth, secrets and permissions reviewed |
Not built. Needs 3 fields — required events, metric definitions, dashboard — plus Data's own list and weights. The list below is a starting draft, not a decision.
Draft — Data set the weights.
| Hard checks — all 3 required, missing any one sends the ticket back | |
| D1 | Events listed, each marked existing or to be added Instrumentation that has to be built is a deliverable, not an assumption. incomplete info |
| D2 | Metric definitions agreed with Data With an owner and a date. Definition disagreements found after launch cost a full re-analysis. incomplete infocommunication |
| D3 | Dashboard named The same surface the Product blade committed to at P5, and it can actually produce that metric. incomplete info |
| Measurability weight to be set | |
| D4 | Identity and join keys specified Which user identifier, and how it joins to the rest. |
| D5 | Freshness expectation Real time or next day — decided, not discovered. |
| D6 | Backfill need stated |
| D7 | Guardrail metrics instrumented too Not only the success metric. You cannot see the damage you did not measure. incomplete info |
| Voted #1 | Clear vision grounded in the actual problem, not the solution. Problem-based roadmaps for prioritisation. | P3 P4 P8 P9 P10 |
| Voted #2 | A scheduled cadence across Business, Tech, Risk and Compliance, replacing duplicate or unclear meetings. | P15 P17 |
| Voted #3 | Ownership defined for every initiative, key decisions documented, expectations on timelines and success criteria set up front. | P1 P2 P4 P6 P7 P12 P13 P16 E1 E2 E3 |
| Obstacle | Priorities, and priorities that keep changing. | P6 P11 P14 E3 |
| Obstacle | Communication. | P7 P15 P17 P18 C4 D2 |
| Obstacle | Incomplete information. | P3 P5 P9 A2 E2 D1 D2 D3 D7 |
| Obstacle | “Assumed best intent” standing in for an explicit agreement. | P1 P2 P15 P16 |
| Obstacle | No urgency and no accountability. | P1 P2 P13 E1 |
Codes refer to G1 checks.