Neil

I think this is a great way of framing our pitch.

Okay, here’s a question. If you had to clearly articulate to a layperson what is “the hard part,” what would you say? I have my answer, but I’m curious what you would say.

William

His answer is that the hard part was marketing and distribution. Someone outlined a hierarchy where engineering is #4 out of 4. I don’t like these status games and it perpetuates the toxicity I’ve fought against my whole career. So my stance is … definitely not that 😄

I do value marketing, sales, and distribution. I think engineers don’t give it enough credit, and engineers actively make other people feel dumb, but it’s because they feel bullied and jerked around by people who are exploring the market. Engineers characterize this as “they don’t know what they want.”

I do think the hard part has always been PMF. The best way to get PMF is to have everyone aligned on the design process. In our hypothesis terms: here’s what we think the market is telling us, so here’s the product / feature we’re building, we need to build and ship it fast so go-go engineers, but it might not work so get ready to delete it and try something else.

My rough stance is that everyone needs to be a participant in that design process and AI is pushing everyone’s jobs closer together. Specialization matters less and the need for speed in SDLC cycles is greater than ever.

Neil

I’m writing some stuff going back and forth with Claude and I wrote this, which I think captures my view:

“I think all of the above. We have years of frameworks to help companies be hypothesis-driven from start to finish. One thing I say is that an investment pitch can be re-framed as ‘In order for my business to work these 10 things must be true. I am building an experiment to prove those 10 things true or false.’ It’s very rare that one of those hard-to-prove things is ‘building an app’ or even ‘making a really nice UI.’ There are some times this important, but it’s less important than people think. Product market fit, go to market, value produced, market sizing, revenue model - all those are more ‘hard to prove’ than the tech. At least for tech startups, oftentimes the tech is THE TOOL to conduct those experiments, not an experiment in and of itself. Building an app is the easy part. Making the app’s development part of the journey of your business strategy the hard part. Losing sight of this is a big issue.”

Marcy

ha, here’s claude’s first shot at my response:

“Right, and the hard part was always figuring out what to build — the hypothesis, the scoping, the translation of business value into something a developer can actually execute on. That’s what we’ve been selling for 15 years, we just didn’t have language for it because the coding was the visible work.”

And then probably: “This is exactly why we need to be positioning above the AI line. The app-building commoditizes, but the knowing-what-matters doesn’t. That’s pattern recognition. That’s the 200 apps. That’s why Forward Deployed Engineering is the play — you’re not paying for the code, you’re paying for someone who can look at your messy problem and know which 20% of it actually needs to get built first.”

You might also add that this is why the test-first gate matters more now, not less. If anyone can vibe-code an app, the bottleneck shifts entirely to specification quality. The people who can write a tight hypothesis and testable acceptance criteria become more valuable, not the people who can implement them.

The thing that keeps coming up in my head is William’s surgeon metaphor – being able to rapidly test toward that north star in small, discrete chunks, differentiates between excellent developers and intermediate ones. The hard part is creating these testable feedback loops, and the nice thing is they can happen faster, to move you toward PMF.