Layers Product Strategy
- 1.6k installs
- 282 repo stars
- Updated May 30, 2026
- jamiemill/layers-skills
layers-product-strategy is a planning skill that helps developers systematically connect user opportunities to measurable business outcomes and low-risk solution bets before writing code within the Layers framework.
About
layers-product-strategy is the first layer skill in jamiemill/layers-skills, treating strategy as the conversion point from problem-space understanding into deliberate scope and direction choices. It is a library of techniques—not a fixed script—for deciding which user needs to serve, which business outcomes to target, and how to test the riskiest assumptions cheaply before build. Developers reach for layers-product-strategy when feature ideas exist but outcome alignment, opportunity prioritization, or assumption risk is unclear. The skill assumes layers-intro is loaded and complements layers-orient, which identifies which layer needs attention. It produces explicit decisions about business outcomes, user opportunities, and solution bets rather than jumping to implementation.
- Connects problem-space opportunities to bounded, measurable business outcomes
- Defines clear solution bets and identifies riskiest assumptions to test cheaply
- One-outcome-per-tree discipline with explicit flip-test to avoid solution language
- Library of techniques that works before any creative implementation work
- Produces prioritized bets with cheap validation paths as handoff to implementation planning
Layers Product Strategy by the numbers
- 1,584 all-time installs (skills.sh)
- +129 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #370 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/jamiemill/layers-skills --skill layers-product-strategyAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.6k |
|---|---|
| repo stars | ★ 282 |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 30, 2026 |
| Repository | jamiemill/layers-skills ↗ |
How do you scope product strategy before writing code?
Systematically convert user opportunities into measurable business outcomes and low-risk solution bets before writing code.
Who is it for?
Product-minded developers and tech leads who must align user needs with business outcomes before the Layers framework build layers begin.
Skip if: Teams with frozen requirements and signed-off specs who only need frontend or backend implementation guidance.
When should I use this skill?
The user discusses product strategy, business outcomes, user opportunities, assumption testing, or the first layer of the Layers framework before coding.
What you get
Documented business outcomes, prioritized user opportunities, solution bets, and cheap tests for riskiest assumptions.
- business outcome definitions
- prioritized user opportunities
- solution bet list with assumption tests
Files
/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
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kHow it compares
Use layers-product-strategy for outcome and opportunity framing; use layers-orient first when unsure which of seven layers needs attention.
FAQ
What decisions does layers-product-strategy cover?
layers-product-strategy addresses the business outcome the work serves, which user opportunities to prioritize, and which solution bets to pursue. It also guides cheap tests for the riskiest assumptions before developers commit to implementation.
Is layers-product-strategy a step-by-step script?
No. layers-product-strategy is a library of techniques within the Layers framework first layer. Developers select approaches based on context after loading layers-intro, rather than following one fixed workflow end to end.
Is Layers Product Strategy safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.