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.

Score on value and effort

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

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.

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:


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.


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.



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."

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%.

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.