Should your products be designed by your customers, or inspired by your customers?
Getting Inspired
We talk about designing products for customers, getting feedback from customers, focusing on problems, and the differences between requirements and design. I’ll wager that every product manager has thought about these things.
J.D. Meier wrote a good article about the best practices of being a product manager, including a tip to get customers (or their proxies) directly connected to developers. After enjoying the article, I was reading through the comments. And I got to #11, from “Bob.” In his comment, Bob said [bold is mine]:
“…Building a product that customers will want to buy means transforming those needs into product specifications. You don’t want a product designed by your customers, you want a product inspired by your customers. That means thinking about wants and needs in a different way….”
Thanks Bob.
There are some ideas, or phrasings of ideas that just stick with you. Maybe I’m receptive because I just read the wikipedia article on koans. Whatever the reason, when I read Bob’s sentence, I walk away with several concepts at different levels.
Requirements
At the end of the day, as a product manager, you don’t (or at least shouldn’t) write down, prioritize, and implement a list of features. That’s just execution against a solution designed by your customer.
A therapist does not interview a patient and then simply prescribe that they “stop doing that.” A therapist will interview the patient, and elicit information – with the goal of understanding the problems that need to be addressed. A product manager (or business analyst) should do the same thing. The product manager should identify the requirements of the customers.
Understanding these requirements is a necessary (but not sufficient) component of developing products inspired by you customers.
Design
Depending on which debate you’re having on a given day, design can mean “choosing to address the customer’s needs with software” or “deciding that you must invoice the customer before shipping their order” or “making sure that the customer gets feedback in the UI automatically without additional action.”
Regardless, a user’s goals (not the buyer’s goals) are a key driver of developing great products. By developing personas and incorporating an understanding of their personal goals into products, you are given an opportunity to be inspired by your customers. A focus group is more likely to tell you how to solve their problems than they are to express the importance of their problems. Unless you’re lucky enough to have a focus group populated with other product managers.
I think the requirements versus design debate is, when thinking about inspiration, (a) murkier than ever, and (b) less relevant than before. If I’m struggling with a particular team on a particular project, where an improvement in role definition and responsibility assignment is needed, I will help the people make an explicit distinction. When the murkiness is not hurting people, I’m happy to leave it murky.
What is important is that the stakeholder’s goals (including customer needs and internal stakeholder goals) be communicated effectively to the team developing the solution.
Understanding the distinction between problems and problem manifestations (or solutions) is a necessary, but insufficient component of developing products that are inspired by your customers.
Ponder the Koan
The cool thing about a Koan is that the statement (or question) is intended to cause you to think, and to help you reach enlightenment. I’m not wrapping up this article with a ‘conclusion’ section, but a ‘go ponder some more’ section. I know that I will be thinking about this when I have my next conversation, draw my next diagram, and write my next requirement.
You don’t want a product designed by your customers, you want a product inspired by your customers.
–Bob
Thanks
Scott, I love the quote by Bob, it’s spot-on. Product managers have the opportunity to hear ideas from many customers and obligation to make sense out of them, and ultimately come up with inspiring products.
You’ve definitely given us something to ponder on, thanks. -Michael
Thanks, MRH, and have a great holiday season!
Good post Scott. Unfortunately, this is all too common in my experience.
Many execs (such as at my last company!) read a book or HBR article that says “Your customers should design your product”. Then they take it too literally and have all the customers directly talk to developers.
What ends up is a “Frankenstein” product — i.e. it stitches together what 30 different customers wanted, and looks horrendous! :)
This is where I believe PMs can add lots of value, by combining the different feedback, identifying common themes and “inspirations”.
– Raj
Accompa – Affordable Product Management Tool for Managing Requirements
Since I actually work through the whole technology adoption lifecycle, there is a phase where I build exactly what the client asks for. Notice, I said client, not customer. I do this, because I do not know what the customer’s in that client’s vertical are going to want. I pay attention to the functional cultures in these engagements, because they are directly accesssible here. This is the place for ethnographic research.
Once I launch into the vertical, I’m left to wonder how long my commitment will be to that vertical, and how committed I want to be. I need to exit with customers, but I don’t have the resources to do a lot. I have other clients, other verticals, and a technology roadmap that must be executed beyond the productizations. And, I have to put the marketure in place for the move to the horizontal market a few or fewer years down the road. This might take a decade or not. But, yes, I still have to listen to the customer.
If I decide to be the market leader in a vertical, and that turns out to be the case, I can, but don’t have to listen to the customer. I might be nice and listen anyway, but no, I don’t have to.
Since I do want to be the market leader in the horizontal, I face the same situation, but facing the late market with the mass customization strategy, I’ll be listening, but in a way that moves me away from average functionality and back to a culture focus. I also have to face moving my customers to SaaS. These things don’t happen because the customer asks for them. In some sense, my company and my category become the customer.
In the late market, we are SaaS. We have to listen to the customer, but this customer is different from those we served in the early market. I’m not going into the info applicance or embedded markets, so all that’s left to do is listen to the customer, and keep up with our external functionality providers.
I do have to move from tasks to work, and from work to management. This one is tricky, because managers peform tasks, and do work. Management here addresses the meta-management issues pointed out in the “Hype Cycle.” These issues foster long-term adoption by pragmatists and are really category issues that reach beyond the lifecycle of any one product in the category. Here the customer is really the economic buyer, rather than the user.
There is litte linearity behind the notion of listening to the customer. Which ones, when, and for how long have to drive the listening. Combining feedback will result in average functionality. It might be necessary, but at some point the functionality will have to be deaveraged, so the functionality is tuned to smaller partitions of the using and stakeholding communities.
@David – When you said “If I decide to be the market leader in a vertical, and that turns out to be the case, I can, but don’t have to listen to the customer. I might be nice and listen anyway, but no, I don’t have to.”
Did you mean that listening to your customer does not provide value? I believe that listening to your customers, gaining insights about what would make your product more valuable to them, and incorporating that into your strategy improves your ability to compete (relative to not doing those things). Your ability to compete impacts the profit you can make, either by improving your share or your pricing.
I agree that treating your market segments as a homogeneous market is the wrong way to go when those segments have unique problems.
Research has shown that market leaders will remain market leaders regardless of whether they listen to their customers. The market leader becomes a standard demanded by the market. The customers fulfill the markets demands, even when we think that they create that demand.
The market leader for a category is not in the same competitive situation as the other vendors in that category.
One problem is that market leadership is usually a marketing claim that has no real basis. If their marcom says “A market leader,” then they are not “The market leader.”
All of that said, a market leader will still have to listen to customers do detect critical situations like when that customer is over served.
I wouldn’t build the application without a client at the core of the product visualization. I wouldn’t become the market leader without listening to my bowling ally vertical markets. So yes, you will have to listen. But, it is not as linear and continuous as it seems.
On top of that, if you do not become “The market leader,” you certainly do have to listen to the customer. There is no certainty to becoming the market leader. Market leadership just gives you some slack.
If you go directly to the SaaS market, you will never be “The market leader,” so you will always have to listen to your customers.