Abstraction

At the beginning of my career, I visualized product management as a set of serial tasks. I was to conduct market research, write requirements, submit the requirements to engineering, build collateral, define pricing, train, promote, then start all over with the occasional pause for a huge promotion and fat raise.

These activities, designed to lead to product success and eventual early retirement, did not at all correlate to my actual experience. Product managers live a very non-serial life. Every activity is urgently needed at once, and there’s never enough time to do any particular activity as well as I would like. This was irritating.

If I had a better grip on best practices, I thought, or had a deeper understanding of technology, things would get less messy. I was partly right. I did need a better understanding of best practices, and my efforts to understand various technologies have paid dividends (if not royalties, as in the case of a book I wrote about the mobile internet). Sadly, the messiness continued.

In the fullness of time, however, I came to accept two fundamental truths: First, making software is hard, and you just can’t fit the process into a neat series of boxes — activities will bleed together. Second (really a corollary to the first), trying to achieve perfection in any one stage of a process will cause neglect of other stages, and is thus an enemy of success.

This means that a good strategy lies in ensuring product management activities complement one another instead of competing for time and bandwidth, and that each activity gets enough attention to achieve success.

The best single way to do achieve these goals is to have an open information policy. I ask my team to post everything (work related) they do in a wiki created for just for the product team, and I encourage everyone in the company to do the same. Product requirements are written using an online tool that everyone can access; the entire requirements-writing process is available for all to see (and comment on) in its painful glory.

In this way, my team has the benefit of everyone’s thoughts and input throughout the entire process. The engineering team is better prepared for product requirements, and can get a jump start on design and feedback. The sales team can see product direction and can provide suggestions related to their geography or to a customer. Since everything is online and updated in real time, material is immediately available to anyone who deems it “good enough” for their purpose.