Lesson 04 · Prioritize features and pick the POC slice

Stories versus features

Stories are about the user. Features are about the build. The same Must story usually decomposes into three or four features — a screen, a backend endpoint, a piece of state, an empty-state. As soon as you decompose, you over-scope. That’s normal. Prioritization at the feature level is the second cut.

A worked example

Story: “As a user, I want to see last month’s spend on one screen, so that I can decide what to cut.”

Features:

Sign-in (you can’t see your spend without one)
Connect-your-bank flow
Transaction-import job
Category mapping
The dashboard screen itself
Empty state for first-time users

One Must story, six features. The dashboard is the thing the user sees, but five of the six features have to exist before the dashboard renders anything useful.

Score on value and effort

For each feature, two numbers, both 1–5:

Value (1–5)

How much does this feature move the needle on the user’s outcome? 5 = the user can’t do the thing without it. 1 = nice gloss.

Effort (1–5)

How much work? 1 = an afternoon. 5 = a week or more, with unknowns.

You don’t need RICE here. Two numbers, eyeballed honestly, beat a four-factor model that asks for inputs you don’t have. Sort by value minus effort — or just by gut after you’ve written the numbers down. The act of assigning the numbers is the work.

The POC slice: thinnest end-to-end

This is the move that makes a POC a POC and not a tiny product.

A POC is not the smallest version of the whole product. It’s the smallest path through the product that lets a real user finish one real thing.

Pick the single Must story that, if you proved it worked end-to-end, would tell you the most about whether the product is real. Then ask: what is the absolute minimum set of features required to walk a user from start to finish on that one story? That set is your POC slice. Everything else — even other Musts — is for v1.1.

The trick is naming the assumption you’re testing. “If users will connect their bank” is a real assumption. “If the dashboard looks nice” isn’t. The riskiest assumption is the one that, if wrong, kills the whole product. Build the slice that tests it.

Use Claude to score and recommend

Paste your spec from Lesson 03 into the prompt below. Claude will decompose into features, score each, and recommend a POC slice with reasoning. The reasoning is the part to argue with — if Claude picks the wrong slice, it’s usually because the riskiest assumption isn’t spelled out anywhere and it had to guess.

Prompt for Claude — features & POC slice

You are a senior product manager and a senior engineer, paired up.

Here is the high-level spec for the v1 of a product I’m building:

[paste your full spec from Lesson 03 — per-story paragraphs + system sketch]

The riskiest assumption I’m trying to test with the POC is:
[name the assumption that, if wrong, kills the product. Examples: “users will trust us with their bank credentials,” “the LLM is accurate enough to be useful,” “people will pay for this once they’ve tried it once.”]

Do three things:

1. **Decompose** the spec into a flat list of buildable features. Aim for 8–15 features. Each one should be small enough that an engineer could estimate it in an afternoon.

2. **Score** each feature on:
   - Value (1–5): how much it moves the user’s outcome
   - Effort (1–5): how much work to build
   Show the scores in a table.

3. **Recommend a POC slice** — the smallest set of features that lets one real user walk end-to-end through the single most important Must story, and that directly tests the risky assumption above.

For the slice, write:
- The list of included features (5–8 of them)
- The list of features explicitly excluded (and why)
- One paragraph: “If a user can do X with this slice and it works, we will have learned Y about our risky assumption.”

Operator story · Lesson 4

From Alon’s notebook

The POC at SimilarWeb that shipped in two weeks because the team named the riskiest assumption first — and the next one, where they didn’t, and ended up with a beautiful dashboard that proved nothing. Suggested hook: the meeting where the “what are we actually testing” question changed the scope by 80%.

[OPERATOR STORY — Lesson 10]

Tonight’s assignment

Run the prompt. Drop your top features and scores into the workbook below, then write the POC slice as a single paragraph — the included features, the assumption you’re testing, and the result that would count as a pass.

Assignment · Section 10

Score features & pick the slice

Five features with value & effort. Then the POC slice in one paragraph.

Feature 1 — name

Feature 1 — value / effort Format: V / E (e.g. 5 / 2).

Feature 2 — name

Feature 2 — value / effort

Feature 3 — name

Feature 3 — value / effort

Feature 4 — name

Feature 4 — value / effort

Feature 5 — name

Feature 5 — value / effort

The risky assumption you’re testing If this turns out wrong, the whole product is wrong. One sentence.

The POC slice One paragraph. The included features, the user journey they enable, and the result that would count as a pass.

Done with this section? Review all your answers in one place.

Review my workbook →

← Lesson 03

Write the high-level spec

Lesson 05 →

Write the PRD

Open Lesson 05 →