Conflicting Clarity

Last week I ran a 1-hour MVP workshop with a cross-functional group in San Francisco. Founders, designers, engineers, operators. About twenty people total.

We did a simple exercise. Sticky notes. Definitions of MVP. Current blockers. Where projects tend to drift.

What surprised me was this:

Nobody seemed confused about what an MVP is.

Everyone already knew the textbook answer.

The friction showed up somewhere else.

One team thinks MVP means: “Get something in market fast.”

Another thinks: “Test assumptions before we overcommit.”

Another thinks: “Build the core experience properly.”

All reasonable. All defensible.

The problem is those definitions pull in different directions.

So you end up with teams saying “we need an MVP” while quietly optimizing for completely different outcomes.

That felt strangely familiar to me. I’ve seen versions of this inside larger organizations too. Especially in enterprise software.

You’ll have ten people sprinting toward “the MVP” through Jira tickets and standups and roadmap meetings…

…but if you stop and ask:

What are we actually trying to learn right now?

…the answers can vary wildly.

The problem with “minimum”

I kept coming back to the word minimum.

I think it’s overloaded.

Sometimes minimum means:

• least engineering effort
• fastest possible ship date
• smallest feature set
• quickest path to validation

Those are not the same thing at all.

A team can optimize aggressively for one while quietly undermining another.

This also explains why so many organizations overbuild.

Not because they lack discipline.

Because nobody aligned on what uncertainty the MVP was supposed to reduce in the first place.

• Customer behavior?
• Market demand?
• Usability?
• Stakeholder confidence?
• Revenue potential?

Those lead to very different MVPs.

AI and the disappearing pause

One participant wrote something on a sticky note that stuck with me:

“AI-assisted product + design is harder to simplify.”

I don’t think they meant AI tools are bad.

I think they were describing a feeling.

Building now feels easy.

You can prototype faster. Generate faster. Ship faster. Iterate faster.

Which sounds great until you realize the reflective pause before building is disappearing.

That small moment where a team sits together and asks:

Wait. What are we actually trying to learn from this?

AI accelerates execution beautifully.

It does not automatically improve intention.

In some ways it may actually reward momentum before clarity.

That feels important.

Because most teams don’t overbuild because they’re reckless.

They overbuild because motion feels productive, especially when the cost of producing artifacts keeps approaching zero.

The discipline of not building has to become intentional.

That is not a tooling problem.

It is a human one.

What the strongest teams do differently

The strongest teams I’ve worked with weren’t necessarily the fastest builders.

They were the clearest about:

• why they were building this version
• for which audience
• to reduce which uncertainty
• and what signal would determine the next move

That clarity changes everything.

Otherwise “MVP” becomes a deadline label attached to motion.

Not learning. Not strategy. Just momentum. 🫠