Tag Archives: software

Product management by committee … how sustainable is it?

I recently talked to another early stage software company that is managing their product portfolio by committee. Oddly enough they too are using an agile development approach – I believe that the committee approach fits well into the notion of daily meetings, product backlogs on the whiteboard, etc. Regardless of the development methodology I wonder how sustainable this is. At what point does this method of managing products breaks down?

Early stage companies typically have a dozen employees or so. What I’ve seen so far is that the committee consists of a combination of the CEO, head of development, Chief Architect, and head of marketing. One or more members are usually the founders / visionaries. Now each have their own roles within the company and they devote a portion of their time (roughly 10%) on the product management activity. The committee primarily decides what goes into the product and when. All works well, but the challenge they face as the company grows is that the members of the committee become more consumed with their primary roles (as they should) and the product management activities fall by the wayside. The result is that a single person – usually the head of development or the chief architect – takes on the task of deciding what goes into the product. But as the development team grows, these product management decisions are made from an internal perspective and not from the outside in as they should be. I believe that as companies approach and move through the $1.5M to $3.0M annual revenue milestone and/or the 20-25 employee threshold, they will see the breakdown of the product management by committee methodology. Most notably, committee members find it a challenge to attend meetings and to focus on the details of what needs to go into the product.

Here are some of suggestions to help get through this phase … (1) hire a product manager with product management experience, (2) invest in building an infrastructure (processes, artifacts, etc.) that meets the needs of your development methodology, (3) document your core competency, market problems you solve and why you add value, and (4) setup regular status meetings with the stakeholders. The key is to setup your product management methodology to support the next stage of your companies growth.

Re-focus the feature debates!

How often as Product Managers do we get into a heated debate over whether Feature A (the cool, sexy one) or Feature B (the mega-reported annoyance) should be included in the next release? Far too often we are in the middle of these heated, opinionated discussions – resources are limited, time is limited so the debate rages on. Invariably the person with the strongest will or voice wins or the biggest, most important customer wins or both.

We always have to remember that product features are like a marriage … until death do us part! In other words, once the feature is in the product you have to support it forever – somebody will always use it; somebody will always want a new and improved version. And to make matters worse, it is an incredibly messy process to get rid of it. The only features that should make it into a release are those that positively impact the company’s objectives – increase revenue, extend marketshare, increase customer satisfaction are all good objectives.

The challenge we face is how to objectively evaluate the myriad of feature requests that come across our desks. The problem that I’ve seen far too often is that the discussion or debate is focused at the wrong place. Instead of debating whether the feature should be in or out, the debate should be around how well a feature meets the business and/or release objectives. Here are examples of a couple of objectives that I found to be very useful:

  • Improve Sales Wins – this objective speaks to the idea of winning more sales engagements. Some features absolutely shine during the sales engagement and others have no impact whatsoever. Features that shine are either very demonstrable or the sales team can speak to them with great impact. Another way to think of this is a resonation factor – features that resonate with the prospect. So the debate surrounding a feature is now, on  scale of 0, 1, 3, 5 how well does this feature meet this objective? 0 – not at all; 5 – home run!
  • Broad Market Applicability – this objective speaks to the broadness of the applicability this feature has with the target market. In other words, you want to add features that apply to as many of your target markets as possible – outliers are not necessarily a good thing. Again, on a scale of 0, 1, 3, 5 how many markets does this feature resonate with? 0 – none; 5 – all of them!

You can add more objectives like these two – I recommend no more that 5 – 7. You can have one or two that are product oriented in nature … word of warning – do not make them too granular, go with something that adds or improves a capability that is a key component for your target market. And lastly, you want to apply a weighted formula to calculate a total score. If your corporate objective is to win more new-named accounts, then weight the Improve Sales Wins higher – that way any features that really help meeting this objective will be ahead of other requests.

The result will be that your scarce resources (development, qa, documentation, etc.) will be focused on the features that help your company achieve its goals.