How to Bring Business Context to the Development Team

Conflict solving
Collaboration

15 May, 2020

Maria Petrova, Principal Product Manager at Zalando details how she strategically mapped out features using a KPI tree to drive measurement, ultimately helping the development team understand their role.

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?
  1. Further engage our existing users
  • How can we invest a bit more and polish the feature to increase usage?
  1. 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.

Related stories

Leveraging Diverse Peer Groups for Tighter Feedback
24 May

With both the need for a more supportive team setting and shorter feedback cycles, Marc LeBrun, VP Engineering at Flow Kana, addresses two problems with a single solution.

Team reaction
Cross-functional collaboration
Collaboration
Marc LeBrun

Marc LeBrun

VP Engineering at Flow Kana

How to Bring Business Context to the Development Team
15 May

Maria Petrova, Principal Product Manager at Zalando details how she strategically mapped out features using a KPI tree to drive measurement, ultimately helping the development team understand their role.

Conflict solving
Collaboration
Maria Petrova

Maria Petrova

Principal Product Manager at Zalando

The Power of Introspection in Career Growth
15 May

Tarani Vishwanatha, Senior Engineering Manager at Scribd, shared a story where he dealt with the conflict of an upset engineer that did not get a promotion he believed he was entitled to. He explains the distinction between being the most technical and being well rounded. Vishwanatha talks about the importance of being self-aware as it's essential to career growth.

Team reaction
Coaching / Training / Mentorship
One-on-one
Conflict solving
Tarani Vishwanatha

Tarani Vishwanatha

Senior Engineering Manager at Scribd

Building an Effective Partnership Between Product & Engineering
15 May

Paulo André, VP of Engineering at TourRadar, emphasizes all the benefits of enhancing partnership between Product and Engineering and explains how to achieve it.

Cross-functional collaboration
Internal Communication
Collaboration
Paulo André

Paulo André

VP Engineering at TourRadar

How To Deal With Conflict At the Workplace
13 May

Stefan Gruber, VP of Engineering at Bitmovin, shares how he successfully mediated the conflict between two of his employees.

Conflict solving
Internal Communication
Stefan Gruber

Stefan Gruber

VP of Engineering at Bitmovin

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.