One of the most rewarding parts of teaching innovation is that it provides an outsider’s perspective on problems I spent decades wrestling with firsthand. Working with students allows one to evaluate strategic decisions that look entirely different when you’re standing inside the tornado.
At the same time, rapid advances in generative AI have rewritten the product development playbook. Practices that were standard operating procedure just a few years ago today look remarkably dated, and in many cases short-sighted.
Goodbye MVP, Hello IUP
Throughout my career in software, the playbook was clear: to test an idea, you needed to create a Minimum Viable Product (MVP).
Creating an MVP was neither fast nor cheap. It required real capital and scarce runway. Technical founders invested primarily their own time; the rest of us needed to hire engineers and of course pay them with cash and/or equity.
That friction, however, was a feature, not a bug. Because building cost time and money, founders were forced to think critically, interrogate hypotheses, and talk to prospective buyers before writing any lines of code.
These days, AI has driven the cost and time of initial software development to near zero. As Steve Blank pointed out in a recent series of essays, when the friction of building goes to zero, the traditional MVP stops being reliable evidence of customer discovery or validation. Instead, it becomes an Initial Untested Product (IUP).
“MVPs were also no longer reliable evidence of customer discovery, critical thinking, hypothesis testing, product/market fit or even commitment.”
Steve Blank - “AI Killed the MVP” - Poets & Quants
The Siren Call to Build First
This semester, I’m teaching 2 sections of a prerequisite course called Innovation! at Northeastern. The students are bright, motivated, and demonstrate the benefits of the university’s unique experiential learning model, as referenced in a recent HBS case study. I’ve taught this course previously, yet this semester it feels especially challenging to get them to turn their attention away from what they want to build so they can focus on potential customer needs.
Their instinct is understandable. Entrepreneurship and innovation have been romanticized as the act of building things. When AI eliminates technical barriers, the urge to start building - immediately - becomes irresistible.
I’m not just preaching from an ivory tower, as to some degree I’ve fallen into this trap myself. Over my summer break from the classroom, I built two shiny IUPs of my own: a Build vs. Buy calculator (BvB) and a platform analyzing Competition for Capital (CfC). CfC is intended to be a first principles approach to buyer requirements, starting with the business problem rather than the solution set. Technically, I’m proud of both, and I use them all the time—especially CfC. BvB started as a client project, but CfC was pure founder conviction: as a former industry analyst earlier in my career, and a frequent consumer of research services more recently, I figured I knew exactly what the market needed.
Because that market was me. Every conversation I have with a potential customer, however, reminds me that meeting my needs doesn’t imply that I’m solving anyone else’s. This work is more of an experiment than a business model at this point, but if I were truly betting my career on it, I’d still be at the starting line.
It’s Not About You
When you show an IUP to a potential customer, discovery effectively disappears. You aren’t conducting an interview; you’re doing a demo. The conversation immediately shifts from their problem to your feature set.
An untested prototype anchors the founder’s ego to a concrete artifact. Since you built it, you feel an overwhelming compulsion to promote it, defend it, tweak it, and hunt for anyone who will validate the time you spent prompting it into existence. You seek validation rather than input, which risks confusing motion with traction.
Having a working product on day one doesn’t make you agile, and in many ways works against agility. It simply means you’ve automated the process of building things before knowing whether anyone actually wants to buy them.
The Only Moat Left
If the cost of building goes to zero, having a “product” is no longer a differentiator, nor does it provide any real moat. The only defensible advantage left is customer understanding.
The founders who win won’t be the ones who prompt a prototype into existence over a weekend. They will be the ones disciplined enough to hold back on coding - even though it’s cheap and undeniably fun - until they deeply understand the problem they are solving - and the Jobs To Be Done.
Cheap code gives you velocity, not vision. Until you really know whether anyone wants to buy what you’re building, writing code isn’t moving you forward. It is distracting you from the hard work of finding out.