In the world of business and finance, ‘Value Driver Trees’ are the compass guiding organisations toward their financial goals and strategic success. These versatile tools offer a detailed roadmap for dissecting and understanding the key drivers that impact a company’s value, from revenue growth to cost management and everything in between. In this blog post, we will explore the powerful concept of ‘Value Driver Trees,’ unraveling their significance, and demonstrating how they can help businesses identify opportunities, make informed decisions, and ultimately drive their financial performance to new heights.

A challenge I see software developers and software delivery teams face is finding the connection between their work and their overarching organisational goals. Communicating this with both the delivery team and the customer (internal or external) can also have its challenges. It can be difficult to prioritise work, know how big or how small to aim and know when enough is good enough. I will share with you three common problems and will build up to show you how Driver Trees can help you and your team mitigate these problems to confidently communicate, prioritise and deliver valuable work.

Focus on outcomes

In many software delivery projects, there tends to be a bias towards the projects being either Developer led, or Customer led. It can be common for a strong developer, or even just a strong-willed developer, to set the direction for a project. This can often end up with outcomes that have a bias towards the technical. We may see task items in a project resemble things like:

  • Add Index to the Orders table
  • Compress Landing Page images
  • Connect Salesforce SSO
  • Deploy Kubernetes cluster

The issue with task items like these is, the customer is unclear what value they are getting out of the work. While these maybe work items that need to be done, it is unclear why they need to be done.

Alternatively, if the bias is towards being Customer driven you may see task items that more closely align to language the business might need:

  • Upgrade Order Management database
  • Refactor Landing Page
  • Implement Salesforce
  • Set up infrastructure

The issue now flips to the confusion landing with the software developers. It is now unclear what the tasks are that will complete the work.

Techniques like Epics, Stories and sub-tasks aim to allow high level customer focused tasks connect with low level developer activities, but I constantly see an impedance mismatch where either, the customers feel the wool is being pulled over their eyes and they don’t have control over the project, or the developers feel bullied where they are given either vague outcomes or oddly specific implementation work to complete.

Example

Let’s consider a fictional example, where a team needs to solve a problem where a number of customer accounts are being closed due to their limit checks not being completed. The Sales team are frustrated because they keep finding out that accounts keep getting closed, which affects their sales targets. The back-office risk team is frustrated that they keep having to close accounts and look like the bad guys. The challenge is that once a limit check has been requested, the check needs to be completed in 30 days, or the account is automatically closed for compliance reasons.

The delivery team understands that the sales team need to know about a credit limit breach that is triggered in the back office. They need to know quickly so that we can reduce the number of accounts being closed by the back office. A developer on the delivery team identifies that an ideal solution would be to integrate the Sales Platform to the back-office credit system.

The team get together to provide an estimate for integrating the Cloud-based Kubernetes stack with the back-office mainframe in the datacentre. The conversation escalates to discussing securing PII data, considering retry semantics, and pondering if we could have synchronised comments tracking between the two systems.

This is where things get problematic. The delivery team will now fall into the ceremonies of estimating and planning for this solution, but they don’t have an outcome yet, they are only planning outputs. They have identified the solution is “to integrate the Sales Platform to the back-office”. The outcome is… “to integrate the Sales Platform to the back-office”. The solution is the outcome.

If the team however took some more time to talk to the Head of Risk and Head of Sales, they will have found that:

  • the sales team are well trained in completing customer limit checks
  • the sales team are highly motivated to complete customer limit checks to keep accounts open
  • the sales team are unaware of when a customer is under limit review
  • neither the sales nor the back office team are particularly interested sharing comments on an accounts limit review progress

It was distilled that both departments just wanted to

Reduce the number of account closures due to incomplete verification.

Customer needs

Working with this business specific outcome, the delivery team were able to use the new information they had to make a bet and verify it with their customers. The bet was that if the sales team were just notified when an account went under limit review, that account closures would be reduced. Both the Risk and Sales teams agreed and pointed out they were also indifferent of how they were notified; it could be a message over email, Slack or SMS. The team identified that the back-office logging system was already integrated with Slack, and that in under 1 day they could deliver a mechanism that sent a slack message within 5minutes of when an account moved to under review.

By focusing on business outcomes, instead of technical solutions the team was able to deliver real business value, very quickly. They were also able to de-risk the project by removing imaginary constraints and requirements; no PII data, no comment tracking, no Kubernetes cluster.

Measurable outcomes

Focusing on outcomes is a big move forward for many teams, however it will just unlock your next challenge. From the example above we moved to focusing on an outcome of “Reduce the number of account closures due to incomplete verification.” Given the that usual number of accounts being closed per month is 10, what should the team be aiming for? If they reduce it to 9 is that a huge win, or if they reduce it to 2 will that be seen as a failure? Without these numbers, it become hard to know how big the solution should be. It can be it hard to plan, and it can be hard to know when to stop. This can be a defeating feeling for people who are putting the effort in to focus on business outcomes, to only come up short when it comes to delivery, or they over deliver and waste delivery resources.

The solution used above came up with a simple model that was likely to reduce the number of account closures. But it really did rely on the Sales Team having a tight process to take the Slack message, and assign the limit check to a Sales person. It also assumed that the logging to Slack integration was guaranteed delivery, which seems unlikely. If the goal was to reduce the number of account closure from 10 to 5, then this solution is likely to yield very good value. However it the outcome is that 100% of account closure needs to be avoided, then this may be a temporary measure at best. We can go back to the customer and get further clarification on the success metrics:

Reduce the number of account closures due to incomplete verification from 10 per month to 2 per month.

Customer’s measurable outcome

By shifting to measurable outcomes, you are more likely to find plans and solutions that are a proportional response to the challenge at hand. This can strengthen your planning, however it also allows you to be more adaptive. If you have a fast feedback loop, then during a project, if you see that you have met your target for the metric being tracked, then you have a credible reason to stop the project. The ability to stop a project early, is an unusual ability for many software delivery teams, most of which at best always finish on time, more likely over run. However, if you have adopted a process that provides the ability to finish early, you are able to start new projects or find time for weeding and feeding.

Driver trees

Once you start thinking of measurable outcomes, you will find that many parts of the business already have well defined metrics that they use to measure success. Sales teams will have sales targets, Marketing teams will have acquisition and retention targets, finance will have budgets and forecasts, and as a Software Engineer you are probably tracking delivery and operational metrics.

If we focus on Marketing, they have a few very common metrics that they chase; ROAS, CPI/CPA, LTV. The challenge with these metrics is that they cannot directly be affected. For example, CPA (Cost per Acquisition) is a lagging metric that tells me how effective my spend has been to acquire a customer. While I can’t change that value directly, I could spend less money, and trust that my efficiency will improve. If it does then my CPA metric will improve. However, I will have spent less, so I have most likely reduced my overall number of acquisitions, which doesn’t seem good. So, the thing I can affect is “advertising spend”, but I cannot directly affect “Cost per Acquisition”.

To better understand the various levers I can directly affect, I have found Driver Trees to be a simple, yet effective tool to help me connect my work with the goals of the business or my customer.

Driver trees

A driver tree helps me understand how get from the things that the Business Cares about and measures to the things I can affect.

In the example below I have a Business Metric that I am Calling “New Users”. I have figured out that the business also has two other metrics that they track that directly affect it.

  1. “Click to Registration Rate” aka Click to Reg.
  2. Impressions.

If the impression rate stays the same, but I improve the Click to Reg, then we get more new users. If however I keep the efficiency measured by Click to Reg the same, but increase the number of impressions, then I get more users.

I already feel like I better understand our marketing process.

However, I can’t really affect those metrics, So I drill down further. I have noticed that the Click to Reg rate is directly affected by Click to Land rate and the Time to Register. I also found out that Impressions are driven by Ad Spend and the number of Channels of Ads that Marketing can use. In my department, I can’t do much around the Registration flow or the marketing spend, I look into how I can manipulate Click to Land.

This is exciting. I have found a great proxy for web performance called WebVitals. WebVitals breaks down into three things I can control: Page load time, Semantic Content and Secure Web Practices. With this information we can make bets like “We believe that by reducing Page Load time from 4seconds to under 2seconds for 99% of landing page views, we can improve Click to Reg rate from 50% to 60%”. This now gives the software developer clarity on what their task is, and the context of why they are doing this. It also leaves room for the software developer to innovate. They can find ways to reduce the page load time. They may choose to compress images, use a CDN or just reduce the number of network calls. This should both be empowering for the developer, and reduce the burden on the Product Manager, Business Analyst or whomever writes the requirements and project tasks.

I found my levers I can pull, the knobs I can turn. This is great for myself and for my team.

I now can identify which part of the tree I am targeting and make bets on which drivers I should be manipulating. However, where driver trees can become effective across the organization is where you can use the same language as both the business and other delivery teams.

When multiple teams find that they are blocking one another, or possibly misaligned, then driver trees can help provide clarity of priorities. For example, it another team was blocked on my team, but their work was focused on improving the Time to Register, we could see that ultimately we are both working improve Click to Reg and we can use this to verify business priorities are aligned.

Driver trees brings another benefit; they allow you to find domino effects. Like Wardley Maps, you can find the tasks that will reduce or remove the amount of work to deliver future value. Taking this into account when planning work gives you more clarity when prioritizing work.

Takeaways

By thinking of measurable business outcomes and using common business language we are better able to communicate with both our customers and other delivery teams. By connecting the value, we can directly affect to these business outcome through driver trees we are able to identify lead dominos and areas of high impact. Making bets on which levers to pull and being able to verify those bets in advance with the business, and in retrospect through measurement allows us to better plan now and in the future. Given a fast enough feedback loop, measurable outcome also provides us the permission to stop projects early when we see that we have already hit our targets.

Further reading: