ship-decisions_skill

Overview

This skill guides product teams through “ship or iterate?” decisions using proven frameworks from Shreyas Doshi, Marty Cagan, and reversible-decision thinking. It helps determine reversibility, score shipping readiness, balance technical debt against speed, and plan safe gradual rollouts. Use it to avoid perfectionism paralysis and make repeatable, low-risk shipping choices.

How this skill works

The skill inspects a feature against a five-check shipping scorecard: core functionality, edge case handling, reversibility, learning value, and risk mitigation. It classifies decisions as two-way (reversible) or one-way (irreversible), recommends whether to ship, iterate, or research, and suggests rollout stages and rollback plans. It also provides a tech-debt assessment to decide when to accept temporary shortcuts versus refactor first.

When to use it

• When a stakeholder asks “is this ready to ship?”
• Deciding between shipping now vs iterating further
• Balancing technical debt with the need to deliver user value fast
• Avoiding perfectionism and reducing decision paralysis
• Designing rollout and rollback plans for new features

Best practices

• Always verify the happy path works end-to-end before shipping
• Classify the decision as two-way or one-way and treat them differently
• Ship to learn when learning value outweighs polish value
• Use feature flags and staged rollouts to minimize blast radius
• Track critical metrics and have a clear rollback plan before any broad release

Example use cases

• Launch a UI experiment (two-way door): ship to a small percent, iterate on feedback
• Release a new API or pricing plan (one-way door): research, versioning, and slow rollout
• Decide when to accept technical debt: ship now if user value > debt cost, plan refactor later
• Evaluate a half-built feature: apply the scorecard to decide ship, ship to small group, or iterate
• Plan a gradual rollout: internal → early adopters → broader beta → general availability