- Home
- Skills
- Menkesu
- Awesome Pm Skills
- Strategic Build
strategic-build_skill
166
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill menkesu/awesome-pm-skills --skill strategic-build- SKILL.md12.0 KB
Overview
This skill helps teams distinguish strategic work from tactical busy-work using Shreyas Doshi’s LNO and Three Levels frameworks plus Marty Cagan’s empowered-team principles. It guides decision-making on what to build, when to abstract, and when to say no. Use it to prevent product theater, avoid feature-factory traps, and prioritize work that compounds over time.
How this skill works
The skill inspects proposed work through three lenses: LNO (Leverage, Neutral, Overhead) to classify impact; Three Levels (Impact, Execution, Optics) to ensure the "why" is clear before the "how"; and a pre-mortem to surface failure risks. It also checks team framing—feature vs problem—to promote empowered teams. Outputs are clear recommendations: prioritize, pause to define, redesign, or skip.
When to use it
- Deciding whether to build a new component or abstraction
- Choosing between quick fixes and long-term investments
- Evaluating feature requests from stakeholders
- Making architectural or cross-team decisions
- Preventing premature optimization or product theater
Best practices
- Aim for ~70% Leverage, 20% Neutral, 10% Overhead across work
- Always validate Level 1 (impact and success metric) before Level 2 (execution)
- Run a quick pre-mortem for major bets to identify top risks and mitigations
- Build shared abstractions only after ~3 real use cases to avoid premature refactoring
- Reframe feature requests into user problems and measure outcomes, not velocity
Example use cases
- Assess whether to refactor a UI component into a design system entry
- Decide if a proposed API endpoint merits full investment based on expected reuse
- Prioritize roadmap items by LNO classification and business outcome
- Run a pre-mortem before committing to an ML-driven feature to reveal data and latency risks
- Shift a feature team to an empowered-team approach by reframing roadmap goals as outcomes
FAQ
Ask: Will this be used 10+ times? Does it unblock future work? Is it merely maintenance? Use the answers to mark Leverage, Neutral, or Overhead and prioritize accordingly.
When should I run a pre-mortem?
Before committing to major architecture or product bets—think any work with high cost, cross-team impact, or unclear success metrics. Imagine failure six months out and address the top risks.