Russ Jeffery, Head of Platform Strategy @ Duda Stephanie Hsiung, CFO @ Duda The world produces 2.5 quintillion bytes of data each day. Yet, measuring the productivity and quality of development and product teams is incredibly difficult. Many metrics used in the industry (commits, features delivered, jira tickets closed, roadmap items delivered, etc..) are bad measures of what we care about: progress. Learn about what modern development teams focus on that leads to better outcomes.

1. Stephanie Hsiung
CFO
Duda
Russ Jeffery
Head of Platform Strategy
Duda
1
Measuring Product Development Teams:
The Metrics you Need to Track

2. Why measure product orgs?
● “If you can’t measure it, you can’t improve it”
- Peter Drucker
● What we measure reflects on our values and
builds our culture
● We want to encourage positive behavior
● We want to understand if we are getting better.

3. The wrong metrics
To measure
productivity

4. High Level Business Goals &
Benchmarking

5. 5
● Generate $10K in MRR from users
purchasing New Feature X
● Benchmark of $100k in MRR per
engineer
● Spend no more than 35% of OpEx
in R&D
Examples:
Business Goals

6. 6
● Easy to measure
● Comparable between
companies
● Leading indicators of scale
● Revenue growth is core to all
business units
Why:
Business Goals
● Depends on too many unrelated factors
(sales/marketing/customer success)
● Doesn’t necessarily say much about
product quality
● Hard to compare between periods
Why not:

7. “Deliver 80% of our product
roadmap”
Roadmap delivery

8. 8
● Reflects on overall delivery
● Clear business value
● Easy to measure
Roadmap delivery
Why:

9. 9
● Estimating projects is the hardest
thing in software development
● Things will ALWAYS change
(and they probably should)
Why not:
Roadmap delivery

10. Responding to change
over following a plan
Agile Manifesto

11. Most of the time, change is a good thing.
I think that’s what it’s all about.
Embracing change.
Ted Lasso

12. 12
Your roadmap should be a snapshot of the
current list of priorities and a vision for the
future.
It should not be a project timeline, a detailed
plan or a team commitment.
Roadmap delivery

13. A better path…

14. Don’t measure success.
Measure proxies for success.
Measure the creation process.

15. DORA Metrics

16. 16
DORA Metrics
Change failure rate
Lead Time
(first commit to production)
Deployment Frequency MTTR (mean time to restore)

17. 17
DORA Metrics
Elite High Medium Low
Deploy
Frequency
On demand
(CD)
Between 1
week to 1
month
Between 1 to 6
months
More than 6
months
Lead time for
changes
< 1 Hour
Between 1
week and 1
month
Between 1 to 6
months
More than 6
months
Mean time to
recover
< 1 Hour < 1 Day 1 day to 1 week
More than 1
week
Change Fail
Rates
0-15% 31-45% 16-30% 16-30%

18. 18
DORA Results
2.2x
Elite/High Performers are
2.2x more likely to be
rated as a good place to
work
22%
Less unplanned work for
high performers

19. Prefer observability and learning
over metrics

20. 22
● Business KPIs and Growth are not always great
measures of team progress and productivity
● Dev & product outputs may be interesting
indicators but don’t actively measure them
(lines of code or roadmap completion)
● Measuring “impact” is important but tricky,
look for success proxies and built a culture of
learning
Conclusion

21. THANK YOU!
Visit us at booth: #243 | www.duda.co