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
Latest Articles
Comments on all Articles
