Insights on product strategy and customer research for product managers

Today we are looking at product management work through the eyes of a CEO, exploring several topics together.

The CEO joining us is Matt Young, CEO of UserVoice, the first product feedback and research tool for software companies. UserVoice is the tool I see most frequently used for collecting customer feedback and prioritizing customer needs to help product managers create more valuable products. Matt started his professional career as a software developer, and throughout his career he has been pushing for better ways to build software products.

Summary of some concepts discussed for product managers
[3:41] As a CEO, what do you expect from your product VPs?

I need product VPs to develop a product strategy and measure its effectiveness. They must formulate a product strategy that will help deliver on the company’s overall strategy. They need to have a way to demonstrate whether their hypotheses are meeting the mark. If the product strategy is intended to drive an increased NPS, how are they going to tie their activity to that result?

[6:48] How do you communicate strategy to your organization?

We do it often in actionable ways. When we get together as an executive team to update our strategy every six months, we role play every department and title to make sure those people know how to support the strategy and be confident what they’re doing contributes.

We make sure the strategy is simple and understandable to everyone. On the executive team, it’s easy to throw around acronyms your industry uses, but someone who just came out of school with a design degree may not know all those things, and a brief explanation isn’t going to make them an expert.

Every two weeks, we do a company all-hands and make sure all our slides re-emphasize strategy and metrics we’re using to track it. We celebrate when an individual team meaningfully contributes to our goal. It not only re-emphasizes understanding of what the mission is but also gets people on board with how to achieve the end result.

CEOs sometimes falsely feel we bear the entire burden of the company, but it’s really all the people who work at the company who are accomplishing everything, and I want them to feel they’re the ones who did it.

There are a lot of people who view the product team as sitting in an ivory tower. They seem to be making decisions without a lot of information and are perceived as ignoring some of the feedback they’re getting and running around with their own agenda that isn’t well researched. The misalignment may come from a communications problems or a failure to see eye-to-eye on the difficulty of other people’s jobs. There are a lot of examples of misalignment between product teams and the rest of the organization.


[11:00] How do you improve communication about strategy with product teams?

Every time we propose a project for our product management team, we list a couple of bullets at the top explaining how this initiative will support the company’s strategy. Whoever’s leading the product team keeps re-emphasizing those points to the product team. People pay attention to their immediate managers. When all the conversations in the organization are oriented around the same goals and using the same language, it starts to stick. Strategy has to be ever-present in people’s day to day.

[12:36] As a CEO, how do you interact with the product functions in the organization?

It’s challenging for me and for most CEOs to hand off control and trust the people leading engineering and product. Every Monday the heads of each department produce a report I ask them to spend no more than 20 minutes on. If they’re spending a lot of time assembling that information, they might be too disconnected from the people doing the work. Producing a terse summary is a good opportunity for them to reflect on what they have a good handle on and what they should dig into more.

I sit in on some brainstorming discussions, and I try to be as much of a peer in the organization as possible. If you have good interconnectedness from team to team, I don’t need to be the one making connections. We dissuade people from communicating through their managers and going up and down the tree until the right people get connected. We’ve shifted to an all-remote workforce, and it’s much more efficient to go on Slack or Zoom with the person whom you need information from.

We have a brief product and marketing meeting and product and success meeting every week where everyone can talk about what they’re learning and the struggles they’re having. More than any report or oversight structure, these meetings create the self-healing network that creates the greatest value in our organization.

In product management, we talk about adding value to a customer, and that’s not precise enough for everyone. There are a lot of ways to add value to the customer. We need to be a little more specific about what value we’re going to add and what problem we’re going to solve.

Research is a huge area of focus for us. Product teams are known for doing research, but every salesperson and customer success person is doing research. We try to make sure all the research is shared freely among people because the way a customer speaks to a salesperson is much more honest than the way they speak to a product person who is presenting something they’re emotionally invested in.

[17:31] How are you bringing customer information back and aggregating it in way that is useful for everyone?

We user our own tool at UserVoice. It not only collects feedback from end users; more than 50% of the feedback UserVoice collects is from internal team members. If a sales rep hears a feature request from a customer, we grab that right away so the product team knows about it. At UserVoice, we sell to product managers, so our sales team needs to be more astute than a lot of people about product management. We bring our sales team along for the ride to learn about product management and how we ask questions. As a byproduct, our sales team is asking questions when a potential customer brings up a feature. That’s free customer research that lands on our plates.

It’s not uncommon for one of our account execs to be doing a demo or call and ask a product manager to join the call when they hear a feature request. We get immediate feedback about what the sales rep is hearing, and the sales rep gets to witness how we might ask for further information. The potential customer comes away feeling like the company listens to what their customers say. Engineers can pop on support calls to help with technical problems. It helps them understand the downstream implication of their work. Some of the strategic thinking in product should come from anyone in any role based on their customer experiences.

[22:15] How are product roadmaps constructed at UserVoice?

A roadmap is a terse summary of the current manifestation of the product strategy that will support our business goals. Every eight weeks we start with a blank sheet of paper. That doesn’t mean old ideas can’t be rehashed, but we want to truly embrace the goal of Agile, which is to do the thing that is most valuable at any given time. That means not anchoring yourself to what you think you should have done last time. It might still be the most valuable thing to do, but it’s surprising how often we don’t end up doing the thing we thought we were going to do next because the research doesn’t justify it as the most valuable thing for our customers and business goals.

We brainstorm ideas focused on problems not solutions. We involve the sales, success, and support teams as much as possible. The roadmap we produce is a list of things we decide to bet on from a list of things we researched.

This is an eight-week process running coincidentally with a development cycle. Eight weeks is a healthy amount of time to do some lightweight work on a lot of things and some deep work on a few things and come to the conclusion that everyone working on the product feels good about it. If we were wrong we learn from it and try to take that information to the next cycle.

[25:27] Do you execute in shorter sprints within your eight-week process?

We create pitches, not tasks. A pitch is a problem and a solution in a “fat marker sketch.” Imagine drawing your solution with a really big Sharpie—that’s the level of detail. You talk primarily about the outcomes and what the end user should be able to accomplish. You decide whether you’re willing to spend two weeks or six weeks on it. There are no four- or five-week options, because it’s easy for us to distinguish between a two-week piece of work and a six-week piece of work.

Within the eight weeks, there are six weeks of work and two weeks of cool down where the engineers get to learn new technology, fix bugs, and rearchitect things.

We don’t divide our engineering and product teams. They’re reporting in the same structure. Their task is to deliver on those pitches. I don’t care what order they’re in or if the teams are reshuffling themselves. They know what their goals are, and they figure out how to best organize themselves to get them done. Self-organizing teams are in a better environment to find a sustainable way to keep working.

Action Guide: Put the information Matt shared into action now. Click here to download the Action Guide.

Useful link:

• Learn more about UserVoice
  

Innovation Quote

“If a machine is expected to be infallible, it cannot also be intelligent.” – Alan Turing 

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.