Functional Equivalence vs Equivalent Value (and why you can’t reuse a cake!)

‘As per live’, ‘like for like’, and ‘lift-and-shift functionality’ – all these are expressions for Functional Equivalence as a baseline for a new product. And all should be a red light to analysts, architects and product people. So what do they mean? Why are they such common ‘requirements’? And why are they dangerous to project outcomes, timelines, and budgets?

In this blog Bryony Berry, Lead Consultant, Business Strategy and Analysis, explains all.

Firstly, what do I mean by Functional Equivalence and all the terms we use to refer to it?

I am referring to taking the current product feature set as a baseline of requirements for a new product. Most commonly, we see this with customer-facing website re-architectures, but it’s also common in other spaces, especially where the data on feature value is sparse or hard to disentangle.

You’ll recognise it in any project scope that starts with the following sentence: “There will be no loss of customer features” or “The new XXX will have what the current XXX has”.

In the case of a website, sometimes, though not always, this is followed with a list of journeys, pages, and features that the current site provides, and that becomes, with little analysis or challenge, ‘must haves’ in the new product backlog. And this is where it gets expensive, and sometimes, to be honest, a little bit soul destroying. But it needn’t be this way.

Why is there this tendency towards ‘no loss of functionality’ at the beginning of a project?

There are a complex set of reasons and I’ll explore a few, but the core part of it, I believe, is this:

Each feature on a customer-facing website, and every Net Promoter Score or conversion point improvement, has been hard-won by the team involved, often over a long period. And without advanced data and feature-value-tracking processes post-launch, the business has little reassurance that any single feature isn’t the key to the current performance. And that is a scary puzzle to start taking apart.

On top of that are a few interrelated things:

• Firstly, time. Analysis and research to determine which of the current features are really driving value can be hard to do, time consuming, and frankly, not as appealing to businesses and product people as thinking about new features.
• Secondly, ownership. Almost all the ‘current features’ on a website will have been the topic of a previous business case and supported by someone in the business, often the same stakeholders involved in the project, so challenging their value can feel dangerous.
• Finally, and critically, because this is the part I think is actually the flaw in the argument, they feel ‘cheap’ or even ‘free’. And here is where I think the thoughts and feelings around them take over, and the challenge fails to materialise.

Because they feel low cost, why take on the risk that the customer will miss them?

Because they feel low cost, why take on the risk of annoying an established stakeholder?

Because they feel low cost, why spend the effort confirming if they actually do deliver value?

The answer is because they are not low cost.

Often far from it. These ‘baseline’ features usually consume a significant portion of the total project budget in both time and money. Often, they are not much cheaper to implement the second time around, from a development perspective, than they did the first time. And often, because they are ‘must have’ requirements, they are delivered early in the project and delay any learning or benefits from the new features that could otherwise be gained early on.

But it doesn’t feel this way, so often we underestimate that cost and fail to put the same rigour into justifying the spend, and relative priority, that we would with a new feature.

But why aren’t they cheaper to build? We’ve already built them once, can’t we just copy what we did then?

Yes, and no. But mostly no.

(I should add the caveat here, of course, that sometimes there is an exception, and a feature can be copied as-is and reused without lots of additional work to make it possible, but it is a very rare occurrence in my experience.)

So why not?

Let’s think of the structure of a cake.

Two layers of sponge, some jammy substance in between them, and some icing on top. Perhaps on top of the basic icing are also flashy bits, twirls and sprinkles, or perhaps the cake stops at the basic icing, but there are at least four distinct layers.

Most websites have a similar construction and a lot of applications. Some code does things in the back end, some code does things in the front end, and between them, an API sticks them together. On top of them is a presentation layer, perhaps with some complex user rendering logic or customer interactions or simply displaying data on the right pages in the right way. It’s this top layer that most of our customer-facing features live, often with data dependencies and/or logic in the ‘cake’ and ‘jam’ layers, but they are mostly icing. If the website is all microservices, maybe it’s actually a big tray of mini-cakes, but they probably have a similar construction of four-plus layers, at least in some way, shape or form.

A lot of other applications will have a similar structure, and of course, this is massively simplified, but bear with me, and hopefully, the oversimplification will prove useful.

Now we imagine our new re-architecture is to make the ‘same cake’ but gluten-free, or vegan, or the top layer both gluten-free and vegan, but also with all the same customer-facing features. This is our website going cloud-native, using a different CMS, or undergoing a significant re-architecture, ‘with no loss of functionality’.

As you can imagine, a lot of the layers are pretty closely ‘coupled’ to the rest of the cake – we can maybe take the bottom layer off and ‘reuse’ it and some of its jammy layer – but we need to be careful. At least some of that middle layer is really part of the top layer now, so we’ll need to do some work there. Perhaps we can reuse certain bits of the flashy things on top of the basic icing if they’ve been constructed in such a way, but the chances of reusing the basic icing itself or any of that top layer of cake are pretty slim. And depending on the new cake specifications, they may not be suitable anyway.

So what is our project? Chances are we’re baking at least one new sponge layer, possibly two, adding a fair bit of jam to our first layer of icing. And if we need to replicate the previous cake, we need to replicate all the fancy bits on top and make sure our top layer is big and strong enough to support them. All this before we’ve got to any additional things that are integral to the ‘new cake’ business case.

We can see now, I hope, that the ‘like the other cake’ feature requirements aren’t really any smaller to deliver in our new cake than they were on the old one or compared to any new features.

And here’s where it can get really sticky….

The other reason ‘as per current’ features feel like lower cost features are because they often demand less business attention. If the business has made blanket decisions that they’re needed, then they aren’t fought over in prioritisation or scope discussions. Because they are already out in a usable environment, requirements are often defined with minimal effort as ‘as per current’, without new visual or technical designs or complete state/interactions scenarios, etc.

So for much of the early part of the project, minimal work is done on them. This makes them feel ‘easy’ – easy to define, so easy to build, right? Wrong. And this apparent timesaving is more expensive than it first appears.

If the previous features we need to replicate aren’t defined with requirements but handed over as ‘like the old cake’, then we can be introducing complexity with no value, which is very hard to see.

I’ll give you an example.

Imagine our ‘current cake’ is a wedding cake. Complete with the confectionary bride and groom on top.

When we copy the old cake without requirements as to those features, we don’t know where the value lies, and there is a tendency to overcomplicate to avoid any potential loss of value.

Now, if the old cake had a beautifully handcrafted couple that was carefully modelled on the wedding couple, a close copy is probably vital to replicating the value. But if they are a generic representation of any couple, a close copy is a wasted effort – an off-the-shelf one might deliver the same value as a near-perfect confectionary recreation of the original pair. What’s more, without supportive requirements, we have likely had to reverse engineer the materials used to make it, so before we even started building, the technical analysis and design work took significantly longer than it could have.

Finally, we missed an opportunity. If we looked afresh at our ‘couple requirements’ in light of our latest understanding of our customer, there might be additional value to be delivered at no extra cost in the build. We could decide we’d prefer a more abstract, gender-neutral couple or figures who are more representative of the diversity of our customer base. If we’d given the previous ‘requirement’ the same thought as a new one, we could make sure our delivery aligns with the outcome and value we need the feature to deliver, no more and no less. Without that, we’ve spent three weeks studying, deconstructing and finally replicating perfectly something that could have been generic and wasn’t all that representative in the first place.

A re-architecture is an opportunity to declutter, like moving house.

But that is not all. The ‘new cake’, like a new website or any other application, is a brilliant opportunity to simplify and par back the features that have built up over the years. It is an opportunity to only spend new development budgets on those features that really earn their keep in value to the customer or return on investment. But this is where our cake analogy runs out of value, so like an old feature, we leave it here – and like new features in a re-architecture, we add in a new one!

Like a house, over time applications accumulate features, and parts of features, which have little or no value to current users. When we re-build them, like when we move house, it’s an opportunity to leave out the bits that aren’t being used frequently or aren’t delivering unique value. Often this is ‘equivalent features’, e.g. three ways to get into a checkout flow or two ways to search the site. Other times it’s something we thought had value at the time but doesn’t seem to be used much now or not the way we thought it would be. This might be some search terms, payment methods, content pages or mini-user journeys – things we tried and can learn from but don’t need to reproduce. Are we really getting value from that tagine or the lemon zester?!

This kind of decluttering can significantly reduce the ‘as per current’ backlog. If done early and with a firm hand, it can free up time to provide great requirements on the current features that do add value so they can be built in the most efficient way possible.

A smaller backlog with higher quality requirements is a faster, cheaper project.

Now our project baseline isn’t ‘Functional Equivalence’ but ‘Equivalent Value’, and all our requirements, both old and new, can be prioritised on expected value, because what we are measuring ourselves against is the outcomes of the current site – not the features that make it up.