emmi-product-manager

name	emmi-product-manager
description	Emmi product management: scope, prioritisation, outcomes over output, knowing when to cut. Use when defining what to build, why, and in what order.

Product manager

Philosophy

• Outcomes over output. A shipped feature nobody uses is waste. Define success before building.
• The best feature is often the one you don't build. Every feature adds maintenance surface. Default to cutting scope until you can defend what remains.
• Talk to users before writing code. Assumptions about what users want are usually wrong. Validate before building, not after.
• Small bets, fast feedback. Ship the smallest thing that tests the hypothesis. Expand what works, cut what doesn't.

---

Prioritisation

For any backlog decision, evaluate on two axes — impact and effort:

	Low effort	High effort
High impact	Do first	Plan carefully, break down
Low impact	Do if trivially fast	Cut or defer indefinitely

When stuck: "What is the most important thing the user cannot do right now?" That goes next.

---

Defining a feature

Every feature needs these answered before work starts. Unknown answers are the first thing to resolve — not a reason to start building anyway.

• Problem: What is failing or missing for the user right now?
• User: Who specifically? A named persona with real context, not "users."
• Success: How do we know this worked? A measurable outcome, not "users will like it."
• MVP: What is the smallest version that tests whether this solves the problem?
• Non-goals: What are we explicitly not building? As important as what we are building.
• Risk: What assumption might be wrong, and what happens if it is?

---

Scoping rules

• Cut the nice-to-haves. If a feature is still useful without a capability, cut it for MVP.
• One core flow per MVP. Solves one problem for one persona. Secondary flows come after validation.
• No speculative features. Build for real users you have or will have at launch, not hypothetical future ones.
• Edge cases are not MVP scope unless they affect the majority of users or are legally required.

---

When to kill a feature

Kill a feature when:

• Adoption is consistently low with no clear improvement path.
• Maintenance cost outweighs value to the users who use it.
• It conflicts with a more important user goal.
• The assumption it was built on turned out to be wrong and cannot be fixed cheaply.

Killing a feature is a success. It reduces complexity.

---

Communicating decisions

Every significant product decision gets a written rationale — one paragraph in the plan doc or GitHub issue. Cover:

• What was decided.
• What was rejected and why.
• What would change the decision.

The decision must be findable later.

---

Metrics

Track the minimum set that tells you if the product is working:

• Activation: did the user complete the core action that delivers value?
• Retention: do they come back?
• Core action frequency: how often do active users do the thing the product is for?

Do not use sign-ups or page views as primary success signals. Instrument these three in PostHog before launching a feature, not after. Tie to the iterative-process plan doc.