Key Takeaways
- In the first edition of Inspired, Marty Cagan omitted business viability as a standalone product risk, focusing only on value, usability, and feasibility.
- Cagan traces his blind spot to his early career building developer platforms, where business modeling felt secondary to technical utility.
- Product managers often skate by with weak commercial skills because companies let them act as feature coordinators rather than business owners.
- Modern software and AI products fail when product managers cannot handle the hard constraints of legal, privacy, finance, and go-to-market mechanics.
The Blind Spot in the Original Product Playbook
Marty Cagan spent two decades shaping how technology companies build software. Yet taking the stage at the Lenny and Friends Summit, he began his review of past advice with an apology.
“The first one I want to start with is business viability because that's honestly the most embarrassing of them,” Cagan said. “There is no way for me to get around this. I completely understated the importance of business viability.”
When Cagan published the first edition of Inspired, he taught an entire generation of product leaders to test for three risks: value (will users choose it?), usability (can users figure out how to use it?), and feasibility (can engineers build it?). Viability did not even make the list as a primary risk. It sat buried in the margins.
That omission left a generation of product managers believing their sole responsibility was discovering what users wanted and helping engineers ship it. In reality, a product that users love but finance cannot price, legal cannot approve, or sales cannot close is a dead end.
Why Developer Tools Distorted the Model
Cagan admitted where his bias originated: his early career in developer tools.
When you build tools for software engineers, value and technical feasibility dominate the equation. If developers find the API clean and the tool solves their immediate bottleneck, adoption follows fairly direct paths. The business mechanics around compliance, regulatory frameworks, privacy rules, and channel sales remain relatively simple compared to consumer applications or complex enterprise platforms.
That background created a false sense of security. As Cagan pointed out, “It's one of the few areas where a product manager can get away with pretty weak skills.”
When product managers migrate from simple developer utilities or pure feature factories into modern applications, that skill gap becomes fatal. An AI feature might delight users in a demo, but if it leaks proprietary customer data, violates regional compliance laws, or runs compute costs that destroy gross margins, it is a failed product.
Product Managers Must Own the Commercial Equation
User empathy without commercial literacy is hobbyism. A product manager who cannot read a profit and loss statement or understand customer acquisition channels cannot make real trade-offs.
Building products that work for the business means stress-testing solutions against every operational constraint before writing code:
- Financial feasibility: Does the pricing model sustain healthy unit economics and account for infrastructure costs?
- Legal and compliance: Does the feature trigger regulatory exposure or breach data privacy agreements?
- Sales and marketing: Can the current go-to-market motion sell this product without reinventing the entire sales playbook?
If you treat those questions as afterthoughts for the finance and legal departments to handle after launch, you are not managing a product. You are just running a backlog.
What to Do With This
Audit your current roadmap against business viability before your next sprint planning meeting. Take your top feature and sit down with your legal counsel, finance lead, or sales director for 30 minutes. Ask them one question: "What hidden cost or policy constraint would kill this feature after launch?" Fix the commercial viability before your engineering team writes a single line of production code.