Evidence-led > Data-informed

Using Every Piece of Evidence to Guide Your Decisions

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.