Getting the Team Involved
Product Managers need to spend time with customers. On-site, where they can be observed. Alone and in groups, so that they can talk in confidence and have free-ranging discussions with each other. There's no better way to discover the customer's problems and identify product opportunities.
Typically, a PM will visit customers and summarize the findings in a report or presentation. These findings generally find their way into a Market Requirements Document, and may even be read by the development team or executives. Or not. Isn't there a more effective way to share this information?
How about taking team members along on customer visits? Sure, everyone's busy, and visiting customers isn't their primary job, but you may find that it's worth the effort.
I've found that bringing including team members accomplishes two very important things:
First, it gives them a firsthand, visceral understanding of customer problems. Listening to a customer describe the pain of a problem is infinitely more memorable than reading a report about it. This matters. When it comes to creating a product, there's no substitute for caring about the customer…a team that remembers the customer's pain is motivated to help ease it.
Second, meeting customers helps build a common language within a team. I know, this is what personas are for. But a flesh-and-blood customer is more meaningful than a really well-written persona - when team members can talk about their firsthand experiences, it's no longer an abstract exercise.
One other benefit - going on customer visits help your colleagues understand what a PM does, and why it's important. Whether it's engineering staff or senior management, you'll find that there's a new level of respect for what you do, and a new eagerness to hear about your subsequent customer research.
There's one very real hazard to watch out for, though: If a team member visits a single customer, that visit will take on an exaggerated importance. This can be a problem if the customer turns out to be a non-target customer or is atypical in some important way. The team member may bring back a message that's irrelevant or distracting. The best way to avoid this is to line up three or four visits with different customers for each team member - admittedly more difficult, but this pretty much ensures a balanced view.
Either way, it is essential that you discuss each customer visit with each participating team member immediately afterward. Don't let your team members disperse after a visit - schedule a sit-down discussion after every visit. (It helps to have lunch money in your research budget!) This debrief should cover items such as "what was learned?", "what are the customer's pain points?", "how is this customer typical or unusual?" and "is this person likely to buy our product?" If the customer may not fit the target, it's essential to make sure that everyone understands this right away.
The discussion that follows a good customer visit can be as valuable as the visit itself, not just for team members, but for the Product Manager. It's a great way to hear other interpretations of the meeting, and note any points that you may have missed. In most cases, you'll end up with a consensus that will find its way into feature discussions months later, making it much easier to agree on the functionality and prioritization of product features.
And hey, why should PMs get to have all the fun?
Typically, a PM will visit customers and summarize the findings in a report or presentation. These findings generally find their way into a Market Requirements Document, and may even be read by the development team or executives. Or not. Isn't there a more effective way to share this information?
How about taking team members along on customer visits? Sure, everyone's busy, and visiting customers isn't their primary job, but you may find that it's worth the effort.
I've found that bringing including team members accomplishes two very important things:
First, it gives them a firsthand, visceral understanding of customer problems. Listening to a customer describe the pain of a problem is infinitely more memorable than reading a report about it. This matters. When it comes to creating a product, there's no substitute for caring about the customer…a team that remembers the customer's pain is motivated to help ease it.
Second, meeting customers helps build a common language within a team. I know, this is what personas are for. But a flesh-and-blood customer is more meaningful than a really well-written persona - when team members can talk about their firsthand experiences, it's no longer an abstract exercise.
One other benefit - going on customer visits help your colleagues understand what a PM does, and why it's important. Whether it's engineering staff or senior management, you'll find that there's a new level of respect for what you do, and a new eagerness to hear about your subsequent customer research.
There's one very real hazard to watch out for, though: If a team member visits a single customer, that visit will take on an exaggerated importance. This can be a problem if the customer turns out to be a non-target customer or is atypical in some important way. The team member may bring back a message that's irrelevant or distracting. The best way to avoid this is to line up three or four visits with different customers for each team member - admittedly more difficult, but this pretty much ensures a balanced view.
Either way, it is essential that you discuss each customer visit with each participating team member immediately afterward. Don't let your team members disperse after a visit - schedule a sit-down discussion after every visit. (It helps to have lunch money in your research budget!) This debrief should cover items such as "what was learned?", "what are the customer's pain points?", "how is this customer typical or unusual?" and "is this person likely to buy our product?" If the customer may not fit the target, it's essential to make sure that everyone understands this right away.
The discussion that follows a good customer visit can be as valuable as the visit itself, not just for team members, but for the Product Manager. It's a great way to hear other interpretations of the meeting, and note any points that you may have missed. In most cases, you'll end up with a consensus that will find its way into feature discussions months later, making it much easier to agree on the functionality and prioritization of product features.
And hey, why should PMs get to have all the fun?