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…