The Single Thread
Find the product's main task; every other feature is a supporting role.
Find the product's main task; every other feature is a supporting role. A product can do only one thing outstandingly well. Pick it, and demote everything else to "good enough." The minimum viable product idea rests on the same premise: decide the one core thing first and validate it with the smallest scope, instead of piling on everything you'd like to build.mvp-wiki
What you'll run into:
- There's plenty of functionality, but users can't say where you beat the alternatives
- Every module is half-finished, and none of them is good enough
- When a new feature comes up, you don't know how much effort to give it, so you decide by mood
Resources are fixed, and so is attention. Spread your effort across five directions and you get five things that just barely pass—and nobody recommends a product that just passes. The point of a main thread is to give you a legitimate reason to do "good enough" on the other four.
Finding the thread isn't picking a direction by feel. It lives in the intersection of user behavior and your strength: the thing users do repeatedly, which you also happen to do better than peers, is usually the thread. You need evidence on both sides; a thread chosen on one side alone won't hold.
How to find the main thread
| Look here | Ask how |
|---|---|
| The action users repeat most | What's the step they do most often in a day on your product |
| The sentence they'd tell someone | If they recommended it to a friend, what would they say it "lets you do" |
| The thing that kills the product if cut | Cut features one by one hypothetically; which one, once gone, makes the product not exist |
| The one you can do best | Among all directions, which are you clearly better at than your peers |
The third is the most practical. Cut things one by one; anything you can cut isn't the thread. The one that takes the whole product down with it—that's the thread.
How to split the resources
A rough but useful ratio: the main thread takes seventy percent; the other four directions split the remaining thirty. Drawn as a chart, it's one tall bar and four short ones—the main bar stands out at a glance, and the four supporting bars only need to be there.
The standard for a supporting role is "don't drag the main thread down." It doesn't need to impress, but it must not break, and it must not be so awkward that people get stuck halfway.
The 70/30 split isn't generosity; it's attention. A person's attention holds one or two things at a time, and a team's is no different. The seventy percent isn't a reward for the main thread—it's the minimum cost of keeping it excellent.
How to hold the line
- Every new feature has to answer one question: does it strengthen the main thread, or dilute it? The diluting ones aren't off-limits, but they go to the back of the line.
- The homepage serves only the main thread. What you put on the homepage is your public statement of what the main thread is (see one screen, one job).
- The main thread experience has to be clearly better than peers, not slightly better. A little better doesn't move anyone; it usually has to be better enough that the user feels it at a glance.
- The main thread can be swapped, but only one at a time. If you picked wrong, switch wholesale—don't end up defending two at once.
Every new feature can be measured against the thread: does it make the thing users do repeatedly faster? If yes, it earns a place; if it's just "while we're here," it goes to the back. A feature you can't answer for is usually a supporting role among supporting roles.
The same ruler does subtraction: a feature that doesn't serve the thread, no matter how polished, is pulling attention away from it. Cut it, and the thread's advantage gets clearer.