layers-product-strategy
jamiemill/layers-skills
Connect user needs to business outcomes and test strategic bets with minimal cost.
What is layers-product-strategy?
A library of techniques for product strategy that helps teams move from problem understanding to deliberate decisions about scope and direction. Use this when defining which user opportunities to serve, which business outcomes to target, and how to validate your riskiest assumptions before investing in design or development.
- Map user opportunities to business outcomes using the Opportunity Solution Tree
- Generate multiple solution bets per opportunity and name their core assumptions
- Design cheap experiments (prototypes, interviews, data analysis) to test strategic assumptions
- Prioritize opportunities by journey moment, size, assumption risk, and effort
- Choose the right strategic technique for your specific question (Kano, Jobs Portfolio, Wardley, Impact Mapping, etc.)
- Capture strategy residue: outcome, opportunity tree, top bets, experiments, and open questions
How to install layers-product-strategy
npx skills add https://github.com/jamiemill/layers-skills --skill layers-product-strategy- Familiarity with `/layers-intro` (this skill is a library of techniques, not an automated script)
- A defined or emerging business outcome to work toward
- Access to user research, customer data, or the ability to conduct interviews
How to use layers-product-strategy
- 1.Start with a specific, measurable, bounded business outcome (e.g., 'increase users who activate in the first 30 days', not 'grow the product')
- 2.Map user opportunities (needs, pains, desires) anchored to specific journey moments; group them by when they occur in the customer journey
- 3.For each opportunity, generate 2–3 solution bets using the format: 'We could [solution], which we believe would [serve the opportunity] because [reasoning]'
- 4.Name the riskiest assumption in each bet
- 5.Design the cheapest experiment to test each bet's core assumption (prototype, fake door, concierge, targeted interview, or data analysis)
- 6.Prioritize bets by opportunity size, assumption risk, effort, and reversibility; start with high size, manageable risk, and a clear experiment path
- 7.Capture the strategy residue: outcome, opportunity tree grouped by journey moment, top 2–3 bets with experiments, deferred bets, and open questions
Use cases
- Define the measurable business outcome and map which user needs genuinely connect to it before building a product roadmap
- Generate and compare multiple solution bets for a single opportunity to avoid early convergence and premature commitment
- Design a low-cost experiment to test whether a strategic assumption holds before investing in design or development
- Prioritize among many candidate features or job stories using frameworks like Kano analysis or jobs portfolio mapping
- Align a cross-functional team on strategy by building an Opportunity Solution Tree diagram that shows dependencies from outcome through opportunities to bets to experiments
- Product managers and strategists defining product direction
- Cross-functional teams (product, design, engineering) aligning on strategic priorities
- Founders and leaders deciding which user needs to serve and which business outcomes to target
- Teams working in discovery mode who need to test assumptions cheaply before committing resources
layers-product-strategy FAQ
An opportunity is a customer need, pain, or desire anchored to a journey moment, stated in first-person problem-space language ('I don't know which streaming service has this movie'). A feature is a solution. Use the flip test: if you can restate it as a feature, it's a solution in disguise. Keep opportunities specific and problem-focused.
The OST is the default technique for making outcome → opportunity → solution → experiment explicit, but it's not mandatory. Choose the technique that fits your specific question: use Kano to sort features by impact, Jobs Portfolio to prioritize among many job stories, Wardley for positioning decisions, or Impact Mapping for B2B multi-stakeholder scenarios.
Your outcome must be measurable, meaningful, and bounded. Not 'grow the product' but 'increase users who activate in the first 30 days.' It should be one outcome per tree. If you can't measure progress toward it or it's too vague, push for specificity before building the rest of the strategy.
A cheap experiment tests the core assumption in days, not months. Examples: a prototype, a fake-door landing page, a concierge MVP, a targeted customer interview, or data analysis of existing behavior. The goal is to validate or invalidate the riskiest assumption before committing to design or development.
No. Offer the technique that fits the question at hand. Running all of them wastes time. Use OST to connect things end-to-end, Kano or Jobs Portfolio to choose among many candidates, Wardley or Bundling for positioning, and Impact Mapping for multi-stakeholder B2B scenarios.
Full instructions (SKILL.md)
Source of truth, from jamiemill/layers-skills.
name: layers-product-strategy description: Techniques for connecting user opportunities to business outcomes and solution bets, and testing the riskiest assumptions cheaply
/layers-product-strategy
Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
Strategy is the first layer of the solution space — where problem-space understanding converts into deliberate decisions about scope and direction. It is about choices: which user needs to serve, and which business outcomes to target.
The decisions this layer makes
- The business outcome this work serves
- Which user opportunities (needs, pains, desires) genuinely connect to that outcome
- What solution bets we're placing on those opportunities
- How to test the riskiest assumptions cheaply
- Which bets to pursue first, and why
If the outcome and the bets are already clear, don't rebuild the tree for its own sake.
Disciplines — what keeps strategy honest
- The outcome is measurable, meaningful, and bounded. Not "grow the product" but "increase users who activate in the first 30 days." One outcome per tree.
- Opportunities are customer needs/pains/desires — anchored to a journey moment. First-person, problem-space statements ("I don't know which streaming service has this movie"), not job stories and not features. Apply the flip test: if you can restate it as a feature, it's a solution in disguise. Keep them specific, not generic. Group opportunities by journey moment — the forcing function that exposes vague opportunities and surfaces moments left unaddressed. (Teresa Torres.)
- Every opportunity connects to the outcome. If serving it wouldn't move the outcome, it doesn't belong in this tree.
- Every bet names its riskiest assumption, and there's more than one bet per opportunity — resist early convergence.
- Every experiment is the cheapest way to test the core assumption — days, not months.
Techniques
The Opportunity Solution Tree is the default; the rest serve particular strategic questions.
| Technique | Use it when |
|---|---|
| Opportunity Solution Tree (Teresa Torres) | Default. Makes outcome → opportunity → solution → experiment explicit. Good for ongoing discovery. |
| Solution bets | For a chosen opportunity: "We could [solution], which we believe would [serve the opportunity] because [reasoning]." Generate several; name each one's key assumption. |
| Experiments | Cheapest test of a bet's core assumption — prototype, fake door, concierge, a targeted interview, data analysis. |
| Impact mapping (Gojko Adzic) | B2B with multiple stakeholders who each must change behaviour. |
| Jobs portfolio mapping | Many job stories — decide which to target by frequency, severity, strategic fit. |
| Now / Next / Later roadmap | The team needs a shared timeline view of bets. |
| Kano analysis | Sort candidate features into hygiene, performance, and delight. |
| HEART / North Star (Google / Amplitude) | Choosing the outcome metric. HEART structures the choice; North Star distils to one. |
| Wardley mapping | Positioning depends on where capabilities sit on the evolution curve; build/buy/partner. |
| Bundling / unbundling (Christensen) | Should this product own more of the workflow, or one job precisely? |
| NPE Canvas | Consumer products: Narrative, Primitive, Enablers. |
| Critical User Journeys (Google / Reforge) | Which flows to prioritise — the minimal path to core value (high-traffic, high-revenue, or metric-critical). |
When you build the tree as a diagram (graph TD): outcome at the top, branching down through opportunities grouped by journey moment, then bets, then experiments. Top-to-bottom reads as dependency, not sequence.
Working with the designer
Settle the desired outcome first, pushing for specificity. Then map the opportunities that connect to it (applying the disciplines above), generate bets for the ones worth pursuing, and identify the cheapest experiment for the most promising. Prioritise by opportunity size, assumption risk, effort, and reversibility — start with high size, manageable risk, and a clear experiment path, not necessarily the most ambitious.
Offer the technique that fits the question — an OST to connect things end to end, Kano or jobs-portfolio to choose among many candidates, Wardley or bundling for positioning. Don't run them all.
Capture only the residue: the outcome, the opportunity tree (opportunities grouped by journey moment), the top 2–3 bets with their experiments, deferred bets worth returning to, and the open questions (untested assumptions, ungrounded needs). If the needs underneath were weak or assumed, say plainly that the strategy is a bet on assumptions.
The bets chosen here define what needs designing next — the objects, relationships, and vocabulary those solutions work with: /layers-conceptual-model.
Related skills
More from jamiemill/layers-skills and the wider catalog.
layers-surface
Audit and refine UI/UX surface against underlying conceptual models, interaction flows, and accessibility standards.
layers-user-needs
Elicit and prioritize user needs, pains, and desires to ground product strategy in evidence.
layers-conceptual-model
Define your product's objects, relationships, states, and vocabulary as a load-bearing foundation layer.
layers-domain
Map domain concepts, terminology conflicts, and bounded contexts before building the conceptual model.
agent-pulse
Inspect local AI-agent activity across 13+ platforms with tokens, costs, budgets, and health checks.
architect
Think through what you're building like a senior engineer before writing code.