How to improve your time to value

At Equal Experts, we often work with stakeholders frustrated by capacity limits slowing their time to value. I’m a delivery lead for Equal Experts South Africa, and I’ve seen this situation before. I’d like to share how a team improved its time to value from months to weeks, by focusing on what matters most.

Introduction

A while ago, I worked at a financial marketplace. I was on the product details team, which owned the customer-facing product details page and some backend APIs. When I joined, the head of product was challenging teams to maximise capacity and improve time to value – the time from having an idea to its realisation as customer value.

Another supplier proposed engineers spend more time on estimates, and log their work hourly for accuracy. I warned that would create a mountain of admin, and said it’s not a capacity problem, it’s a value problem. I outlined the Equal Experts approach to improving time to value:

1. Measure value-add time
2. Prioritise what matters
3. Reduce unplanned tech work

I started to measure where my team was spending capacity, and we generated some powerful insights that helped us to speed up our time to value.

Measure value-add time

In why unplanned tech work kills team capacity, my colleague Steve Smith showed how to measure capacity as product work and tech work. I implemented that model on my team by tagging completed Jira tickets per month, to categorise our work as:

I was on the product details team for over a year, and I ran an analysis each week to calculate what percentage of our capacity was value-add time, i.e. actual time spent on value-adding product work. Here’s our flow distribution chart.

My product manager originally expected 80% value-add time, but this chart showed the impact of non-value-adding work. January was only 40% value-add, March was 50%, and September and October were 45%. Non-value-add doesn’t mean unimportant, the tech work usually had to happen, but it was time away from product work. And when we looked deeper at our value-add time, it was clear we had a significant prioritisation challenge.

Prioritise what matters

Here’s some more detail on how I modelled product work.

Prioritising unplanned product work was straightforward. Teams sometimes needed new attributes from our backend product APIs. Ideally, that would be planned product work, but teams often asked for changes at the last minute, and we handled them immediately.

Prioritising planned product work was difficult, as user needs came from our product manager, and business initiatives from a portfolio management team.

The variation in our value-add time (January was 30% user needs, 5% initiatives whereas November was 5% user needs, 65% initiatives) highlighted our prioritisation challenge:

• Our product manager was accountable for product details ROI, and wanted to maximise user hypothesis testing
• The portfolio team was accountable for cross-team coordination, and wanted to maximise business initiatives delivery

Those misaligned incentives led to too much work in progress, context switching, and inefficiencies. Someone once asked me to start another initiative, and I had to say that my 5 engineers already had 12 in progress. I pointed them to Accelerate by Dr. Nicole Forsgren et al, which explains the value of work in progress limits.

Something had to change, so we showed our value-add data to the head of product. They hadn’t had those insights before, and were surprised by the impact of business initiatives. As a result, we all agreed on some prioritisation guidelines:

1. Value-led business initiatives
2. User hypotheses
3. Other business initiatives

This gave us a clear focus. We replaced planning estimates with forecasting e.g. ‘70% of our capacity can be value-add in the next quarter’. We limited our work in progress to 3 initiatives, and balanced them with A/B user experiments. We gradually improved on flow efficiency until by the end of the year, our time to value was weeks not months!

Reduce unplanned work

Here’s how I modelled tech work on the product details team.

Planned tech work was about removing sources of unplanned tech work, and our product manager was open to fixing technical debt if there was a strong case. For example, the team flagged that intermittent test failures cost 5 hours a week, and requested time for a permanent fix. The product manager agreed to schedule it a few weeks later.

Handling unplanned tech work was more complicated.

Unplanned tech work spiked in January (25% reactive fixes, 10% platform upgrades), and again in October (20% platform, 10% fixes). While platform upgrades were worthwhile, the time on reactive fixes was concerning, and the team’s live services were a key factor.

The organisation’s maintenance mode solution was for zero demand services to become background BAU. When a live service ran out of funding, it was transferred into a long-lived team like mine, and in a year we went from one service to six. The older tech stacks led to more platform upgrades and more reactive fixes, and less value-add time.

We managed the situation by introducing modern engineering practices into zero demand services, and using our quarterly capacity forecasts. Our product manager was able to say ‘I only have 70% value-add time next quarter due to the 6 services I already own’. This resulted in a better balance of zero demand services between teams, and value-add time for my team remained intact.

Conclusion

At Equal Experts, we empathise with senior leaders when they’re frustrated about team capacity and time to value. Hiring more engineers might be the short-term answer if you’ve got the budget, but it isn’t the long-term answer. It’s not a capacity problem, it’s a value problem. We recommend:

1. Measure value-add time
2. Prioritise what matters
3. Reduce unplanned work

And a lot depends on how your teams and services are architected. For example, there weren’t any significant handoffs between teams at the financial marketplace. Handoffs harm your time to value, but they show up more clearly on a value stream map than a flow distribution chart.

The answer to improving time to value isn’t more estimation, it’s more focus. Better measurement, prioritisation, and removal of unplanned tech work will accelerate delivery. You can change the conversation from ‘how long will it take?’ to ‘what do we do next?’