Start With the Smallest Valuable Loop

The first version of a product should prove one loop, not the whole vision.

A loop has a user, an action, a result, and a reason to come back. If that loop is weak, adding more screens only gives the weakness more places to hide.

A feature is not a loop

A feature can exist without changing behavior. A loop has to move someone from intent to outcome.

For example, “create a dashboard” is a feature. “A manager sees the three blocked projects before the Monday meeting” is a loop. The second one is easier to judge because it has a moment, a user, and a consequence.

Useful beats complete

Complete systems are expensive to build and expensive to change. Useful loops are easier to test.

The first question is not “What can this become?” The first question is “What is the smallest thing that would be missed if it disappeared tomorrow?”

What to cut

Cut anything that does not help the loop finish:

• settings that only serve future edge cases
• dashboards without a recurring decision
• onboarding copy that explains features the user cannot use yet
• integrations before the core workflow works manually

What to keep

Keep the parts that create proof: a real input, a real output, a real review point, and a real user who cares.

Once the loop works, expansion becomes safer. The product has a center.