Back to my networking event - someone asked the question: "well if you are listening all the time to what these customers are asking for and prioritizing/implementing purely based on that feedback, then who is responsible for innovation in your product?!". Interesting question.
The question may seem simple. The answer is pretty simple too actually.
Answer: your Customer certainly aint responsible for your product innovation! They are responsible for telling you their pains. They are responsible for telling you "wouldn't it be great if it did x when I hit y". They are responsible for running their business, and innovation within THEIR business model. They are NOT responsible for YOUR innovation, YOU as a PM are.
For example - I'll hazard a guess here and say that Customers themselves were not responsible for cool inventions such as the iPod. All that users probably said to Apple (this is all pure conjecture for the attorneys out there - disclaimer/tm yada yada) is: "I want to have a device that makes it easy for me to listen to my tunes." Apple did the rest in terms of delivering a truly innovative product - and the rest is history - until someone innovates better than Apple of course :-). Don't expect innovation from your Customers, it is not their business to give that to you either. They have enough on their hands running their business and their lives, and is not fair to ask them to do your job and theirs. This holds true even if the "business" challenge for the night is the 16 year old who has to update her myspace profile before the major cheerleading event on the next day! :-)
Net it is your job as a PM to drive innovation. It is your job as a PM to optimize, streamline, and improve your Customer's existence through product innovation. Expect this from Customers and you will be sorely disappointed.
Taking a step back, if we look at the categories of product innovation, they come in two basic forms:
- Those where PMs translate customer requests and pains into greater things. As I mentioned before, customers will eagerly tell you their pains and "wouldn't it be great ifs". These are feature requests - sometimes they are camouflaged in bug reports. These are not REQUIREMENTS though. Requirements are the inputs you deliver to your Development team. And importantly, they should be groups of what appear to be related (or sometimes unrelated) feature requests synthesised into a single requirement. For example, Customer A may ask for this feature: "wouldn't it be great if I hit this button and it did X." Customer B may ask for this feature: "wouldn't it be great if I hit this link, it did Y and then did X". Different feature requests, but similar potential need - there could be an innovative requirement hidden in here that differs from what the two customers requested, but solves both their problems. Very important to understand this - feature requests are not requirements - requirements are derived from feature requests, and may not represent exactly what the Customer requested, but still addresses the problem they had, and maybe goes beyond that...
- Raw great ideas. These are those ideas that come up with little Customer input, but again are driven through some vision derived off an indirect market pain. These are often the greatest innovative features. Google's PageRank is an example. There weren't any Customers asking for this were there? Yet the founders of Google thought of a cool idea, thew something out there, and innovated and iterated rapidly. And the rest is history. You should not be afraid to pursue these. My only word of advice is keep it simple, keep it pure - get your concept out there quickly, start iterating, and let the market tell you if it is a money or poopoo idea sooner rather than later.
I have one final point on the topic - PM should not solely be responsible for product innovation within a company. Innovation can come in many forms - maybe you have a scenario where one of your engineers comes up with a way to dramatically enhance the architecture of your product in a way that opens your product up to new business (APIs etc) - that is an example of innovation, although everyone does it today (you get my point though). Engineers are often the most creative people in the company, and we don't leverage that creativity in many many cases (more on this in a separate post). The way to effectively harness a strong engineer's creativity, and direct that towards the product, is to do things like getting engineers on Customer visits with you. That way they see the PAIN themselves, they feel what the Customer is feeling - and innovation ideas they have will be so much more grounded. Net - PM should not be the bottleneck for product innovation - empower the rest of your organization through Customer familiarity and real-world experience to participate in the innovation game too. Do this, and you and your TEAM will do great things.
Comments, thoughts welcome.