What I learned from Inspired

Here’s the book to read if you want to better understand what product managers/owners do. I enjoyed it.

This book pairs well with the empowered teams model.

Marty Cagan, the author, argues that the winning feature of modern software teams is a focus on products over projects.

A product is something you own long-term and iterate. You’re looking to achieve a business goal and you don’t stop until the goal is achieved.

A project is something you do. You’re pursuing a deliverable and whether it works or not is not your problem.

Projects can be a tool in product development (like building the next iteration of your product), but they’re not the path to tech products customers love.

The main difference between building a product and building a project is that product work never ends. You continuously iterate and make improvements.

Like kicking a can – every iteration unlocks new possibilities and improvements. Users see the new thing and think “Wow amazing, what if it could also …”.

Neither you nor the users could think of that improvement before seeing the improved new version. It wouldn’t cross your mind. Too far into the unknown. The adjacent possible is everything.

Innovative products come from thinking “What has technology just now made possible that was too difficult to do before?”.

You need to know where you’re going, of course. At least for the near future.

But stiff roadmaps are an organizational yellow flag. Roadmaps like to devolve into laundry lists of features and ideas to build.

Someone thought of a solution to their problem 6 months ago, put it at the end of the roadmap, and by the time you build that feature they no longer care. Or the problem has changed. Or the system has changed. Or … point is: feature roadmaps bad.

Instead you want a roadmap of problems to solve. Objectives to achieve. What are the business metrics you want to move? What are your best guesses on how to do that?

Focus on the business outcome, not the feature.

Everyone knows about MVP these days – minimum viable product.

But as an industry we focus too much on the minimum part and not enough on the viable part. Shipping broken software that’s cumbersome to use is not MVP. That’s just broken software.

Instead you should focus on solving the problem with the minimum number of features for a specific segment of customers. It’s okay if your new idea doesn’t work for everyone in its first iteration. Pick a segment. Solve the problem. Iterate until they love it. Expand.

Solving it is key. Nobody’s gonna use your broken feature.

You can’t do this with a feature or internal agency team model. Or, worse, external agencies and contractors.

You need people who work together on a product long-term. This need not match reporting structures. It’s fine to grab people from different teams to create a squad or whatever.

Focus on a single product that you own builds depth, evolves understanding, and helps you get it right.

Engineers and designers should be involved as early as possible. While talking to customers is best.

Cagan argues that some of the best ideas come from engineers and product designers who deeply understand both the problem domain and the technological adjacent possible. They see solutions others miss.

You want to include them early in the process because as the people building your ideas (Cagan writes to product owners), they’ll tell you what’s possible, when you’re dreaming, and even when you’re not thinking big enough.

In my experience product owners often fear something is super hard when it’s actually easy. Likewise they think super difficult things are trivial. That’s our fault as engineers. It’s the balls of mud that make this hard to predict 🙂

This is the big one – get out of the building and talk to people.

Make a prototype. Shop it around. See what people say. The earlier you can iterate with user/customer feedback, the faster you can move.

Don’t wait until you spend 6 months building a thing. Take that rough mockup and talk to users. Paint a picture with words and handwaving if you have to. Kick the can.

Cheers,
~Swizec