[pwarner]

I work at a less innovative place, and I see out product managers coming with prototypes, at least solid mock ups rather than just a jira. They socialize it with potential users, they iterate, they find missing requirements, it's pretty powerful. The net result is we're building better features faster.

[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.

[FromTheFirstIn]

How can you be less innovative than Block? Their products are 100% ripoffs of better products

[blehn]

Eh, Square and Cash App were pretty innovative when they came out. The industry is mature enough now that all the products are ripping each other off

[pityJuke]

I mean Cash App is simply a workaround for the US Banking systems lack of a unified transfer system.

[mrits]

I prefer prototyping to slides. The reason is it helps me understand the problem and edge cases better. Getting AI to build means you could potentially understand it even less than if you put the slides together.

Hiring talent that is passionate about delivering a quality product is more important than ever considering there are so many ways to take shortcuts now that might not be obvious until later.

[alephnerd]

Can confirm this in my portco's and a couple other peers (one of whom previously founded a major threat intel platform).

If you have product-minded Engineers and engineering-minded PMs, you can merge the two into a single function and remove much of the friction surrounding requirements, prototyping, and launching MVPs.

A couple of these products are already being deployed by F100 security teams as we speak. I also know of one F10 that's building it's own entire security platform from scratch with a team of security engineers working directly with one of the foundation model vendors.

Too many people on HN are divorced or too OOTL from some of these initiatives and then get blindsided during layoffs.

What matters now is DOMAIN EXPERIENCE. Do you understand good development principles and the problem your ICP is trying to solve and how pricing, packaging, and procurement is structured? I don't need a code monkey, process sloths, and queens of the calendar. I need domain experts who can actually execute.

[OneDonOne]

Stupid question from a foreign newbie.

What separates a code monkey from a domain expert? Can you use infosec and embedded systems as two examples please?