Guides for product decisions

Step 1. Write the decision first. Define what the team could do differently after reading the brief and which customer segment it concerns.

Step 2. Prepare the evidence. Give each participant a neutral ID, remove identifying details and preserve a link or timestamp for each observation.

Step 3. Extract observed behaviour, reported needs and your interpretations separately. Ask AI to suggest themes using source IDs; require it to label missing or ambiguous evidence.

Step 4. Check every proposed theme against the original notes. Look for contradictory cases and distinguish the number of participants from the number of repeated mentions.

Step 5. Write the brief: top problems, supporting evidence, counterexamples, affected segment, confidence and unanswered questions. Describe the sample without treating it as the whole market.

Step 6. Choose the next action. Specify one assumption to test, its owner and what evidence would change your current view.

Step 1. Define the decision and comparison criteria around the customer’s job: target user, workflow, promised outcome, constraints and proof.

Step 2. Collect current first-party evidence. Record the page title, URL, access date and exact excerpt for each claim; distinguish vendor promises from observed behaviour.

Step 3. Compare like with like. Note the plan, region or release condition when visible. Mark unavailable information as unknown rather than absent.

Step 4. Use AI to organise the evidence into a matrix. Require a source for each populated cell and keep analyst inferences in their own column.

Step 5. Review the cells against their sources. Check that one product’s claim has not been copied to another and that estimates are clearly labelled.

Step 6. Choose one implication to validate with customers. Write the opportunity, its supporting evidence, an alternative explanation and the cheapest useful next test.

Step 1. Set the objective and horizon. Agree on the customer outcome, business constraint and capacity available for this decision.

Step 2. Normalise the options. Express each as a problem or opportunity, state the affected segment and attach the best evidence for its expected impact.

Step 3. Choose common criteria and scoring definitions before scoring. Keep evidence quality, delivery effort, dependencies and risk visible rather than hiding them inside one number.

Step 4. Ask AI to find missing assumptions and inconsistent inputs. Use your team’s actual estimates; where data is missing, leave it unknown or define a range.

Step 5. Stress-test the order. Vary uncertain inputs within plausible ranges and see which choices remain strong. Put fragile, important assumptions into a learn-first queue.

Step 6. Record the decision with its trade-offs, owner and review trigger. A justified strategic or compliance constraint can override a score; document the reason.

Step 1. State the assumption and what could disprove it. Choose the smallest workflow that can expose that uncertainty.

Step 2. Build only what the test needs. Include the essential entry point, decision and result, plus realistic loading, empty and error states where they affect the task.

Step 3. Write a neutral task and discussion guide. Ask participants to work toward a goal without naming the controls they should use.

Step 4. Pilot the session. Check the prototype, recording consent, keyboard path, wording and moderator prompts before recruiting the main participants.

Step 5. Observe target users attempting the task. Record completion, assistance, critical errors and evidence IDs; separate usability problems from limits of the prototype.

Step 6. Review evidence against the prewritten criteria. Decide whether to revise, continue testing or stop, and record what the study cannot establish.

Step 1. Define the job and boundaries. State who benefits, which actions require human approval and what the system should do when it lacks evidence or fails.

Step 2. Build a test set from realistic tasks. Include normal, ambiguous, missing-input and adversarial cases, and reserve some examples from prompt tuning.

Step 3. Write the rubric before comparing versions. Define task success, evidence accuracy, privacy and safety failures, response-time expectations and cost per completed task.

Step 4. Run the baseline and candidate under comparable conditions. Record the prompt or model version, test-set version, outputs, scores, cost and latency; repeat where variation matters.

Step 5. Inspect failures individually and calibrate automated grading against human review. Do not let a better average hide regressions on a critical scenario.

Step 6. Approve only a bounded pilot if the agreed gates are met. Assign an owner, monitoring plan, stop conditions and rollback path; use a properly designed live experiment if you need causal business-impact evidence.

Step 1. Make the strategic choice explicit. Write which segment and problem matter now, why they matter, and two plausible areas you will not pursue this cycle. A company growth target alone does not explain that choice.

Step 2. Describe the change in customer behaviour or experience that would support the strategy. Connect it to the business result as a hypothesis, including where the relationship is uncertain.

Step 3. Draft one objective for each distinct priority. Keep proposed features in a separate initiative list so teams can change the solution while preserving the intended outcome.

Step 4. Define each key result with a population, calculation, baseline period, target, deadline and data owner. If the baseline is missing, create a measurement task and leave the target provisional instead of inventing a number.

Step 5. Challenge the set with product, design, engineering and analytics. Could every result improve while customers are worse off? Add guardrails for quality, reliability, cost or exclusion where that is possible.

Step 6. Check ownership and capacity. Identify dependencies that the team cannot control, negotiate shared responsibilities, and distinguish an approved commitment from an aspirational result.

Step 7. Agree how to review progress. Track actuals, confidence and new evidence separately; name the decision that a review can change. Record any revision so a changed target cannot silently erase the original expectation.

Step 1. Write the decision requested. Specify whether you need time to investigate, permission for a pilot or funding for delivery; these require different evidence and commitments.

Step 2. Compare realistic alternatives. Include the status quo and its consequences, a narrower intervention and a process or partner option where relevant. Use the same horizon and customer segment for each.

Step 3. Trace the proposed value chain. Show how a change might affect behaviour, then the business outcome. Label each link as observed, inferred or untested and identify the link most likely to break the case.

Step 4. Estimate whole-life effort and cost with delivery partners. Include migration, support, instrumentation, security review, vendor usage, maintenance and the work that would be displaced. Keep ranges when uncertainty is material.

Step 5. Build downside, central and upside scenarios from named assumptions. Keep benefit units separate until conversion is defensible: hours saved are not automatically payroll savings, and adoption is not automatically incremental revenue.

Step 6. Propose the smallest next commitment that resolves a decision-relevant uncertainty. Define what evidence would justify expanding, changing or stopping, plus the owner, maximum exposure and review date.

Step 7. Present the recommendation and strongest objection together. Ask the authorised decision maker to record the choice, conditions and unresolved risks rather than approving an impressive-looking spreadsheet by default.

Step 1. Agree what this roadmap is for and who will use it. Separate internal exploration from customer-facing commitments; record existing contractual or regulatory deadlines rather than hiding them in a flexible horizon.

Step 2. Rewrite each candidate as an outcome or problem to solve. Attach its evidence, owner and success signal; keep a proposed solution as a hypothesis when discovery is incomplete.

Step 3. Place work into now, next or later using readiness and dependency conditions. Define those horizons in words. A later item should not look like a promised release date.

Step 4. Test feasibility with the teams doing the work. Surface shared specialists, platform work, rollout effort and support obligations. Reduce concurrent work before implying that every initiative can move together.

Step 5. Make the trade-off discussion concrete. For each contested item, describe what enters, what leaves and which outcome or commitment changes. Keep the strongest reason for the deferred option in the decision record.

Step 6. Agree promotion and removal gates. State what evidence moves an item into now, what invalidates it, and who can approve a material change. A new request must compete with current work instead of silently expanding scope.

Step 7. Publish the appropriate view after stakeholder review. Include confidence, open questions and the next review trigger; preserve the previous decision so future teams can understand why direction changed.

Step 1. Bound the decision. Write the exact question, what is out of scope, when it must be made and whether it can be reversed. Split separate questions that require different approvers.

Step 2. Confirm roles with the people involved. Name a driver to organise the work, an authorised approver, contributors with relevant expertise and those who must be informed. A map is a draft until people acknowledge their responsibilities.

Step 3. Collect concerns before proposing alignment. Ask each contributor which outcome they protect, which constraint matters and what evidence would change their view. Record their stated position rather than guessing motives from job titles.

Step 4. Prepare a short options brief using common criteria. Include the status quo, the strongest case for each option, unresolved evidence and the cost of delay. Separate disagreements about facts from disagreements about priorities.

Step 5. Use the meeting for the unresolved trade-off. Clarify facts first, then ask the approver to choose or explicitly commission the missing evidence with an owner and deadline. Do not confuse silence with agreement.

Step 6. Record the decision and remaining dissent accurately. Specify conditions, follow-up owners and a review trigger; have the driver confirm the record with the approver before sharing the approved version.

Step 7. Close the communication loop. Tell affected people what changes for them and where to raise new evidence. Reopen the choice only when the agreed trigger is met or the authorised owner decides circumstances have changed.

Step 1. Trace a real piece of work. Mark where priorities were set, evidence gathered, decisions approved, work handed off and results reviewed. Ask participants what happened instead of diagnosing the organisation from a generic maturity score.

Step 2. Choose one friction to address. Examples include unclear authority to change a solution, discovery squeezed out by urgent requests, or no review after release. Describe the impact and the evidence that it recurs.

Step 3. Agree a testable operating change with the sponsor and team. State which decisions the team may make, what guardrails remain, when specialists must be consulted and how disagreements escalate. Do not imply permissions that leaders have not granted.

Step 4. Create a minimal cadence around real decisions. Give each review a purpose, owner, input and output; remove or replace an existing meeting where practical. Keep customer learning and post-release results connected to planning.

Step 5. Define pilot observations before starting. Track the targeted friction and possible costs such as review burden, quality or workload. Use an initial baseline or clearly mark where it is missing; protect candid team feedback.

Step 6. Run the pilot for enough work cycles to observe the change. Log exceptions, dependencies and decisions that still required escalation. Coach through the new behaviour rather than judging success by attendance or template completion.

Step 7. Review with the team and sponsor. Decide what to keep, adapt or stop, state what the pilot cannot establish and assign unresolved system-level blockers. Expand only after an explicit decision; a local pilot is not permission for a reorganisation.

Step 1. Agree the purpose of the conversation. Make clear whether this is development coaching or part of a formal performance process; do not disguise a consequential assessment as an informal exercise.

Step 2. Ask the PM to reconstruct a recent decision. Explore the outcome they sought, the options they considered, the evidence they trusted and what they would now change. Understand constraints before attributing a result to a skill gap.

Step 3. Offer specific observations from the work. Separate the behaviour from its impact and your interpretation. Invite correction and ask where the PM sees the same pattern or a counterexample.

Step 4. Choose one capability and a concrete practice opportunity. For example, compare two plausible options in the next discovery brief, or write down disconfirming evidence before a stakeholder review. Agree what good practice would look like in this role.

Step 5. Set the manager’s support as well as the PM’s action. Arrange a rehearsal, shadowing, an example or protected time. Preserve the PM’s ownership of the decision rather than quietly taking the work back.

Step 6. Review the next artifact together. Discuss what changed in the reasoning and what remains difficult; distinguish skill practice from outcomes affected by luck or dependencies. Adjust the plan using direct evidence.

Step 7. Keep only the agreed development record in the appropriate restricted location. Do not upload identifiable performance notes to an unapproved AI tool or let an AI-generated rating determine promotion, pay or employment.

Step 1. Separate user, buyer and approver. Describe the job, purchase trigger and current alternative for one segment. Do not blend unlike buying contexts into a single willingness-to-pay average.

Step 2. Investigate recent behaviour before pitching. Ask how the problem was handled, what alternatives were considered, how budget was obtained and what made the decision difficult. Record evidence without pressuring the participant to reveal confidential figures.

Step 3. Write a value proposition as a testable claim. Identify which benefit is supported, which is assumed and what a buyer would need to see to believe it. Avoid guaranteed savings or outcomes you have not measured.

Step 4. Compare a small set of packages or pricing units. Ask participants to explain what they think is included, estimate a bill for a realistic scenario and describe what would make them hesitate. Note uncertainty and confusing boundaries separately from preference.

Step 5. Review economics and operations with the relevant owners. Consider variable usage, support, billing accuracy, spend controls and the effect on existing customers. Customer value and a viable cost structure must both be investigated.

Step 6. Choose the next evidence step. Interviews can expose language and purchase constraints; stronger demand evidence may require an approved offer or bounded market test. Predefine the question, eligible population, guardrails and decision rule before running it.

Step 7. Document a proceed, revise or learn-more recommendation with its limits. Keep research separate from a live price change: implementation, customer notices, contracts and rollout need their own approval and specialist review.

Step 1. State exactly what is launching, to whom and why. Distinguish deployment, customer availability and public announcement; they may have different dates and decision owners.

Step 2. Turn readiness into evidence gates. For each critical journey, quality requirement or approval, name the proof, owner and current status. An unchecked item is unknown, not green; a completed task is not automatically a passed gate.

Step 3. Walk the whole customer path with realistic test data. Review discovery, signup or purchase, first value, failure recovery, help and cancellation where relevant. Check that marketing promises match the capability actually available to the launch cohort.

Step 4. Review operational preparation. Confirm support guidance, access and eligibility rules, billing, known limitations, accessibility, security or privacy review, and escalation coverage according to product risk.

Step 5. Agree rollout and measurement. Define the initial cohort, exposure control, customer-value signal, reliability or safety guardrails, observation window and person who can pause. Verify the rollback or containment path rather than merely naming one.

Step 6. Make the decision with unresolved risks visible. Record go, conditional go or hold; any exception needs an authorised owner, explicit consequence and expiry. A failed mandatory gate cannot be waved through by an optimistic average.

Step 7. Schedule the outcome review and handover. Compare expected and observed customer behaviour, inspect complaints and failures, and decide whether to expand, revise or stop. Keep communication drafts separate from approved publication.

Step 1. Describe the moment of customer value in plain language. A visit, click or generated output may be an intermediate event; explain what useful result the customer actually receives and how often that result should occur.

Step 2. Propose a value measure that can be observed. Specify the entity being counted, eligible population, time window and completion rule. Consider whether one aggregate metric hides important segments or product jobs.

Step 3. Break the measure into candidate inputs. Distinguish exact mathematical relationships from hypotheses about influence. Show formulas where they truly hold; do not draw a causal arrow just because two metrics move together.

Step 4. Add guardrails and counterexamples. Ask how the value metric could rise while quality, trust, reliability, access or economics worsen. Pick a manageable set of checks tied to those failure modes.

Step 5. Write the measurement contract with analytics and engineering. Define event names, required properties, inclusion and exclusion rules, identity handling, deduplication, time zone and ownership. Minimise personal data and review consent requirements.

Step 6. Validate before using the dashboard to decide. Reconcile a small set of known journeys to recorded events, check missingness and duplicate events, and compare definitions across teams. Mark unvalidated values visibly.

Step 7. Assign a decision to each review. Specify what a meaningful change would cause the team to investigate or do, and when definitions should be revisited. Use an appropriate experiment or stronger design if a causal claim is needed.

Step 1. Define intake and escalation separately. A safety, security, outage or other urgent issue follows the appropriate response policy immediately; routine product triage must not delay it.

Step 2. Normalise records without losing evidence. Preserve a restricted link to the original, date, segment, reported problem, workaround and customer impact. Distinguish an observed problem from the customer’s proposed feature.

Step 3. Deduplicate carefully. Link repeated reports while retaining unique reporters and affected accounts where permitted. Count people, accounts and mentions separately, and state what each channel overrepresents or misses.

Step 4. Group by the underlying job or failure, then challenge the grouping. Keep counterexamples, severe one-off failures and uncertain classifications visible. Do not treat the largest theme as automatically the most important opportunity.

Step 5. Make a disposition decision with the right owner. Route each important theme to investigate, fix, link to an existing initiative, defer with a reason or close as resolved. Use customer impact, strategy and evidence rather than raw request volume alone.

Step 6. Close the communication loop through the authorised channel. Acknowledge what was heard, explain what can honestly be said about the decision and avoid unsupported delivery promises. Track who owns the response and whether it was actually sent.

Step 7. Check the result after action. Look for recurrence, whether the affected workflow improved and whether the customer confirmed resolution where practical. Feed incident-learning actions into this review without exposing restricted incident details broadly.