Hit me with your best shot

A designer on my team told me this recently:

“My PM makes prototypes in Claude.

The problem is, he thinks it’s good enough to ship and it’s not.”

I’ll give this PM some benefit of the doubt. Building a proof of concept to show an idea is possible, and to test whether it’s worth doing at all, is fair game. The trouble starts as models get better at producing work that looks and feels solid on the first try. Shipping it and moving on becomes easier than asking whether that first shot was the best one.

Most creative product people learn this the hard way at some point: your first idea is not always your best idea.

You type a series of directions to kick off a project and take the results at face value. The output looks done, so you treat it as done. Sometimes that holds up. A low-fidelity internal tool, a proof of concept, a throwaway app you built for yourself.

Sometimes it doesn’t hold up, and the cost compounds. You burned credits and hours on the first build, so you keep vibing off that code instead of starting clean, and you commit to the wrong product path too early.

Laziness and sunk cost explain part of the problem. The rest comes from the people around you. Expectations for speed have changed in 2026. Your stakeholders watched a demo come together in an afternoon, so the whole feature now gets a week, and you have no room left to argue for a second pass.

This is classic product advice from before the AI era. You jump into one solution and fall in love with it before forming a hypothesis about the problem or the people who have it. You skip the question of what separates your approach from the four competitors already doing something similar.

A one-shot without that thinking drops you onto the most obvious path available. Models generate from what already exists, so the obvious path is what they hand you.

Writing is now one of the most valuable skills a PM or designer can have. The audience is the model, not your stakeholders.

I write a real PRD when I kick off a product with AI, and I work with the model on that PRD before committing anything to code. Models need to know thoroughly what they are building. Ask one explicitly for feedback and it will point to the gaps in your thinking and show you where your writing left room for interpretation.

When I built MTCHMKR, I started with a one-pager covering the business objective, the users, the jobs to be done, and a competitor analysis. Then I asked the model to propose a build plan and to ask me questions. One came back: “What should a brand see before subscribing? A read-only preview, an editable draft after signup, or email mockups?” I had no answer, which is how I found the gap. Nothing in my one-pager accounted for signed-out visitors, and that led to externally shareable brand previews as a way to bring in new members.

Some people have declared the design canvas dead. I disagree. Sketching a handful of possible solutions burns through your first-but-not-best ideas and gets you to something worth building.

It doesn’t have to be Figma. Claude Design, Framer and Paper both produce several takes on an idea before you spend a token on code, and the output moves into a coding environment once you like what you see. Pencil and paper works too, or Procreate if you’d rather stay on a screen. Image processing is good enough now that a model can read the ugliest chicken scratch you produce and turn it into a working layout.

For MTCHMKR, I sketched the core screens in Figma and paired them with the AI-assisted PRD, so the model could see which moments mattered and how I pictured the product. That gave us common ground to start from, and it seeded the visual direction and the brand. These days I do that same work in Claude Design.

Approach that first build with humility and curiosity. Separate the excitement of “I built something that works!” with the inquisitiveness of “how could it be even better?“

Show it to someone who hasn’t seen it and try some good old cafe testing. If you want to pressure-test the value proposition, ask:

• Without knowing anything about this, what do you think it does and who is it for?

• What does it remind you of? Where does it fall short of products you know, and where does it beat them?

• Does this seem like something you’d pay for or use daily?

If you want to gut-check the execution, ask yourself or peers:

• What’s another way I could have solved this problem?

• Where does it feel clunky or less than consumer-grade?

• How would you make it faster or feel smoother to get through?

Then bring the answers back to your build. If you’re on the right path, tweak and iterate. If the feedback tells you the concept is wrong, stop tweaking. That’s when the next tactic comes in.

My most valuable lesson from Tobi Lütke at Shopify: don’t be afraid to burn an idea to the ground and start the rewrite. The second version comes out faster and cleaner. He said this before vibe coding even existed.

Now that you can build a robust application in a day, hesitating to start over costs you more than the rewrite ever will. The sunk cost you feel comes from a time when code was expensive. It isn’t anymore. Scrapping something early buys back your time.

Have you found yourself still ideating instead of settling on your one-shot? Have you ever deleted something where the full rewrite beat the original? Leave it in the comments or send me a message.