Business Impact Driven Development

(Business) Impact driven development is the approach of the new feature development, based on the analysis of the business benefits of the new functionality.

In my talk, I am going to show examples of metrics and indicators, how you can quickly configure business intelligence and begin to analyze user behavior.

Transcript

1. 1 Business impact driven development Dmitry Salahutdinov 12/10/209
2. Hey, my name is Dmitry 2 +
3. 3 About myself :)
4. AMPLIFR 4
5. 5 Vital project: 400m2
6. Continuous delivery
7. Canary releases A/B Testing, Green Blue Deployment
8. 8 Feature Toggling
9. Experimenting
10. Measuring
11. Analysis & Reinforcement
12. 12 Process is iterative and continuous Area, time, workers are limited 
 Needs are growing persistently
13. 13 Продакт овнер? Growth hacker? Startup?
14. 14 Продакт овнер? Growth hacker? Startup? Product owner?
15. 15 Продакт овнер? Growth hacker? Startup? Product owner? Growth hacker?* * https://en.wikipedia.org/wiki/Growth_hacking
16. Yep! Run experiments to increase output Monitoring Analysis Changes
17. 17 Using tools and techniques to turn data into meaningful business insights Basis: analytics
18. Business metrics Trial to Payment conversion Paid users outflow 18 High-level product performing indicators (money)
19. 19 Product metrics ↗ Feature Usage Middle-level indicators in terms of product features efficiency
20. 20 Tech metrics Low-level metrics showing how the technical underground perform
21. 21 All fo them Are numbers
22. That are the only one truth Measure The only One Truth! Everyone in your team has own background and insights Product analytics works both: for developer & product owner 22
23. 23 Why do we love metrics? - is the only one source of true data
24. 24 Analytics/Metrics - is the only one source of true data - helps approve good ideas
25. 25 Analytics/Metrics - is the only one source of true data - helps approve good ideas - helps reject bad ideas
26. 26 Analytics/Metrics - is the only one source of true data - helps approve good ideas - helps reject bad ideas - works both ways
27. Reject idea: sticky header & footer Average user screen height is ~600px 27
28. Example: Main feature fails Error rates correlates with users outflow User outflow Let developers earn money by increasing code quality: Do refactoring legacy code and give back technical debt ☺ Process fails 28
29. 29 Product Owner Developer Business Project: Role distribution
30. 30 Product Owner Developer Business Startup: role distribution
31. Proper tools (requirements) 31
32. Tracking events 32
33. Show graphical data, compare charts Data visualisation Scheduled Post Created Draft 33
34. Metadata Event metadata stores “as is” User metadata associates within current event Pass extra user & event data to analytics 34
35. Metadata usage Scheduled Post
 by user having Billing Plan “A” Scheduled Post
 by user having Billing Plan “B” 35 Extra date for details analysis
36. Multiple platroms support Mobile application Web(frontend/backend) 36
37. Release tracking Release:
 feature deployment Release:
 feature improvement 37
38. Instrumentation 38
39. Amplitude 39 https://help.amplitude.com/hc/en-us/categories/200409887-Getting-Started
40. 10 millions events for free 40
41. Amplitude API 41
42. Backend integration Ruby sample Node JS Mobile 42
43. Frontend integration 43
44. Share user properties Render “backend” User properties Pass actual user properties With events 44
45. Empirical tips 45
46. verb + noun (e.g. 'clicked signup’) noun + verb (e.g. 'signup clicked') Naming Scheduled Post Draft created Save post saved Fail to post ... ... ✅ ❌ Event naming convention prevents entropy 46
47. Separate environments To keep experiments pure and prevent testing events mixing Overall data Testing data Very significant for low traffic experiments! 47
48. Organise events & properties And keep it simple 48
49. Use cases 49
50. Existing feature analysis Start to collect metrics - measure feature performance - make a decision: improve or remove Measure business performance metrics before 50
51. New feature investigating/testing Start to collect metrics New feature deployment Ensure to have previous and next metrics collected 51
52. Incremental improvements Do small experiments with performance analysis 52
53. Impact driven? 53
54. 54 Every change has to have an impact Impact driven?
55. Impact work cycle 55 - collect metrics
56. Impact work cycle 56 - collect metrics - analyse performance/profit
57. Impact work cycle 57 - collect metrics - analyse performance/profit - make a prediction (hypothesis)
58. Impact work cycle 58 - collect metrics - analyse performance/profit - make a prediction (hypothesis) - deploy & monitor
59. Impact work cycle 59 - collect metrics - analyse performance/profit - make a prediction (hypothesis) - deploy & monitor - repeat if ok, reject if not Experiment
60. Necessary conditions 60 - Statistical correctness of analytics
61. Necessary conditions 61 - Statistical correctness of analytics - Traffic/Duration tradeoff
62. Necessary conditions 62 - Statistical correctness of analytics - Prevent interception - Traffic/Duration tradeoff
63. Necessary conditions 63 - Statistical correctness of analytics - Prevent interception - Overhead for small experiments - Traffic/Duration tradeoff
64. Necessary conditions 64 - Statistical correctness of analytics - Prevent interception - Overhead for small experiments - Time consuming for huge ones - Traffic/Duration tradeoff
65. 65 Hypothesis selection
66. 66 Idea: ??? What is it for:??? How it will help:??? Voting
67. 67 ICE scoring* Impact, Confidence, Ease * https://tech.trello.com/ice-scoring/
68. 68 * https://tech.trello.com/ice-scoring/ Doubt? Measure! ICE scoring* Impact, Confidence, Ease
69. 69 Experiment duration?
70. 70 Hypothesis check: hard-code way 7 day trial
71. 71 Hypothesis check: practical way Wait until data get stable Double check by reverting back
72. 72 Hypothesis check: math way
73. 73 Summary: - Metrics are good - Experiments are the best - Analysis is better
75. Feature availability Unexpected ideas could work feature visibility with ugly hack improved conversion ' 75
76. Unexpected ideas could not work 6%↗ post popup cancellation 76
77. Settings => Subscription ~20% Change Project Name => Activate Subscription Let just force people to change project name and earn 77
78. 78 Why analytics/hypothesis?
79. Makes everyone happy 79 →Everyone on the team understands the core business model, i.e. who is paying for what and why
80. Makes everyone happy 80 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life
81. Makes everyone happy 81 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life → Improves team communication by building a common language
82. Makes everyone happy 82 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life → Improves team communication by building a common language → motivates the team by showing everyone their impact
83. Makes everyone happy 83 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life → Improves team communication by building a common language → motivates the team by showing everyone their impact → improves the product debate and arguments by providing a system
84. Makes everyone happy 84 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life → Improves team communication by building a common language → motivates the team by showing everyone their impact → improves the product debate and arguments by providing a system → summarises the perception of the project
85. Makes everyone happy 85 →Everyone on the team understands the core business model, i.e. who is paying for what and why → Improves engineering team culture by building awareness of how customers use different features in real life → Improves team communication by building a common language → motivates the team by showing everyone their impact → improves the product debate and arguments by providing a system → grows team experience, skill, and expertise. → summarises the perception of the project
86. 86 Give it a try In your startup
88. STACHKA 15% discount coupon ❤ 88
89. 89 Thank you @dsalahutdinov1 dsalahutdinov@gmail.com https://dev.to/amplifr https://amplifr.com ♥