Pat Crowebar

Product judgment for non-technical founders building with AI. Build less of the wrong thing. Ship more of what matters.

[Pat Crowebar @patcrowebar]

Every new app idea should come with kill criteria.

Not because you are negative.

Because you are serious.

Before you build, write:

“I will stop working on this if…”

The goal is to spend your limited time where it has the best chance of mattering.

[Pat Crowebar @patcrowebar]

@Lovable @claudeai This is where the workflow gets interesting.

Claude can help shape the thinking, Lovable can turn it into software, and Claude Code can tighten the build.

The unlock is not just faster shipping.

It is keeping product intent connected from idea → design → app.

[Pat Crowebar @patcrowebar]

Before you build the whole product, find the one painful moment.

Not the category. Not the market. Not the big vision.

The moment.

Products get sharper when the moment gets sharper.

[Pat Crowebar @patcrowebar]

Don’t confuse motion with progress.

You opened Lovable, generated screens, added auth, connected a database, and tweaked the UI.

But the real question is still sitting there:

Does anyone urgently need this?

Building is now cheap enough to hide weak thinking.

[Pat Crowebar @patcrowebar]

The tools make speed possible.

One founder can now ship, design, distribute, and support without a team.

The judgment part did not get easier.

You can ship a full app in days. You can also ship a full app that solves a problem no one feels.

The second option is much easier to do by accident.

The founders who use this window well are the ones who got better at the questions that come before the first prompt.

[Pat Crowebar @patcrowebar]

Founder drift is when you keep building because deciding is uncomfortable.

You add one more feature.

Then one more screen.

Then one more workflow.

But the hard question remains:

“Is this worth shipping?”

The cure is not more building.

The cure is a clearer decision.

[Pat Crowebar @patcrowebar]

I spent years in product management watching teams move in the wrong direction.

Now I see the same thing happening with AI builders.

The tools are faster.

The risk is the same.

Building the wrong thing still wastes time, energy, and momentum.

The tools changed.

The need for clear thinking did not.

[Pat Crowebar @patcrowebar]

Product judgment is not a feeling.

It is three answers you can write on paper.
- The problem worth solving.
- The person who feels it.
- The outcome that matters to them.

If you cannot write them, the build will wander.

[Pat Crowebar @patcrowebar]

Most aspiring founders describe features before they know the problem.

The fix is simple but rare.

Write three lines first.

What exactly am I building?
Who feels this pain today?
What does done look like for them?

Then the prompt writes itself.

[Pat Crowebar @patcrowebar]

Most AI tools promise: “Build 10x faster.”

They forget to say: “And 5x more likely to build the wrong thing.”

The antidote is product judgment.

Not more speed.

Better direction.

[Pat Crowebar @patcrowebar]

Vibe coding feels like momentum. It is not.

More generated screens do not equal progress. A clearer problem definition does. A sharper scope does. A validated bet does.

Stop measuring by lines of AI output. Start measuring by how much less wrong your product is becoming.

[Pat Crowebar @patcrowebar]

These 20 rules fix execution. They do not fix direction.

Non-technical founders can follow every single one and still ship the wrong features faster than ever.
Product judgment decides what should be built at all.
Answer the three questions in Rule 1 before you ever open the tool.

Then use the rules. Otherwise you are just executing bad ideas more efficiently.

[Pat Crowebar @patcrowebar]

@PrajwalTomar_ Speed is here. The danger stays the same.

You can now build the wrong MVP much faster than before.

Product judgment decides whether those features actually matter before you connect the next tool.

[Pat Crowebar @patcrowebar]

Vibe coding can trick you into thinking progress means more screens.

It does not.

Progress means the product is becoming easier to understand, easier to use, and more clearly valuable.

A generated feature is not progress by itself.

A clearer product is progress.

[Pat Crowebar @patcrowebar]

Feature sprawl feels productive.

It is usually fear.

Fear that the core idea is not strong enough. Fear that users will not care. Fear that the app looks too simple.

But simple is not the enemy.

A small product with a sharp promise beats a large product nobody understands.

[Pat Crowebar @patcrowebar]

A simple MVP rule:

Write for one user. Build for one situation. Solve one painful moment.

Early products do not win by covering more.

They win by mattering more to someone specific.

[Pat Crowebar @patcrowebar]

A strong app idea usually has one of these signals:

- people already pay for a workaround
- people complain about it repeatedly
- people use spreadsheets to manage it
- people ask others for help with it

Pain leaves evidence.

Look for the evidence before you build.

[Pat Crowebar @patcrowebar]

Before you build an app idea, ask:

“Who is already trying to solve this problem without my app?”

If the answer is “no one,” be careful.

That can mean you found a hidden opportunity. But it often means the pain is not strong enough yet.

[Pat Crowebar @patcrowebar]

AI can help you build faster.

Product thinking helps you build what matters.

The second part is where most founders get stuck.

Not because they are lazy.

Because the tools moved faster than the decision systems around them.

That is the space I care about.

[Pat Crowebar @patcrowebar]

You may not write the code.

But you still own the product judgment:

- who it is for
- what pain it solves
- what belongs in v1
- what good looks like
- what should not ship yet

That is real founder work.