In this second post, let’s start with some facts and figures. Research in Belgium by Insites (and taken over in the Conversation Manager) shows the following:

These data show thus an extreme willingness of consumers to be part in the design of products and services, mostly by giving feedback, but as well being actively assisting in the product development process.

The question that rises thus (and that someone asked me after my previous post) is: “Has there really been a change in the role of the Product Manager?”. My answer to that is twofold… No, the role of the product manager hasn’t fundamentally changed. However, the day to day activities, span of control and complexity have significantly increased.

I’m a fan of metaphors and have heard already a couple for a product manager. They are all metaphors of the fact that the Product Manager has many interfaces and many tasks, which make its role quite complex.

Metaphor	‘Old’ Product Manager	Crowd Product Manager
Octopus (legs = tasks/ interfaces)
Orchestra Conductor (number of music players = complexity)	Quartet	Full Symphonic Orchestra

Now, let’s dive into the 2 elements of the study. In order to keep each post short and sweet, I have split this one in two. Soon the follow-up will be published.

1. Willingness to give feedback on new products:

I’ve redrawn the image of my previous post somewhat to make it more clear on which stages feedbackfrom the Crowd (and its Conversations) can happen in the product development cycle . We are talking about the yellowish arrows here.

  Most likely, conversations will be about use cases. Just listen around and you will hear people talk about what are great use cases for a product or what are use cases they would want but didn’t find in a product. The following example demonstrates this. I’ve heard numerous owners of an iPod shuffle say that they were extremely happy using it while running, but that they hated it that you couldn’t look up a specific song. This statement contains 2 use cases:

• Listening to music while practicing sport
• Listening to music as an activity on its own, where you want to listen to specific music you like

Don’t mix-up use cases with features. In my example, I was never talking about the lack of a screen –which is a feature- but rather the use case –looking for a specific song. The use case could for example be realized by some text-to-speech functionality (you say the song title and the iPod plays it). Focusing on use cases gives you more options in the design process than if you would immediately focus on features. Remark: I bet that the  reasoning at Apples was: the iPod shuffle is for having background music while practicing sports only, there are other types in the iPod family for music listening as an activity on it’s own.

How can you put this in practice? Well, it’s getting your hands dirty. You’ll have to look on Twitter, Facebook, (support) forums, Youtube, (competitor) wiki’s and just listen around you to find this out.

This is what I meant above: in essence, looking at use cases was already part of the job, but you will have to become this octopus with more arms: you’ll have more feedback channels to take care of. To some degree this will naturally slip into your day to day job, but to a vast degree, you’ll need to reach out and look for them yourself (same job, more complex).

 On the idea side, it is a very similar story.

Idea management is a ‘process’ in two stages: first of all, it’s having e.g. brainstorm sessions to get as many ideas as possible.

Then these ideas need to be screened and prioritized. It’s often called the ‘idea funnel’ process.

With the extra input coming from the social media sources, all of a sudden, you will see the opening at the top of your funnel significantly increase. That is, if you are open for it. In order to capture this extra feed of ideas, you will need to put your ears and eyes out into the Conversations on the street and on social media platforms in order to capture as many ideas as possible. To use the metaphor again: this will add some more legs to the octopus.

 When you have decided what are your use cases and which are the key ideas you want to develop, you’ll need to develop your requirements. And if you have already lived some product development, it will sound familiar that immediately ‘prioritization’ pops up. Budget, time or resource constraints will often push you to prioritize features. But you have some guidance in doing this.

• First of all, there are the use cases you want to fulfill. Like a company has its mission statement as its holy grail, the use cases (or primary use case), should be your products holy grail.
• A second weapon you have is organized market research. You can e.g. conduct focus groups, do a survey around your product or invite a panel (e.g. taste of food products). This will help you determine what’s hot and what’s not.
• The last one is the social media dimension. You can also use your social media sources to help you prioritize features. Instead of the classical market research, you can for instance use your Facebook Fan Page to launch a poll on certain features or you can ask the most active members on your (support) forum in a direct message what they see as the best of a couple of features.

This is a very important step, so in this phase it is very important to take the opinion of the Crowd into account. After all, a great product is in essence a set of features that fulfills a need (a use case) of a customer. The legs of octopus here are that you will need to find the best information sources for your specific case in order to develop the correct features for your product. This topic deserves more attention and I’ll come back on it in a next post on Value and Simplicity.

— To be continued in the next post—