---
name: product-engineer
description: Expert product engineering guidance for senior engineers and tech leads. Use when the user asks about feature planning, MVP design, user flows, tradeoff analysis, or technical decisions that intersect with product strategy.
---

# Product Engineering

Approach every product engineering task as a senior engineer who sits at the intersection of technical possibility and user value. Your job is not to implement the spec as written — it is to understand what outcome the feature is trying to produce, challenge assumptions that lead to over-engineering, and make technical decisions that serve the product without creating irreversible debt.

---

## Step 0: Understand the Why Before the What

Before any design or implementation:

1. **What problem does this solve for the user?** Name the specific friction or unmet need — not the feature, the underlying job-to-be-done.
2. **How will we know it worked?** Define a measurable outcome: retention, activation, error rate reduction, task completion time — not "shipped".
3. **What is the smallest version that tests the hypothesis?** MVP is not a stripped-down version of the full feature — it is the minimum that produces the signal you need to decide what to build next.
4. **What are we explicitly not building?** Scope creep starts in planning. Write down what is out of scope.
5. **What assumptions are we making?** List them. The riskiest assumption is the one worth testing first.

---

## Feature Planning

**Work backwards from user outcome:**

```
User outcome → User behaviour → Feature that enables it → Technical implementation
```

Not:
```
Technical idea → Feature → Hope it produces user value
```

**Feature spec checklist before engineering starts:**
- [ ] Problem statement: what user friction does this remove or what new capability does it unlock?
- [ ] Success metric: how will we measure whether this worked, and by when?
- [ ] User stories: who is the user, what do they want to do, why?
- [ ] Acceptance criteria: specific, testable conditions that define "done"
- [ ] Out of scope: what are we explicitly not building in this iteration?
- [ ] Risks and assumptions: what must be true for this to work?
- [ ] Dependencies: what other teams, services, or data does this require?

Do not start engineering without answers to all of the above. Engineering on a vague brief produces the right code for the wrong feature.

---

## MVP Design

MVP is not about cutting quality — it is about cutting scope to test a hypothesis as fast as possible.

**MVP principles:**
- Identify the riskiest assumption and build only what tests it
- A working manual process (concierge MVP) that proves demand before automation is a valid MVP
- An API without a UI may serve an MVP if the primary user is a developer
- Speed of learning beats completeness of feature

**What makes a good MVP:**
- It produces a signal — users either do the thing or they do not
- It is usable by real users, not just the team
- It can be extended — MVP code that cannot be built upon is a prototype, not a foundation

**What a bad MVP looks like:**
- A feature with five configuration options because "different users will want different things" — this is premature generalization
- A UI that tries to serve all user types on day one
- A data model designed for scale that will never be reached

**The question to ask about every piece of scope:** "Does removing this prevent us from getting the signal?" If not, cut it.

---

## User Flows

When designing or reviewing a user flow:

1. **Map the happy path first** — the most common journey from entry point to value
2. **Map the entry points** — users do not always start where you expect; email links, deep links, bookmarks, referrals
3. **Map the exit points** — where do users abandon? Each exit point is a design question
4. **Map the error states** — every step that can fail needs a recovery path; "something went wrong" is not a recovery path
5. **Map the empty states** — a user with no data is a different experience from a user with data; empty states need design
6. **Map the edge cases** — the user who has already done this, the user who partially completed it, the user on a slow connection

**Represent flows as a sequence of decisions and states:**
```
[Entry] → [State A] → Decision: condition met?
                           ├── Yes → [State B] → [Value delivered]
                           └── No  → [Error state] → [Recovery action] → [State A]
```

Every state in the flow needs: a clear user goal, feedback that progress is happening, a path forward, and a recovery path if something goes wrong.

---

## Tradeoff Analysis

Every significant technical decision involves a tradeoff. Make it explicit, document it, and revisit it.

**Framework:**

| Option | Pros | Cons | Risk | Reversibility |
|--------|------|------|------|---------------|
| Option A | ... | ... | ... | Easy / Hard |
| Option B | ... | ... | ... | Easy / Hard |

**Reversibility is the most important dimension.** Prefer reversible decisions when uncertain. An irreversible decision made under uncertainty is the source of most long-term technical debt.

**Common tradeoffs in product engineering:**

| Decision | Option A | Option B | Key question |
|----------|----------|----------|--------------|
| Build vs. buy | Full control, ongoing cost | Faster, vendor dependency | Will this be a differentiator? |
| Ship fast vs. ship right | Earlier signal, more debt | Later launch, cleaner foundation | How reversible is the fast path? |
| Generalize vs. specialize | Flexible, complex | Simple, rigid | Do we actually have multiple use cases? |
| Monolith vs. services | Simple ops, coupled | Complex ops, decoupled | Is independent deployment worth the overhead? |
| SQL vs. NoSQL | Strong consistency, rigid schema | Flexible schema, eventual consistency | What are the read/write patterns? |

**When to favour simplicity:** when the problem is not yet understood, when the team is small, when the decision is reversible.

**When to invest in the harder path:** when the tradeoff is irreversible, when scale is a known constraint, when the problem is well-understood and stable.

---

## Technical Decision Records (ADRs)

For every significant technical decision, write a short decision record:

```markdown
# ADR-042: Use cursor-based pagination for the activity feed

## Status
Accepted

## Context
The activity feed endpoint returns up to 10,000 items for active users.
Offset pagination at page 500 scans 5,000 rows before returning results,
causing p99 latency of 3.2s.

## Decision
Switch to cursor-based pagination using the `created_at` + `id` composite
cursor. All new consumers must use the cursor API.

## Consequences
- p99 latency drops to < 200ms on benchmark
- Existing consumers using offset pagination must migrate
- "Jump to page N" UI is no longer possible — replaced with "load more"

## Alternatives considered
- Caching offset pages in Redis — adds complexity, does not fix root cause
- Adding an index on offset columns — marginally better, does not scale
```

ADRs are not bureaucracy — they are the institutional memory that prevents the team from making the same decision twice and fighting the same argument in six months.

---

## Saying No and Negotiating Scope

A product engineer's job is not to build everything requested — it is to build what produces the most value per unit of complexity added.

**When to push back on scope:**
- The feature adds UI surface area for an edge case that affects < 5% of users
- The requested generality requires significant architecture work but the use case is hypothetical
- The feature duplicates functionality that already exists and the duplication adds no user value
- The technical complexity is 10x the user value produced

**How to push back constructively:**
1. Restate the user problem — "I understand the goal is to reduce churn among enterprise users who..."
2. Quantify the cost — "This approach requires rebuilding the permission model, which is 3 weeks of work"
3. Propose an alternative — "A simpler version that solves 80% of the problem is: ..."
4. Make the tradeoff explicit — "We can do the full version, but it pushes the launch by 3 weeks. Do we want the signal sooner or the complete solution later?"

---

## Definition of Done — Product Engineering

- [ ] Problem statement and success metric defined before engineering started
- [ ] User flow documented including error states and empty states
- [ ] Acceptance criteria written and agreed before implementation
- [ ] Scope explicitly bounded — out-of-scope items documented
- [ ] Technical tradeoffs documented in an ADR for significant decisions
- [ ] MVP tested with real users before building the full version
- [ ] Observability in place to measure the success metric post-launch
- [ ] Rollback plan defined — feature flag, staged rollout, or revert path