Install any skill in seconds. Free to start, no credit card required.
Get Started Free →syahiidkamil/super-product-owner
Complete Product Owner / Product Manager capability — a wiki-style knowledge map of product practice in active software development: the role and its boundaries, strategy cascade (vision → OKRs → roadmap → backlog), continuous discovery, backlog craft (epics, INVEST stories, acceptance criteria), prioritization frameworks (RICE, MoSCoW, Kano, WSJF), sprint delivery, metrics (North Star, AARRR), stakeholder management, and anti-patterns. The PO/PM owns what gets built, in what order, and why — in
Passed 17 of 22 test cases with the skill, and 17 of 22 without it.
2 fixed15 passed either way3 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our startup is building a new automated logistics platform. The founders want to spend six months building a complete web dashboard, automated routing engine, and driver mobile app before launching Version 1. How should a product manager redefine the MVP approach?
| Checked | Without skill | With skill |
|---|---|---|
| Defines an MVP as the smallest experiment required to validate the riskiest assumption. | Missed | Passed |
The instructions your model reads when the skill loads.
Same format as the UI/UX schemata: a wiki of linked nodes with Mermaid diagrams. Build the schema, then go get it broken by real stakeholders, real engineers, and real users.
Internal links like Prioritization jump between nodes. Mermaid renders in Obsidian, GitHub, and Notion.
This is the upstream half of a two-skill pair. The super-ui-ux-design schemata governs how the product looks, feels, and converts; this one governs what gets built, in what order, and why — the decisions that exist before a single screen is sketched. On a real build you wear both hats in sequence: the PO/PM hat chooses the outcome, the slice, and the order; the design hat shapes its surface. When the question is scope, priority, or value, you are here. When the question is the interface, go there. The two documents deliberately rhyme — same wiki-of-nodes format, same constructivist spine — because they are one schema with two layers: Kano's basics mirror the UX Hierarchy of Needs, discovery's ~5-user tests are Node 5 of the UI/UX schemata, and "outcome over output" is the product-level twin of "aesthetics is a multiplier, not a substitute."
One boundary deserves stating up front because teams get it wrong constantly: the Product Owner / Product Manager is responsible for User Flows and User Journeys as well. The end-to-end journey — how a user discovers the product, enters it, moves through each core task, hits the moments of value, and comes back — is product territory, not a design afterthought: the journey encodes what the product is. The PO/PM owns that the steps exist, connect, and serve the outcome (journey maps, flow definitions, the path through every capability in Node 0's scope); the designer, through super-ui-ux-design, owns how each step on that path looks and behaves. A beautiful screen inside a broken journey is a well-decorated dead end — and that failure belongs to the PO, not the designer.
With that frame set, build the schema below.
mindmap
root((PRODUCT<br/>OWNER / MANAGER))
The Role
Value maximizer
Decision owner
PO vs PM vs PjM
Desirable · Viable · Feasible
Strategy Layer
Vision
Product Strategy
Roadmap
OKRs
Discovery
User research
JTBD
Opportunity Solution Tree
Assumption testing
MVP & prototypes
test cases passed, vs 17 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.