Documentation
Docs in progress.
Full docs are in progress. Until then the AI Product Playbook documents every capability: per Activity the required context, the steps, the output and the quality gate.
Every Activity as a how-to
Each Activity explains briefly what it achieves – the detail page shows context, steps, output and quality gate.
01
Discover
- How to write OKRsTranslate strategy into a few measurable outcomes; do not disguise task lists as key results.
- How to define and use KPIsChoose a few standing product-health indicators, then establish a repeatable evidence-led review distinct from quarterly OKRs.
- Define product positioningBuild a supported value story for a defined audience and preserve claim meaning across short variants.
- User interviews — planning & prepPrepare behaviour-based interviews that could disprove the hypothesis, with realistic recruitment and consent planning.
- User interviews — running the sessionListen to recent lived behaviour rather than selling the product; keep raw observations intact for later synthesis.
- User interviews — synthesis & distributionSynthesise across participants without counting repeated mentions as independent evidence; communicate decisions with their support.
- How to map a customer journeyMap the customer’s experience, keeping observed current behaviour distinct from proposed future improvements.
- How to map an opportunity solution treeKeep the tree rooted in one outcome and evidence-backed opportunities; solutions remain alternatives until tested.
- How to map and test assumptionsPrioritise consequential weak beliefs and predefine what evidence would change the decision.
- How to use the Kano modelDistinguish customer-derived satisfaction categories from provisional team hypotheses; reassess categories as expectations evolve.
- How to prioritise using jobs-to-be-donePrioritise important underserved jobs before mapping solutions; preserve the difference between customer evidence and team guesses.
- How to write a feature briefAnswer whether the opportunity deserves exploration without prematurely prescribing requirements or implementation.
- How to prioritise against your objectivesPrioritise by objective contribution without forcing essential maintenance into an invented strategic link.
- How to build a weighted scoring modelAgree strategic criteria before scoring; use the ranking to expose trade-offs rather than automatically selecting work.
- How to prioritise with a 2×2 matrixUse shared relative placement to surface assumptions; the matrix is not a precision ranking.
- How to run effective product meetingsFirst decide whether live discussion is necessary; preserve preparation and resume with the actual meeting outcomes.
- How to share product updates on SlackLead with evidence of completed work and user value; draft for a confirmed audience without automatically posting.
- Coordinate a go-to-market launchCoordinate product availability and market readiness with clear dependencies; distinguish launch approval from publishing or deployment.
- How to run a retrospectiveBegin with prior commitments and finish with a few owned improvement experiments; do not turn the reflection into blame.
02
Define
- How to define success metricsDefine success before requirements by combining one primary outcome, diagnostic usage and a counter-metric.
- Success metrics with Discover, Use, RelyConnect awareness, successful use and continued reliance into distinct measurable stages with shared functional ownership.
- How to use RICEScore independently before discussion and preserve legitimate reasons to choose out of score order.
- How to prioritise with ICE scoringUse ICE for a quick relative comparison with consistent anchors and honest confidence.
- How to prioritise with MoSCoWUse the conversation to separate essential delivery from negotiable scope; Won’t means this time, not forever.
- How to write a PRDDescribe what users must be able to do, explicitly bound scope, and avoid substituting design or architecture for requirements.
- How to write a good ticketMake the item understandable and testable while respecting the engineers’ agreed working format.
- How to run backlog refinementPrepare and refine a PM-agreed subset of upcoming stories; preserve partial meeting coverage, per-story discussion and confirmation, and resume the same Activity without overwriting approved sources.
- How to record an architecture decisionRecord one decision with its real consequences; supersede earlier decisions visibly instead of erasing their rationale.
- How to define and review service level objectivesChoose reliability targets to support user-centred trade-offs, then review whether the indicators actually represent the experience.
- How to run a design critiqueFacilitate critique against goals rather than personal taste; critique informs design judgement and is not user validation.
- How to test a prototype with usersEvaluate observed task behaviour without teaching the intended answer; evidence determines whether another round is necessary.
- Design onboarding to first valueOptimise for the first useful outcome rather than completion of setup or a tour of every feature.
- How to write error messagesWrite error copy together with the recovery behaviour, never promising an action the product cannot perform.
- Run an adoption experimentPredefine the experiment and protect its interpretation from contamination, insufficient evidence and outcome-driven metric changes.
- How to run exploratory testingExplore adaptively within a bounded question; document what was actually exercised and what remains unknown.
03
Build
- How to review a code changeReview actual change scope and system effects, separating substantiated issues from optional preferences.
- How to log a bugProduce one factual reproducible report; search for a matching report before proposing a new ticket.
- How to plan a canary rolloutPlan limited exposure with pre-agreed evaluation; an approved plan alone never executes a production rollout.
04
Operate
- How to write release notesTranslate shipped changes into user value and never equate a merged change with general availability.
- Enable sales and support for a releasePrepare customer-facing teams with truthful role-specific material and feed actual questions back into the reference set.
- How to write user messages for downtimeCommunicate known impact promptly without inventing a recovery time; maintain a clear update and all-clear sequence.
- How to run a blameless incident postmortemLearn from system conditions and information available at the time, preserving uncertainty and avoiding personal blame.
- Plan product deprecation and retirementSeparate discouraging new use from actual removal and preserve users’ ability to complete their work through the transition.