The motivation to write this post came from a great, raw, uncut interview with Steve Jobs, the then CEO of NeXT Computer, in 1990. Among many other insights, he recalls a thought that crossed his mind when he gave Sean Lennon a Macintosh as a birthday present, “Older people want to know how it does what it does but the young people just want to know what it can do”.
There comes a time in every product and industry’s history when serving the expert customer imprisons the product team into a cycle of ‘how’. The Product Managers respectfully ask folks ‘how’ something should work, implement things to comply with what they heard and then spend their days explaining ‘how’ things work in order to convince the expert to buy the new and improved product.
Of course, the inherent problem with this scenario is that in any sizable community, one will get a different answer to the ‘how’ question from every single expert user. So the final implementation and explanation of ‘how’ the product/feature works will be a compromise that satisfies noone completely and disappoints everyone slightly. The hope then is that one is able to manage the compromises effectively enough for the majority to still buy the product. In essence, one becomes a Compromise Manager instead of a Product Manager. A quick clarification at this point – obviously all complex projects require smart trade-offs to ensure maximum value is delivered with the time and resources at hand. The compromises that I write about here are about finding the least common denominator among many different implementation options, ending up with an insipid experience for all.
Now consider the scenario where the Product Manager reaches out to not only the current user but also the new user and the potential users and asks them what they would like to do and why (think outcomes and results not product features). In this scenario, there is freedom – freedom to implement the solution however one sees fit while making sure that the users can do what they want to do painlessly. Of course, the implementation in this case takes a lot of hard thinking as well as hard work because the Product Managers have to chart their own course. However, at the end of the day, they can then sell the product by talking about what all it can do and not ‘how’ it does it.
If these are the primary options, then why is it that Product Managers and product organizations choose the route of ‘how’ – why is it that so many wantonly imprison themselves in these user-generated courses of action that are guaranteed to produce unsavory compromises and ho-hum results?
You tell me…