There was a time when everyone said that product managers and engineers should be data-driven. Data helped us track user behavior at a large scale. Numbers answered questions and sometimes sparked new ones - why did a key metric change in September?
Soon, many learned that data alone pointed out problems, but did not provide clear next steps. Teams observed what users did but still struggled to improve things. This taught us that combining numbers with listening to customers is essential. Short insights, like quick feedback, can be as valuable as big data. In short, be data‐informed instead of simply data‐driven.
Today, building a great product requires more than just using quantitative data and qualitative, empathic user insights. Combining both, good decision can be made. One person on LinkedIn called this approach “evidence-led.” (Unfortunately, I cannot find the post anymore for proper credit.) Along with data, sources such as user interviews, surveys, and direct feedback play an important role.
What evidence is there that product teams can use? Let’s create a long list:
Customer-Related Evidence:
User feedback from support tickets
User feedback from direct conversations
Scores of Customer satisfaction (CSAT), Customer Effort Score (CES) and yes, still Net Promoter Score (NPS)
User behavior analytics and usage patterns
Customer interview transcripts and insights
User testing results and observations
Feature adoption rates
Customer churn data and exit surveys
User journey mapping data
Session recordings and heatmaps
A/B test results
User persona validation data
Market Evidence:
Market size and growth projections (incl. Total Addressable Market, TAM)
Market share data
Industry trend reports
Competitor analyses
Patent filings in relevant areas
Geographic market differences
Price sensitivity studies
Technology adoption curves
Technical Evidence:
System performance metrics
Code quality metrics
Technical debt assessments
Security audit results
Infrastructure costs
Development velocity metrics
Bug reports and severity trends
API usage statistics
System reliability data (uptime, etc.)
Business Evidence:
Revenue projections
Customer acquisition costs (CAC)
Customer lifetime value calculations (LTV)
ROI calculations for features
Development cost estimates
Sales cycle length
Conversion rates
Operating costs
Budget constraints
Partnership opportunities
Team Evidence:
Team capacity metrics
Resource availability
Skill gap analysis
Cross-functional alignment assessments
Regulatory/Compliance Evidence:
Legal requirements
Compliance audit results
Industry standard certifications
Privacy and security assessments and data protection requirements
Accessibility data
Historical Evidence:
Past project post-mortems
Previous feature performance data
Legacy system documentation
Innovation Evidence:
Research and development findings
Technology feasibility studies
Emerging technology assessments
Proof of concept results
Experimental feature data
Stakeholder Evidence:
Executive feedback and priorities
Board member input
Investor requirements
Partner feedback
Sales team input
Marketing team insights
Customer success team feedback
The list is unsorted, but customer evidence always tops the list if you want to create products that truly serve your users.
When planning product decisions, gather all the evidence you can find. Avoid basing choices solely on opinions. Let every bit of proof guide your decisions. Be evidence-led.
What I read
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:
Advice on how to be a bad PM with a good career: What to do to avoid hassle and be promoted while not building successful products.
Large projects, broken up: How to successfully deliver large projects.
Referent Power: Referent power comes from the personal qualities, respect, and admiration a leader inspires in others. It is different from coercive power.