For the past few months at Powered, we’ve been driving an initiative to create a more collaborative and transparent product strategy process. In other words, the goal is to involve all business groups in sourcing product enhancement ideas and to make sure that key stakeholders across the company are both involved in mapping out a release and informed on why product strategy decisions were otherwise made. So far, this methodology is working out great for the company because it makes everyone feel like they have a voice in product strategy and in turn creates more passion for the product across the company.

During this time, I had the good fortune to pick up a great book called “Inspired” by Marty Cagan. This is an outstanding book for any software product manager and I highly recommend it. The content is excellent and the format makes it very easy to consume. In the context of a collaborative and transparent product strategy process, there were several chapters that provided great advice. Here are some highlights:

  • The Product Council (Ch. 14) - It all starts with the Product Council which is a hand selected group of key cross-functional company stakeholders that represent the collective interests of all business groups across the company (e.g., VP/Director Product, VP/Director Marketing, VP/Director Engineering, VP/Director Site Ops, etc.). This is the group that will participate in collaborative product strategy through frequent meetings (e.g., every few weeks) and work to cover things like proposed product strategy, roadmaps, opportunity assessments, product prototypes, launch plans, etc. Stacey Weber of Pragmatic Marketing also recently authored a great piece on how to assemble this Product Council team and conduct the meetings.
  • Assessing Product Opportunities (Ch. 11) - Great chapter on the criteria by which new product feature/enhancement opportunities should be assessed. When you’re involving a cross-functional team in product strategy decisions, each business group representative may have a tendency to prioritize requests based on their day-to-day activities and not necessarily on what’s best for the company. It’s key to give direction on what constitutes “high-priority”. Criteria includes; problem addressed, who’s the target customer, how big is the market, competitive alternatives, product fit and market window.
  • Product Principles (Ch. 13) - It’s key to define a high-level list of product principles that will guide product strategy. These can be tied to high-level business goals across the company or they can be high-level product principles. Either way, these are the principles that will ensure that product strategy decisions are being made with respect to driving the higher level strategy goals of the product and/or company. This chapter also has a great “aside” on resolving conflicts that will inevitably come up when making product strategy decisions. The key – keep all decision making transparent.
  • Reinventing the Product Spec (Ch. 18) - In this chapter, the author stresses his view that high fidelity prototypes are much more valuable than verbose Product Requirement Docs (PRDs) to developers and all parties. He argues that prototypes (whether they be quick and dirty “coded” prototypes or interactive design mock-ups like clickable PDF decks) capture more information about the vision and requirements of the software than a textual PRD ever could. I tend to agree. The reason why I think this applies to a collaborative product strategy process is that these high-fidelity prototypes can also be used at Product Council meetings and other key stakeholder meetings to verify initial functional requirements and they facilitate quick iteration on changes because the prototype embodies user interaction and experience that usually doesn’t show through via PRDs until the finished product.

This is a work in progress for us so I’d welcome any other constructive tips on collaborative product strategy processes. P.S. – You can also access Marty Cagan’s blog at www.svpg.com.

Advertisement