You know that moment when you pick up a book thinking it's going to be a quick professional development read, and instead it fundamentally changes how you view your role? That's what happened when I dove into Marty Cagan's "Inspired." As an engineering leader, I approached it thinking I'd gain some insight into our product partners' world. Instead, I found myself questioning everything I thought I knew about building successful software products.
Here's a confession: Like many engineering leaders, I used to think I had a pretty good handle on product development. After all, we're the ones who turn ideas into reality, right? But as I turned each page of Cagan's book, I felt a mix of enlightenment and slight embarrassment. How had I missed so many crucial aspects of what makes products truly successful?
The real eye-opener wasn't just about what product managers do – it was about how engineering, product, and design need to work together from day one. Not just in theory, but in a deeply integrated way that many of us pay lip service to but rarely achieve.
The Four Risks That Changed Everything
Cagan introduces four types of risks that need to be addressed before any significant product work begins. As an engineer, I naturally gravitated toward feasibility risks – can we build it? But the framework completely changed how I think about product development:
Value Risk: Will customers actually want this thing we're building? It's not just about whether we can build it, but whether we should.
Usability Risk: Even if customers want it, can they figure out how to use it? This goes way beyond UI/UX reviews.
Feasibility Risk: Yes, my comfort zone – can we build it with our current resources, skills, and technology? But now I see this as just one piece of the puzzle.
Business Viability Risk: Will this solution work for all aspects of our business? This is where engineering leaders often have blind spots.
Evolving Beyond Technical Leadership
The book made me realize that as engineering leaders, we need to evolve beyond just delivering technical solutions. We need to partner with product and design from the problem definition stage, not just the solution stage. Think about technical feasibility in the context of business value and user needs. Foster a culture where engineers feel comfortable questioning not just how, but why we're building something. Build teams that understand product thinking, not just coding.
The biggest impact wasn't in any specific practice or framework – it was in how I approached my role as an engineering leader. I started asking different questions in planning meetings, encouraging engineers to think about user value, not just technical elegance, building stronger relationships with product and design teams, and looking at technical decisions through a broader business lens.
Whether you're a tech lead, engineering manager, or CTO, understanding product thinking isn't optional anymore. It's not about becoming a product manager – it's about being a better technical leader in a world where success depends on the seamless integration of product, design, and engineering. The book isn't just about product management – it's about building successful products. And isn't that what we're all here to do?
The most powerful lesson wasn't even about product management – it was about the importance of stepping outside your professional comfort zone. Sometimes the most valuable insights come from exploring areas that seem adjacent to your role but end up being central to your effectiveness as a leader.
Have you read "Inspired" or had similar perspective-shifting experiences with books outside your direct field? How has it changed your approach to leadership? Share your thoughts in the comments below.