Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. This is the first post in a two+ part series. I have content in mind beyond the first two parts, but want to gauge interest before deciding whether or not to continue. These first two parts are sections of a paper I wrote in a class called, “Creating and Sharing Knowledge” at Northwestern University. As a result, it’s a little more formal than my previous posts and includes citations to referenced material. I do think the material is very relevant to the world of product management and if you agree, I’ll continue to experiment with similar posts.
In order for a company to launch a successful product, it must build a product that customers actually want. It has to fill a specific need, work within the context in which the customer has the need, and work in such a way that the customer can understand it. This requires that the company have knowledge of all of these factors before they decide what to build. How does this happen?
Hislop defines innovation as “the deliberate modification, or transformation, by an organization of its products / services, processes or structures” (2009, pg. 114). He argues that innovation is primarily a knowledge creation process, but also includes the ability to search for external knowledge, the ability to apply existing knowledge to new contexts and the ability to combine knowledge in new ways. In the product discovery process, product teams may engage in any or all of these activities.
Customers rarely know what they want. They aren’t product experts. They don’t know the market. They may not even be clear on the specifics about the problem they are experiencing. A product team does two things during the product discovery phase. First, it clearly defines a problem that the customer is experiencing. Second, it identifies a suitable solution to that problem. In order for a product team to accomplish this, they must cultivate strong relationships with their customers. Cross, Parker, Prusak, Borgatti (2001) discuss four attributes of an effective relationship for sharing knowledge: knowing what another person knows, being able to gain timely access to them, willingness of the person to engage in joint problem solving and the degree of safety in the relationship.
Product teams must be aware that while customers do have some explicit knowledge about their problem and potential solutions, they just as often may be limited in their ability to define the problem, and quite often lack the product expertise to explore possible solutions. Product teams must combine customer knowledge with knowledge acquired through observation of the customer experiencing the problem. The team must combine these two sources of knowledge with broader market knowledge before exploring solutions. If the team doesn’t have access to customers, or the customers aren’t willing to engage with the team in problem solving, or either the team or the customer doesn’t feel safe sharing what they know or don’t know, this process will be hindered.
Similarly, Newell, David and Chand (2007) outline three different levels of trust: commitment trust, competence trust and companion trust. Commitment trust is trust that both parties will follow through on an agreed upon contract. Competence trust is trust in a person’s ability to complete a necessary task. Companion trust is the trust that develops over time as the result of a personal friendship. If a customer does not have competence trust in a vendor, they won’t be willing to spend the time required with the product team to help in the product discovery process. Similarly, the product team has to trust that the customer will honor their commitment to devote the time to this process. In situations where the product team has companion trust with a customer and both parties approach the product discovery phase as a partnership, the process works best.
In the next post, we’ll look at the flow of knowledge from product managers to engineers. Stay tuned. Was this helpful? Too formal? Please let me know what you think in the comments.
References
- Cross, Parker, Prusak, Borgatti (2001) “Knowing what we know: Supporting Knowledge Creation and Sharing in Social Networks,” Organizational Dynamics, Vol. 30 No. 2 pp 100-120
- Hislop, D. (2009). Knowledge Management in Organizations. New York: Oxford University Press
- Newell, David, Chand, (2007) “An Analysis of Trust Among Globally Distributed Work Teams in an Organizational Setting,” Knowledge and Process Management, Vol. 14, No. 3, pp 158-168
Great post, Teresa. In my humble opinion, the successful innovation or new product introduction strategy will vary based on the industry and current product landscape. What might work for a new product in the consumer electronics space is likely quite different than what would be required for selling a replacement product to tier I automotive suppliers for instance. In the latter case, the mantra that “customers rarely know what they want” can be a pitfall. Switching costs, supplier relationships and other constraints must be considered by the product development group. This is where the trust levels become key, especially competence and companion trust.
Hi Nick,
Great point! My perspective is heavily influenced by my experience in the internet industry. And I do agree that most things will vary significantly by type of product, customer, and industry.
Thanks for taking the time to write!
Cheers,
Teresa
Thank you for that insightful description of a complex process. I had not previously thought about the importance of the trust relationships between product managers and customers. I think it speaks volumes about why many product teams cannot successfully launch new products. I am a big fan of the idea of being open and honest with customers.
Bob, I agree. The same is true beween product managers and engineers. I’ll be covering that in the next post.
I have been in the Diagnostics industry for a long time. Bringing Product managers closer to the customer is always a great opportunity. Since most project lasts a while periodic re-check is also a good idea. Also, I have found that customers have “needs” and “wants” and “wow factors”. The project manager should separate that and make sure the needs are first met and add then spice it up with “Wow factor(s)”. This helped me to grow our business. Some of our products were IT products in a diagnostics industry. Hope this helps the discussion.
I agree. Re-check-ins are critical. And I love your needs, wants, and “wow-factors” categories.
Teresa,
I found your post informative as I am a project manager embarking on a new realm of product management with the duties I am undertaking. I have been receiving conflicting information regarding customers and their needs.
Your posts speaks to theories I’ve heard; “The customer rarely knows what they want… or how to articulate what they want…or unaware of solution options available to them”.
However, recent Sandler training states: “Don’t paint seagulls in your prospect/customer’s picture”. (Sandler Rules: 49 timeless selling principles and how to apply them(2009)). Basically, this rule means let your customer tell you their problem and what they want for a solution and if you add anything to their solution you may offend them/turn them away/cause issues. I know this reference was meant for prospective customers but it seems my company has taken it to mean even with current customers if you inform them your product can do more than what they are asking you are causing issues.
To me this flies in the face of “the customer rarely knows what they want”, I’m trying to figure the balance between the two… your thoughts?
Hi Ken,
Thanks for your thoughtful comment. Unfortunately, I’m not familiar with Sandler, but I do have some sales experience. However, I do think that the sales context is not exactly the same as the product discovery process.
A customer is an expert on the problems they are experiencing and they may or may not have an idea of a potential solution. In the product discovery phase, I’d argue that it’s the product manager’s job to generate better solutions than a customer ever could. I think this is how innovative products are created.
In the sales process, the scenario is different. Often times the customer is asking for a specific solution and the sales person is better off showing how their product fits that solution. The last things a sales person should do is argue with a customer about how the customer wants to solve their own problem. But if the product manager did their job in the discovery phase, the product should solve the customer’s problem and this scenario shouldn’t occur.
In practice, however, the sales team and the product team are not always aligned and this happens quite often.
Teresa
Interesting series of posts. I have long pushed back on the “just go ask the customer what they want” mentality by saying that the customer can only speak in the language of what was possible in the past, they can’t speak in the language of what is possible in the future. In my experience, great flashes of innovation occur when a visceral understanding of a customer’s problems comes in contact with what is technologically possible – to me that’s the role of a product manager.
Hi Gary,
I agree. People can rarely tell you what to build. But they can tell you abou the problems they are experiencing and the context in which they are experiencing those problems – both are critical for uncovering what to build.
You might like this post about what to talk to your customers about.
Thanks for reading and taking the time to comment!
Teresa