Some time ago I read "Inspired" by Marty Cagan. It's a book about product management, but as someone who builds custom software for clients, I found it surprisingly useful for my own work.
The book talks about how companies like Google and Netflix build products that people actually want to use. Most of it is about internal product teams, but several ideas changed how I approach client projects.
What "Inspired" Is About
Marty Cagan spent years working at companies like eBay and Netscape. He noticed that most product teams fail because they build the wrong things. They spend months creating features that nobody wants.
His solution? Focus on solving real problems for real people, not just building what stakeholders ask for.
Four Ways It Changed My Approach
1. I Started Asking "What Problem Are We Solving?"
Before reading this book, I used to take client requirements at face value. Client says they need a CRM system? I build a CRM system.
Cagan's approach made me dig deeper. Now I ask: "What problem is this supposed to solve?"
Often, the real problem is different from what the client initially describes. A client might ask for a complex inventory system when they really just need better visibility into their stock levels. Understanding the actual problem leads to simpler, better solutions.
2. I Stopped Building Everything at Once
The book talks about building prototypes to test ideas before writing production code. This was a game-changer for my client work.
Instead of disappearing for months to build a complete system, I now create quick prototypes for the most important features first. We test them with real users, learn what works, and adjust before building the full version.
This approach saves time and prevents the nightmare scenario where you build something perfectly... and nobody uses it.
3. I Focus on Outcomes, Not Features
Cagan talks about the difference between feature teams and outcome teams. Feature teams just build what's on the list. Outcome teams focus on achieving specific business results.
I apply this to client projects by always connecting features to business outcomes. Instead of "build a user dashboard," I think "help users complete their tasks 50% faster."
This shift in thinking makes me ask better questions and build more useful solutions.
4. I Involve Engineers in Problem-Solving
One of Cagan's key points is that engineers are often the best source of innovation. They understand what's technically possible and can suggest better solutions.
I used to present clients with fully designed solutions and ask my team to implement them. Now I involve developers in the problem-solving process from the start.
This leads to more creative solutions and helps avoid technical problems early in the process.
What I Don't Use
The book has a lot of advice about internal product teams, roadmaps, and company culture that doesn't apply to custom development work. I also skip the parts about user research departments and complex organizational structures.
But the core ideas about focusing on real problems and testing solutions early? Those work for any kind of software development.
The Most Important Lesson
If I had to pick one thing from the book that changed how I work, it's this: Don't build something until you understand the problem you're solving.
This sounds obvious, but it's harder than it seems. Clients often come with solutions, not problems. They say "I need a mobile app" instead of "I need to reach my customers more effectively."
Learning to dig deeper and understand the real problem has made my projects more successful and my clients happier.
Should You Read It?
If you're building custom software for clients, yes. Even though it's written for product managers, the core principles apply to any development work.
The book is practical and easy to read. Cagan uses real examples from companies like Netflix and Google to explain his points.
Skip the chapters about internal team structures and focus on the parts about problem discovery and solution testing. Those are the most useful for client work.
Final Thoughts
"Inspired" didn't just change how I build software - it changed how I think about software. Instead of seeing myself as someone who codes what clients ask for, I now see myself as someone who helps solve business problems using technology.
That shift in perspective has made my work more interesting and my solutions more effective.