iterate-pivot-decision

$npx mdskill add product-on-purpose/pm-skills/iterate-pivot-decision

Documents strategic pivot or persevere decisions based on market feedback

  • Identifies key hypotheses and their validity through market analysis.
  • Deploys tools like market research APIs to gather evidence for decision-making.
  • Analyzes data and user insights to determine the likelihood of success for different strategies.
  • Generates a clear document outlining the rationale, evidence, and recommendations.

SKILL.md

.github/skills/iterate-pivot-decisionView on GitHub ↗
---
name: iterate-pivot-decision
description: Documents a strategic pivot or persevere decision with the evidence, analysis, and rationale. Use when evaluating whether to change direction on a product, feature, or strategy based on market feedback.
license: Apache-2.0
metadata:
  phase: iterate
  version: "2.1.1"
  updated: 2026-06-22
  category: reflection
  frameworks: [triple-diamond, lean-startup, design-thinking]
  author: product-on-purpose
---
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Pivot Decision

A pivot decision document captures the analysis and rationale behind a strategic direction change.or the decision to stay the course. Based on the Lean Startup concept of "pivot or persevere," this artifact ensures major strategic decisions are made with evidence, communicated clearly, and preserved for organizational learning.

## When to Use

- After significant validated learning suggests the current direction may not work
- At planned pivot-or-persevere checkpoints (e.g., after MVP launch)
- When key hypotheses have been invalidated by market feedback
- During strategy reviews when considering major direction changes
- When stakeholders are debating whether to change course

## When NOT to Use

- You are reporting experiment results without a direction decision attached -> use `measure-experiment-results`
- The decision is technical or architectural rather than directional -> use `develop-adr`
- You want to explore candidate directions before deciding anything -> use `define-opportunity-tree`
- The team needs the period-end reflection ceremony -> use `iterate-retrospective`; a pivot call is a decision document, not a retro
- The product is not built yet, and the question is whether to build a new idea, feature, or scope change at all (a build / validate / cut verdict) -> use `foundation-build-risk-review`; a pivot call weighs market feedback on something already shipped

## Instructions

When asked to document a pivot decision, follow these steps:

1. **Summarize Current State**
   Document what you're currently doing, how long you've been doing it, what you've invested, and what results you've achieved. This grounds the decision in reality.

2. **Present the Evidence**
   Compile all relevant data: metrics, user feedback, experiment results, market signals. Be comprehensive.include evidence that supports both staying and changing course.

3. **Review Hypotheses**
   Revisit the original hypotheses that justified the current direction. Which have been validated? Which have been invalidated? Which remain untested?

4. **Define Options**
   Articulate at least three options: persevere (continue current direction), and two or more distinct pivot options. Describe each option concretely.what would change?

5. **Analyze Each Option**
   Evaluate options against key criteria: market opportunity, competitive advantage, team capability, resource requirements, and risk. Use evidence, not opinions.

6. **Make the Decision**
   State the chosen direction clearly. Explain the rationale, acknowledging trade-offs. If the team disagrees, capture dissenting views.

7. **Plan Implementation**
   Outline what happens next: immediate actions, resource needs, success criteria for the new direction, and communication plan.

## Output Format

Use the template in `references/TEMPLATE.md` to structure the output. A complete decision document fills every template section: Overview; Executive Summary; Current State; Evidence Summary; Hypothesis Review; Options Considered; Analysis; Decision; Implementation Plan; Communication Plan; and Appendix.

## Quality Checklist

Before finalizing, verify:

- [ ] Current state includes honest assessment of results
- [ ] Evidence is comprehensive, not cherry-picked
- [ ] Multiple options are analyzed fairly
- [ ] Decision rationale is clear and evidence-based
- [ ] Implementation plan is actionable
- [ ] Dissenting views are captured

## Examples

See `references/EXAMPLE.md` for a completed example.

More from product-on-purpose/pm-skills

SkillDescription
define-hypothesisDefines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
define-jtbd-canvasCreates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
define-opportunity-treeCreates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
define-prioritization-frameworkRun applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
define-problem-statementCreates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
define-xFixture skill for phase-map and phase-router tests.
deliver-acceptance-criteriaGenerates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
deliver-edge-casesDocuments edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
deliver-launch-checklistCreates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.
deliver-prdCreates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.