Growth Loops · Session 01 · Dates TBD
A product scorecard built from behavior you can trust
Ship AIPhoenix, ArizonaPress → to begin
A dashboard cannot rescue a vague question.
Tonight starts with the decision, follows one user through the product, and earns the right to put a number on the screen.
Six sessions, one live product. Measurement comes first because every activation, retention, and loop decision after tonight depends on these definitions and events.
Act one
A metric earns a place when a plausible change in it would alter what the team does next week.
Starting from available events reverses this logic and produces dashboards full of activity with no decision attached.
| Question | Example answer | |
|---|---|---|
| Who | Which eligible customer? | Workspace member with edit access |
| Did what | Which completed action? | report_shared |
| Conditions | What must be true? | Report contains at least one saved result |
| Counting | How often does it count? | Once per report per workspace |
| Window | Over which interval? | Weekly, in workspace time zone |
The example is illustrative. Replace the noun and conditions with the moment your customer actually receives value.
| Question | Illustrative metric | |
|---|---|---|
| Outcome | Did customers receive repeat value? | Weekly workspaces sharing a useful report |
| Driver | Which behavior could explain movement? | Reports created per eligible workspace |
| Driver | Where does the path stall? | Share completion after report creation |
| Guardrail | Did quality or trust get worse? | Errors, permission reversals, unwanted sends |
A driver helps diagnose. A guardrail keeps the team from raising the outcome by damaging the experience.
Act two
Events record what happened. Properties preserve the context needed to explain why the same action behaved differently for different customers.
| Event | Minimum useful context | |
|---|---|---|
| workspace_created | The workspace exists | plan · source · creator_role |
| data_connected | A usable source connected | source_type · connection_result |
| report_created | A report was saved | template · result_count |
| report_shared | A recipient can access it | surface · recipient_count · permission |
| report_viewed | A recipient opened it | viewer_role · report_id |
Prefer a few durable product verbs over an event for every click. Clicks can be diagnostics; they are rarely the value itself.
User metrics and account metrics answer different questions. Decide which entity can actually receive the product's value.
Live build: validate one real journey
complete journey → inspect payload → find user
report_created fired onceworkspace_id + user_id presentreport_shared missing recipient_countproperty added; clean replay verified
Perform the core path with the analytics debugger open. Inspect the raw payload, locate the same user and account in analytics, and replay only after the defect is fixed.
A dashboard row is downstream evidence. Validation begins at the product action and follows the exact record into the analytics tool.
What goes wrong
How to catch it
If one action should count once, give the event a stable ID or server-side boundary that makes retries distinguishable from new actions.
Act three
The first scorecard is intentionally small: definition, current value, comparison, owner, and a link back to the behavior behind the number.
| Definition | Decision | |
|---|---|---|
| Repeat value | Eligible workspaces with a useful share this week | Is repeat value improving? |
| Activation driver | New workspaces reaching first useful share | Where should onboarding change? |
| Engagement driver | Activated workspaces repeating the action | Which next action needs help? |
| Trust guardrail | Errors and permission reversals per share | Did the change create harm? |
Every row also needs an owner, update cadence, source query, and last-validated date. Two people should calculate the same result.
Confidence comes from knowing the boundary of the measurement, not from adding decimal places.
A scorecard compounds only when it changes a decision and the instrumentation is rechecked after the product changes.
The artifact
save taxonomy → validation log → scorecard
value-event contract versioned5/5 journey events verifiedowners + weekly cadence assignedwrote 01-measurement/scorecard.md
Commit the metric tree, event taxonomy, identity rules, validation evidence, data caveats, and the scorecard query links as one measurement contract.
Session two uses this exact event stream to test candidate activation signals and build the signup-to-value funnel.
Measure the decision, not the dashboard.
Next
Next session compares what retained customers did early, defines activation as a behavioral prediction, and removes one barrier on the path to first value.
shipai.club · Free, always