[wenc]

We need to match the tool to the uncertainty we're facing.

The "just prototype it" thinking addresses "feasibility uncertainty". It surfaces blind spots and helps people tangibly reason about what the product looks like. It's a great exploratory tool for incremental ideas.

But it doesn't address the the larger uncertainty that startups are faced with: "market uncertainty" (or pmf). It doesn't answer "should we be building in this the first place?" That's where writing as a tool of thought is most powerful -- it helps you crystallize what problem we're actually solving.

The "just prototype it" culture (which is being promoted these days because Claude Code makes it easy) risks answering the wrong question, or at least the right question but in the wrong order. You end up with organizations that are incredibly fast at building things that no one should have built.

Ironically sometimes you need to start from a lower resolution (i.e. writing a doc). Prototyping too early is premature optimization.

[pjjpo]

I really agree with a lot of this but also think it may be hitting a bit too hard. It may be most applicable to engineer founders.

My anecdote is that, after a few stings with non-technical founders, a doc etc will not improve the chances to reach PMF and prototypes that they can understand can improve the chance.

Outside of the startup context, I have also seen prototypes (hand written way back when that was a thing) resonate with FAANG directors much more than brainstorming.

I am very much for not just vibe it, and the biggest risk of prototypes is they lend to just directly launching broken systems to production. But I think this is a different topic than reaching PMF.