When you launch a product out into the world, you’re going to get feedback. Lots of it, and it’ll be both positive and negative. There’s no doubt that feedback — whether good or bad — is valuable and will help you make sure you’re in line with what your customer needs.

But you also have to keep in mind that you should give users what they need, and not what they say.

When you let your customers’ whims control your roadmap, you can wind up with a Frankenstein-like creation that’s very far from your original vision—and, for that matter, from your customers’ vision.

The key to success on a customer-driven product team is getting through the maze of feedback and focusing on what will be best for the product. But how exactly do you do that? Let’s take a closer look at how to figure out where feedback’s coming from, how to build a product roadmap that supports feedback and how to roll out relevant updates.

Suss out who your customers are and what they do

The number one rule for building a customer centric product? Don’t follow customer feedback blindly.

Customers aren’t product experts—you are. So while it’s important to listen to what they have to say, figure out who you’re hearing from first and how they use your product.

You have two main types of active customers: power users and average customers. Power users use every aspect of your product regularly and are most likely to send feedback through channels like social media and emails. Average customers on the other hand, enjoy using your product but they’re less likely to proactively share their feedback.

Sort through the feedback you receive from each group by tracking how they use the product and set up focus groups to understand what they’re trying to accomplish. Rank the feedback using this data.

[Source] Example of repetitive feedback apps receive

Let’s say power users ask for an advanced feature like an enhanced data analysis toolkit. Moving forward with this project will require major time and effort to implement. Rather than just running with the idea, run the numbers first to see if it’s worth it. Ask yourself the following questions:

• How much is the customer worth? Figure out if you’re hearing from power users with huge MRR or average users with a free plan. Their feedback will be different.
• What’s the opportunity cost? If you follow through on this update, what’s the cost of not doing something else? Huge undertakings mean you can’t do something else or you have to delay another plan. Figure out if it’s worth it.
• How much will it cost to develop the new update? This isn’t just about money, consider the time it’ll take to work on a new project.

To test the uptake of this new feature, select a small group of beta testers — preferably power users — to see how they use the new feature. How are they using it? What are they saying about it? Use this information to decide whether you move forward with the project and who you make it available to. Perhaps it’s an add-on that power users have to pay to use.

Key takeaway: Don’t adjust your product solely based on what users say they want. Run the numbers and do the math. Set up experiments to test user uptake and usage. Remember, you know what’s best for your product so use this process to decide what feedback you incorporate.

Flexible product roadmaps are essential

You wouldn’t build a house without blueprints, would you? An app or SaaS product isn’t any different.

Product roadmaps are blueprints — they document each step of the process to get a product from A to Z. They’re essential to product development because they ensure that updates stay in line with the overall vision for the product.

[Source] Components of a product roadmap

It isn’t easy to say no to new ideas, especially when they seem like good ones. Rely on the strategy developed in your roadmap to help make decisions that fit. At Apple, their guiding principle for introducing new features is that they say no to “all but the crucial features.” They’re not adding new features to simply say they’re innovative or thought of it first, they only add features that are in line with their product vision.

As a product manager, if particular feature changes or enhancements aren’t in-line with your current product focus, don’t be afraid to say no.

On the flip side, say yes and update your roadmap if:

• The new feedback offers a solution that has long-term gains for the customer. If it’s still viable and important to them five or 10 years down the road, it’s worth saying yes to.
• There are requests coming from all types of users, not just one group.
• The feedback can be scale over time to boost user engagement and revenues.

When you say yes, the roadmap should be reviewed regularly — for example, quarterly — to make sure that changes are still in line with your long-term product vision and customer goals.

Key takeaway: Product roadmaps are guides but they aren’t meant to be fixed. When you map out the path your product will take there will be specific steps to take. However, it should leave room for to “respond to shifts in the competitive landscape” and incorporate some user feedback.

Stay organized with release sprints

Part of growing a strong product is knowing that it’s not perfect. There will always be something that can be improved or a new way to do something. For this reason, release sprints are essential. Regular releases help you get things done and let you incorporate user feedback quickly and methodically.

Whether they’re weekly or monthly, they give developers and engineers time to shore up and test all of the updates they’ve worked on before releasing them live at the same time. There are two approaches you can take:

• Use release sprints that focus on individual components of your product like onboarding or notifications.
• Use release sprints that incorporate all updates to your product.

The model you choose depends on your product. For example, frequent sprints based on individual components are a good idea for new products and PMs that are still learning from their users. This lets you roll out relevant updates quickly. Sprints that incorporate all product updates at the same time are a good idea for mature products that need a few minor tweaks.

[Source] Example of a monthly release sprint

Whichever approach you choose, organize incoming feedback and bucket them based on urgency and relevance. Create a scorecard to decide what to include in each release. For example, focus on “feature prioritization and high level estimation.” Meaning if your current focus is attracting new customers, figure out if current feedback helps with this. High level estimation helps you figure out if all the features you plan to launch will fit in a particular release sprint. Limit the number of updates in each sprint, decide based on how much time you know it takes to makes changes.

Key takeaway: The sprint model you choose depends on your product and where it is in its growth cycle. The point is to be flexible in order to meet customer needs. Release sprints don’t have to be rigid, make room for issues or bug reported by users. Fix the issue and release the change as soon as possible.

Customer centricity doesn’t mean following the whims of customers

Your customers are the best source of product information. They interact with it so they’re in the best position to tell you what’s working well and what needs to improve.

However, you have to take the time to analyze their feedback, or you’ll find yourself in an endless iteration cycle that takes you further away from your vision. Listen to your customers but forget that you’re the product owner. You developed your strategy, so you know better than anyone why your product works the way it does.

Above everything, stay true to your product vision.

 

This is a guest post from the team at Amplitude, a platform for product analytics. To read more on product management, check out the Amplitude blog.