The future of product management (2)

Yesterday I posted some of my own ideas on improving product management.  Today I thought I would share a few of the better articles I have read on the topic, and contrast them to my own ideas.

First up Kathy Sierra has a post on leveraging the community to to help build a more effective community around your products, its a good read and one of the topics she talks about is using the community to help with product design but she goes way beyond that.  I am a real fan of building community, I’ve done it several times and every time I find we get much more back from the community than the investment we make, but best of all it really is a win win, because the community gets much more back in total than they invest as well.  The thing I like most is that everything seems to get easier, rather than the sometimes difficult customer-supplier model it starts to feel much more like a real partnership and sometimes even like a team.

I have a few posts on the power of community, this one in particular

Next up the inspirational Ismael Ghalimi describes how he is using demand driven development, his approach is very simillar to the one I proposed, although he’s not using some of the market driven aspects that appealed to me.  He restricts his scope to custom features, which is a great place to start:

The main idea behind Demand Driven Development is to syndicate the development of custom features among a group of customers who need the same features and are willing to pay for it. Here is how it works: customers get access to a detailed product roadmap and can suggest the addition of new features to it. Upon review by the vendor, features that make sense get added to the roadmap, but no delivery dates are committed for them. Instead, customers can bid for the development of specific features, indicating how much they are willing to pay for which feature, assuming that the feature could be delivered within a certain timeframe. Multiple customers can bid for the same feature, and once enough bids have been collected to fund its development, the vendor develops the feature and delivers it to the group of sponsors, three to six months before anybody else gets it.

Ismail has recently provided an update to his original post which he titled How To Outsource Product Management and it seems to be going very well.  I liked this quote:

Product Management is one of the most critical functions for any enterprise software company. As a product gets used by more and more customers, requests for new features start to pile in, and the job of a Product Manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep. During Intalio’s early years as a company, we found it very difficult to manage this process. Too many resources where allocated to the development of features that very few customers actually needed, while features that could have made a significant difference on the market did not get developed, for lack of available resources. We only managed to solve this problem when we decided to outsource it, and selected an unlikely outsourcing partner for it: our customers.

In Ismails approach, simillar to mine he has a number of phases:

1. identification, where an initial list of options is proposed, added to, discussed and rated, then they moves on to
2. estimating, where a specification is drafted, effort estimated and a rough cost is developed, then they moves on to
3. out for subscription, where customers bid for the features they want, at least two customers are required for features that seem very customer specific.  Once customers have bid enough money the feature moves on to
4. project, and development starts – once its finished, they either give it to the customers who paid for it 3 to 6 months before anybody else gets it, thereby creating an incentive for customers to contribute to its funding. Or incorporate it into the Enterprise Edition of the product, thereby increasing the value of a subscription. Or donate it back to the open-source community, thereby getting help from the community for its downstream maintenance. In most cases, they do all of the above, in a staged manner, killing three birds with one stone

it’s a really great process and if I ever get a second chance within my company there are some ideas I would like to incorporate.

Finally Kathy provides an alternative approach to the process of defining a set of product features, that can be applied to all sorts of decision making needs where there are many options to choose from and perhaps refine.  It’s a fairly long process, but essentially it has the following charachteristics:

1. The whole process is subject to a time contraint to explot constrain-fueled creativity
2. It involves getting teams to repeatedly pitch other peoples ideas, with the best options being selected.  The clever part of this approach is that because the ideas being pitched are not yours it avoids attachment to your own idea
3. It leverages the wisdom of crowds (diversity-driven inspiration) by having a wide range of independent people involved in the selection process
4. It uses a lot of external inputs to spark inspiration, books magazines etc

I particularly like the idea of repeatedly pitching other peoples ideas and iteratively down selecting them until you get to the subset that you want to take forward.  I think it could be creatively applied to be a much better approach than pitching up a management hierarchy.