Sign in

Product management for software developers

In many software companies, the Product and the Engineering departments are very closely connected. While many companies keep the two departments separate, there are also companies that would have the Product org inside the Engineering org, and vice versa. Regardless of how your company is organized, I believe it’s important for engineering leaders to have a good understanding of how great software products are designed.

At my current company, all engineering leaders are also expected to be product owners for their product areas. Even though I have been doing this for a number of years now, I found my education background lacking in this area.

There are actually a number of great readings on product management. One of the highly recommended books is called “ Inspired — How to create tech product customers love “ by Marty Cagan. The book covers a lot of what I’d call modern product management and leadership ideas, and in general, advocates the agile methodology. Here are my top takeaways (I actually wrote 8 pages of notes to myself, but I don’t think many people here are interested to read through 8 pages)

Key takeaways

  • Experimentation vs planning. Instead of planning what the product should look like, products should be built incrementally by going through many iterations of experimentations. The traditional top-down waterfall method of product roadmapping, product requirement analysis, implementation followed by user acceptable simply doesn’t work in a fast paced industry. The key to success is to have an organizational experimentation mindset and have the infrastructure available to build and deploy low cost prototypes extremely cheaply.
  • Focus on outcome instead of output. Creating a product roadmap is an output, but the inconvenient truths about product roadmaps are 1) most ideas on the roadmap aren’t going to work anyway 2) the only way to find out definitively is through experimentations. Similarly, engineers should be focused on solving the business problems and not implementing features. Instead of creating a roadmap, define the problems that need to be solved instead. Similar to a roadmap, the problem set can be used to communicate and track commitments.
  • Product roadmaps should be discouraged, but it’s important to have a product vision and a product strategy. Starting with why and focusing on the problem and not the solution are two of the top principles in coming up with an effective product vision. A great product vision is needed to inspire the teams to want to help make this vision a reality, and it can also be used as a recruiting tool.
  • Having a durable product team is critical. The book uses the term “product team” to mean a team composed of cross functional members from product management, product design (UX), development, testing and operation.

The book has three great chapters that I have not tried to summarize above. One is on why organizations are not able to innovate. The other one is on why organizations lose their velocity. Lastly, there’s a chapter on the two different types of product cultures — one that is focused on innovation and one focused on execution.

Originally published at

I'm an engineering leader in a SAS company with more than 15 years of software industry experience.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store