Learning to Say No

phototype-labs-3.png

Once the problem is validated, the temptation is to build everything.

This is where most founders fail.

I learned that an MVP isn't "a smaller version of the product." It's one workflow that solves one problem well.

The MVP delusion

Your mind will do something insidious: it will start adding features.

"We should support this integration."
"Users will definitely want this."
"It's only a little more work."

Every feature you add before users ask for it slows learning. Every delay postpones reality. Constraints breed creativity.

How to find your core workflow

Ask yourself:

For a project management tool, that might be: "Users can create a task and see it in a list." Not: "infinite views, custom fields, integrations, advanced reporting."

For a design tool, that might be: "Users can create a canvas and draw shapes." Not: "all the Adobe features compressed into a browser."

What you're cutting

You're cutting:

Will some users ask for these? Yes. That's good. That means you're building something worth wanting. You can add them later, when you understand which ones actually matter.

The real work

The real work now is ruthless prioritization. Every team member will have ideas. Every conversation will suggest new features.

Your job is to say no without explaining. "No, that's Phase 2." "No, that's not our core workflow." "No, if that's critical, we'll learn it from users."

When you're ready to build

You're ready to start the MVP when:

That discomfort is good. It means you've found the minimum.

Restraint here is a superpower.

Next — Phase 4: MVP