Return to site

Business win vs Level of Effort

Making good digital decisions at a rapid pace

What is business win?

In keeping with our company strapline 'Software. Simplified.' I wanted to explore a simple but often overlooked aspect of software development, the 'business win'.

By business win I simply mean revenue, money in, return on investment (ROI), or the equivalent term for however you describe the income that your products generate.

The commercial side of software development is often overlooked by technical teams, as performance metrics and financial incentives are rarely tied to business metrics.

A lot of teams keep close tabs on the technical side of software development (and therefore will get good with estimating how long it takes to build different features). By contrast very few teams try to predict the business impact of the features they build, let alone review the business impact once these features have launched to customers.

At the end of the day, the job of a digital team is to build compelling features that drive people to use, buy, or renew a product.

 

In my experience the teams that understand business and technology tend to be streets ahead of everyone else, so that's a culture we try to engender at Day Digital.

Back to basics

Think of it this way... how many times can a startup afford to release software that does not result in business?
 

Maybe a year if they have supportive investors, perhaps just a few uncomfortable months to deliver real value or call it day, and finally a team could be down to their last throw of the dice with just a single release to turn everything around.

With that kind of pressure two very basic metrics come to the fore (whether people realise it or not):
 

1) How much effort will it take to build this feature?
2) How much money will this feature make?

Everyone at a startup is acutely aware of the need to deliver high value features at a rapid pace.

The same principle is at work for large companies even if the existential pressure might not be as intense.

Put simply, you can't afford to spend time working on software that's not valuable to your customers.​

Please note: If you run a not-for-profit product or website, then this article still applies. You may want to think about 'business win' metrics such as usage stats, completion rate, customer satisfaction scores and so on.

What's the level of effort?

You will often hear business owners asking engineers something like 'what's the level of effort?', 'how long will it take to build this feature?', or words to that effect.

Estimates from the technical team form the basis of most sprint planning, project management tools, and also retrospective meetings (i.e. reflecting on a technical team's performance in a given timeframe).

What's the business win?

It's easy to overlook the elephant in the room, 'what is the business win?' (i.e. return on investment) for a given feature.

A good (read: very good) product owner will ask themselves questions around this constantly, even if no one else on the team does.

Good business owners realise that generating business (i.e. value to customers) is ultimately one of the easiest and best ways to measure success, and they will have an approximation for business value in mind for any given feature.

When everyone on the team (including developers) start to take an interest in business metrics this is the icing on the cake. Suddenly a team is thinking of how to increase business value, whilst also remaining technically efficient (as opposed to mainly thinking about technical efficiency).

Putting the two together

The chart below is a very simple way of picturing how these two metrics go together.

This simple rule of thumb is a good way to visualise your roadmap, get business and technical people on the same page (more on that topic here), open up discussions, and promote quick decisions.

The software cycle should not be preoccupied with technical estimates, and then end once a feature is deployed to a server. The software process hinges on whether customers use and value your products. 

Developers often agonise about giving estimates (perhaps overly so), so if a business owner squirms at the idea of estimating how valuable a feature will be, then join the club. It's not meant to be an exact science.

When you plot your roadmap like this, the high business win:low technical effort items stand out, as do any low business win:hard technical items.

Key 'Business win' questions to think about

There are many ways to think about business win, and each organisation will have its owned nuanced take on this metric. Here are some questions to think about:

- Will people use this feature

First things first you should know your customers well enough to take a good guess at how many people will actually use a feature (5%, 20%, 40%, or 100%?).

If you don't know, break the deadlock with some user research, or A/B testing.

- What will happen if we don't include this feature?
The product has survived without this feature so far, and that's a strong argument for leaving it out.

Keep an eye out for acceptable workarounds, if people can already achieve their end objective somehow, then there is no need to clutter your product with unnecessary features.

- Will this feature pay dividends?
All features should increase sales, reduce churn (lost customers), or save money internally (either directly or indirectly).

People talking about a feature does not necessarily mean that clients will part with hard cash when it launches.

Don't sponsor an idea on a hunch. Speak with customers and the customer facing teams, and you'll have a better estimate for business win.

- Should this idea be killed?

If a feature request or idea doesn't fit in with the product ethos and vision, then even if your top customer really, really wants you to build a feature - your focus should always be on overall business win, not short-term gains.

As the product owner you can't be a pushover.

- Is the lack of this feature causing embarrassment?
Not everything will always fit neatly into the Business Win vs Level of Effort matrix, and common sense should prevail.

Sometimes it's OK to break the rules. So maybe a feature that has been on the roadmap for 12 months (constantly getting pushed back, and causing the sales team to lose face in front of clients), or an annoying bug (that makes the product look sloppy), could be good examples of where you might be flexible and bump up their priority.

How might a business win estimate look in practice?

You don't have to say 'I think this feature will earn the company exactly £174,349' you could say that 'on a scale of very low to very high, this is a high value business win item'.

To support your case you might say 'I've done some research with the sales team, and we think that 30-40% of customers will trial this new feature, and 10% of those will go onto purchase'.

If it ends up that 20% of customers trialled this feature, and 12% of those people bought it, then you were over-optimistic in your estimation, but you weren't spectacularly wrong.

The number of customers trialling the feature was 30-50% lower than you originally thought, but the conversion rate of those customers that did trial the feature was very similar to what you predicted (12% compared to 10%).

So the estimates were optimistic, but at least you stuck your neck out, and now you can review why the estimates were off the mark.

Perhaps there could have been better communication to clients when launching the feature, was the pricing too high, or maybe the idea just wasn't that valuable?
 

Now that you are in the habit of thinking this way, it's inevitable that you will improve these skills over time.

If you're too scared to even do these estimates then you'll never make mistakes, you'll never learn, and you'll never get good at this task.

This would be like a software developer going through their entire career without ever predicting how long any task would take them for fear of being wrong!​

Summary - do estimates even work?

People realise there is limited use in obsessing over technical estimates (e.g. 'You said this feature would take 10 hours to build, and it actually took 13 hours and 46 minutes'), so business estimates don't have to be perfect either.

If a developer says something will take them a day to build and it takes them a month (or vice versa), it doesn't exactly fill anyone with confidence in their ability to estimate tasks.

Similarly as a business owner, you don't want to be reliant on hunches and gut feelings ('the sales team are asking me about this feature, it's our top priority!') only to have these constantly proved wrong (the feature launches and barely gets used).

A true product lead is willing to give business win estimates, and more often than not, they'll be in the right ball park.

When developers give technical estimates that are robust enough to plan around, and they get the job done, everyone wants them on their team.

Someone who can give solid business estimates also fills the team with confidence, and people will happily rely on their judgement.

When you have both these aspects (good 'level of effort' and 'business win' estimates) covered by your team, then you're in a very strong position to constantly deliver value to clients.

By David Fallon

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly