← Visit Appcues.com
×
×

Data-driven product management: How to use data to create great products in 2021

Learn how to hypothesize about the next great feature, collect data to support its inclusion, and continue to monitor progress.
Skip to section:

Skip to section:

Great product management is about more than reviewing feature requests. Sure, there’s a never-ending list from your current customers of their must-haves and nice-to-haves. But by the time feature requests make their way to you, your customers already wish those features were part of your product.

Truly great product management is about anticipating customer needs before they make their requests. You understand your product and its use cases so well that you can predict its evolution.

When thinking about “What comes next?” you need to rely on data from less-obvious sources. Data-driven product management, specifically, has become a reliable way to inform product decisions.

Think of this style of product management as a scientific experiment. You begin with a hypothesis and collect research and data to prove—or disprove—your theory. That data will help you form a conclusion and make a decision about your product roadmap.

Start with your hypothesis about the next product feature

Feature ideas rarely come from explicit requests.

You may be aware of customer pain points or hear feedback from your sales team about product shortcomings or competitor offerings.

Product usage insights might also clue you in. You might observe that customers reach a certain point in onboarding and then stop. You need to identify which feature will fill that gap.

Feature ideas may also come from observing market conditions—COVID-19 being a prime example. Or if you’re in a heavily regulated industry, you may note that your product needs to change based on new requirements.

From your observations, you form a theory about which product feature to develop and what its result will be. Ask yourself:

  • Does this feature help draw in new customers?
  • Will this feature better retain existing customers?
  • Does this feature present an upsell or cross-sell opportunity?
  • Does this match the overall product positioning?

Based on the responses to these questions, you are forming a hypothesis: “The next product feature should be __________  because __________.” Your next step will be collecting the data to back up that statement.

Collect customer feedback about your idea

As you begin to imagine your new product feature, you’ll want to make sure it’s a worthy investment before sinking time into it. Data-driven product management involves figuring this out, and your primary data source is going to be your customers.

Your customer support interactions should reflect the pain point you're trying to solve. Review tickets related to the issue your new feature addresses to see whether the solution fixes most of the problems customers mention.  Remember, customers don’t always know how you can solve a problem within a product, so you may not find explicit requests that match your feature idea.

Interview customers who have pain points relating to your feature idea. Set up a time where you can describe the feature to them, and ask whether they would find it useful or not. This customer feedback is critical for making sure your proposed solution addresses the problem.

Your power users—those who are quick to adopt features—are an especially helpful source. Talking with these customers can not only validate your thinking, but also give you some feedback on the feature’s practical application and “real-world” value.

You can also collect feedback from customers through in-app surveys. You might ask, “If we added x functionality, would you find this beneficial?” Surveys are less time-intensive to complete than interviews, so they’re ideal for quickly collecting a large amount of feedback.

You are not merely looking to confirm your hypothesis by collecting this feedback. At this stage, you might discover that your proposed idea is not a good solution. Your customer feedback or survey responses might send you back to the drawing board. And that’s OK! It’s better to discover this early in the process than when you are halfway through development.

Form a conclusion based on your expertise

Your final step in moving forward with a product feature is to collect internal data that helps you determine how much time and resources developing this feature will require.

Projects often go awry when there isn’t enough information to fully understand their resource requirements. Luckily, you’ve already collected much of this data in the steps mentioned above. Create a detailed outline of the project’s scope based on:

  • Customer feedback to determine what functional requirements your feature needs to meet user expectations
  • Product usage data to determine where the feature will fit into your user flows
  • External factors to make sure your product is needed in the current market and compliant

You need to then collaborate internally with developers on the feature’s feasibility. Based on reviewing the scope you’ve set, your development team should be able to identify the amount of time and resources involved. Does this feature bring enough value-add to customers to justify the investment? What is the associated cost of not adding the new feature, either in churned customers or fewer new customers?

By combining your data sources (customer feedback, surveys, tickets, market trends, and more) with developer input about feasibility, you’re set to turn this feature into a reality.

Confirm your decisions with beta testing data

Collecting data doesn’t end with the decision to move forward with developing a new product feature. You should continue to monitor feature adoption through the beta stage and through your product launch.

Repeat the collecting customer feedback step with your beta users. In-app surveys and interviews can confirm that your new feature is on the right track, or if it needs additional work. You can also track events to see how your beta customers are responding to your new product feature.

If the beta test goes well, and you fully release the feature, use the initial data sources you relied on to form your hypothesis—customer input, sales team feedback and product usage data— to measure and improve overall feature adoption.

Data-driven product management is a continuous cycle


Creating the next great product feature is about relying on the information that you have available. Data-driven product management involves identifying what data you can gather and knowing how to apply it.

There is no crystal ball regarding feature adoption, even with decisions driven by data. If you find adoption is low, it can be a lesson in how to better collect data for the next product decision. You may need more feedback, different survey questions, or a more well-defined scope. You can always seek out more data from your sources to minimize your product development risk and keep your customers at the forefront.

Author's picture
Eric Keating
VP, Marketing at Appcues
Eric heads up Marketing at Appcues. When he isn't helping companies become more product-led, he’s likely to be found keeping up with his wife and two children, exploring the White Mountains, or fermenting things at home.
Skip to section:

Skip to section:

Great product management is about more than reviewing feature requests. Sure, there’s a never-ending list from your current customers of their must-haves and nice-to-haves. But by the time feature requests make their way to you, your customers already wish those features were part of your product.

Truly great product management is about anticipating customer needs before they make their requests. You understand your product and its use cases so well that you can predict its evolution.

When thinking about “What comes next?” you need to rely on data from less-obvious sources. Data-driven product management, specifically, has become a reliable way to inform product decisions.

Think of this style of product management as a scientific experiment. You begin with a hypothesis and collect research and data to prove—or disprove—your theory. That data will help you form a conclusion and make a decision about your product roadmap.

Start with your hypothesis about the next product feature

Feature ideas rarely come from explicit requests.

You may be aware of customer pain points or hear feedback from your sales team about product shortcomings or competitor offerings.

Product usage insights might also clue you in. You might observe that customers reach a certain point in onboarding and then stop. You need to identify which feature will fill that gap.

Feature ideas may also come from observing market conditions—COVID-19 being a prime example. Or if you’re in a heavily regulated industry, you may note that your product needs to change based on new requirements.

From your observations, you form a theory about which product feature to develop and what its result will be. Ask yourself:

  • Does this feature help draw in new customers?
  • Will this feature better retain existing customers?
  • Does this feature present an upsell or cross-sell opportunity?
  • Does this match the overall product positioning?

Based on the responses to these questions, you are forming a hypothesis: “The next product feature should be __________  because __________.” Your next step will be collecting the data to back up that statement.

Collect customer feedback about your idea

As you begin to imagine your new product feature, you’ll want to make sure it’s a worthy investment before sinking time into it. Data-driven product management involves figuring this out, and your primary data source is going to be your customers.

Your customer support interactions should reflect the pain point you're trying to solve. Review tickets related to the issue your new feature addresses to see whether the solution fixes most of the problems customers mention.  Remember, customers don’t always know how you can solve a problem within a product, so you may not find explicit requests that match your feature idea.

Interview customers who have pain points relating to your feature idea. Set up a time where you can describe the feature to them, and ask whether they would find it useful or not. This customer feedback is critical for making sure your proposed solution addresses the problem.

Your power users—those who are quick to adopt features—are an especially helpful source. Talking with these customers can not only validate your thinking, but also give you some feedback on the feature’s practical application and “real-world” value.

You can also collect feedback from customers through in-app surveys. You might ask, “If we added x functionality, would you find this beneficial?” Surveys are less time-intensive to complete than interviews, so they’re ideal for quickly collecting a large amount of feedback.

You are not merely looking to confirm your hypothesis by collecting this feedback. At this stage, you might discover that your proposed idea is not a good solution. Your customer feedback or survey responses might send you back to the drawing board. And that’s OK! It’s better to discover this early in the process than when you are halfway through development.

Form a conclusion based on your expertise

Your final step in moving forward with a product feature is to collect internal data that helps you determine how much time and resources developing this feature will require.

Projects often go awry when there isn’t enough information to fully understand their resource requirements. Luckily, you’ve already collected much of this data in the steps mentioned above. Create a detailed outline of the project’s scope based on:

  • Customer feedback to determine what functional requirements your feature needs to meet user expectations
  • Product usage data to determine where the feature will fit into your user flows
  • External factors to make sure your product is needed in the current market and compliant

You need to then collaborate internally with developers on the feature’s feasibility. Based on reviewing the scope you’ve set, your development team should be able to identify the amount of time and resources involved. Does this feature bring enough value-add to customers to justify the investment? What is the associated cost of not adding the new feature, either in churned customers or fewer new customers?

By combining your data sources (customer feedback, surveys, tickets, market trends, and more) with developer input about feasibility, you’re set to turn this feature into a reality.

Confirm your decisions with beta testing data

Collecting data doesn’t end with the decision to move forward with developing a new product feature. You should continue to monitor feature adoption through the beta stage and through your product launch.

Repeat the collecting customer feedback step with your beta users. In-app surveys and interviews can confirm that your new feature is on the right track, or if it needs additional work. You can also track events to see how your beta customers are responding to your new product feature.

If the beta test goes well, and you fully release the feature, use the initial data sources you relied on to form your hypothesis—customer input, sales team feedback and product usage data— to measure and improve overall feature adoption.

Data-driven product management is a continuous cycle


Creating the next great product feature is about relying on the information that you have available. Data-driven product management involves identifying what data you can gather and knowing how to apply it.

There is no crystal ball regarding feature adoption, even with decisions driven by data. If you find adoption is low, it can be a lesson in how to better collect data for the next product decision. You may need more feedback, different survey questions, or a more well-defined scope. You can always seek out more data from your sources to minimize your product development risk and keep your customers at the forefront.

Author's picture
Eric Keating
VP, Marketing at Appcues
Eric heads up Marketing at Appcues. When he isn't helping companies become more product-led, he’s likely to be found keeping up with his wife and two children, exploring the White Mountains, or fermenting things at home.
You might also like...