How to Bring Business Context to the Development Team

Problem

"There was a lack of clarity amongst several teams I was working with. It was unclear how to prioritize the decision around which feature to develop next, its refactoring time, and the overall development structure."

"This problem often comes when you don’t know how to prioritize and figure out the biggest impact. At the end of the day, your business needs more revenue. More revenue means more sales, but how this specific feature drives the overall revenue number may not be completely clear to the development team."

"When working for a SAS B2B project we were trying to understand how many users out of the whole user base were using the video editor feature. At the same time, we wanted to know how much revenue these users were bringing to the whole company."

Actions taken

"An approach that I came up with overtime was building a dedicated KPI for the specific product team that connects strategic business goals and features a team in charge of it."

"This then became the metric we used to point to a revenue-driving process - 'the share of wallet' being our specific north star KPI."

"The second part came in needing to figure out exactly how we would drive this measurement forward and increase it. To do so, we created a hierarchy or KPI tree to map out a few features that helped us understand how to move forward with just a few incremental changes here and there. An example of some of those KPI tree brackets were:"

1. Deliver new value for the user
   • "What features can we develop to attract more users?"
   • "Will it help us get more users and drive our revenue?"
2. Further engage our existing users
   • "How can we invest a bit more and polish the feature to increase usage?"
3. Use the cut effect to understand if users are being negatively affected
   • "How are they affected in downtime?"
   • "Are there similar metrics in product performance and speed?"

Lessons learned

• "All the things that can be somehow scoped as quality problems with the product should be measured. This is a good check for when you are thinking about going forward with user stories or refactoring."
• "Once you have a north star and KPI drivers mapped out you can bring them to team retrospectives and team planning."
• "It is important to pick which KPI tree measurements can be improved and corrected. As a rule, we always put some sort of measurement that we want to drive next to user stories that we are working on. At the end day when we deliver it and push it to production we can actually measure whether the metric was affected or not. Then, the development team will understand that it’s not just about 0’s and 1’s in the code base, but about the overall business."
• "The biggest challenge is with the financial department. They are always thinking about numbers and earnings, but we don't get how we contribute to that. This is why it becomes even more important to build that product specific KPI tree for better understanding."
• "In order for this system to work, it is important to distinguish between leading and lagging indicators. If you really want to use KPIs as a way to prioritize tasks with a development team then you need leading indicators. They should be volatile and change over time, allowing you to absorb resolves relatively quickly. Additionally, I would suggest sticking with measurements that can be easily affected and change over time. Without that, there will be very little dynamic and the team can struggle while working on these KPIs."