On Delivery, Product, Value, and Their Relationship With Clients and Customers

So often I go onto projects that are floundering because basic errors have been made in team structures. This is simply because often people put into non-technical roles lack the holistic view and deep technical expertise of how whole systems behave.

The view of these roles is often that they are just about maintaining and updating spreadsheets of how progress is to be tracked against timelines - which is arguably one of the largest wastes of resources when a project is late.

An example of a very standard mistake: (because the negative outcomes follow a priori) If you organize teams by their skill set (e.g., mobile and backend), you are very likely making these errors. Hopefully that triggers you to read on rather than clock off.

What is value?

Nobody gets any points for doing a service design, agreeing on a scope, creating pretty UX mockups, talking to customers, or meeting a deadline. Nobody cares if development has ‘dev done’ a piece of work.

At the end of the day, the fundamental thing that matters is whether customers are willing to pay the client for something of value. That means producing something for customers to use. Everything else doesn’t matter until that relationship is in place.

Everything else is a variable cost that we can play with. It delivers no value in and of itself and represents a liability—right up until the point where all that hard work is converted into throughput via some form of sale. The subject here is: what can we vary? How should we vary it? And what do we expect to gain from doing so? The answer is that we stand to gain far more value from less cost, and if we get good at this, then we can start to charge based on value rather than time and materials—which is your only option if you are ignorant of this stuff.

“I don’t work in a company that has financial transactions”—fine, it’s harder (more indirect) for you, but at the end of the day, you have a budget that comes from somewhere by meeting certain obligations. If you cannot tie both the work you deliver to your customers and what they do with it to those obligations, then there are a ton of improvements that can happen—because it is always possible. The only case where it is not possible is when you only exist because you are somebody’s pet project and will be culled when money gets tight for them (I have experienced this in startups that fail to get a customer).

This is very simple—does not mean it is easy. The less effort expended in understanding this relationship, the harder it is to make decisions to maximize this relationship and grow. And so the harder it is to demand the appropriate levels of investment to grow.

I would argue that the purpose of delivery and, to a large extent, product is to create a strong mapping and relationship between what is delivered, its actual value, and the cost of doing so. None of these things are fixed costs; they represent curves over time—and different shaped curves demand very different approaches.

So what is value? It is the delivery of something that someone is willing to transact for—cost is everything expended up until that point.

We want to maximize value and manage cost to produce a strategy for growth—not survival.

So let’s build up some models.

The simplest model

This is pretty much the simplest model I can think of. It’s a single team that decides to take a request, do some work, and release it for customers.

What we are missing in this is the transaction feeding back into the start of the system. Let’s add that.

That got more complicated quickly! Don’t worry, most of the time we can forget about most of this diagram while we do our homework properly - when we are wrong we have to come back to it and question the arrows in order to debug what went wrong. That said, in this post we won’t do that as it got long! The next will get back to the team structure question.

The word “external” here simply indicates something that is outside of the current conception of the system. For example, I have worked for startups that claimed they want to take investment and scale but when that point came they refused. It turns out that the driving motivator was not growth - it was simply not having a boss. If I had identified this earlier, I would’ve changed my investment strategy (time) into the system as it significantly changes the target scale. It was an expensive lesson.

Some points:

1. The customer is willing to invest in the client only so long as the cost of doing so and consuming the product aligns with what they get out of the product.
2. The client is only willing to invest in the product so long as the cost of doing so aligns with the rate of client investment in order to achieve their external goals.

I think point 1 maps more onto being managed predominantly by product thinking whereas 2 maps more onto delivery responsibilities. Therefore, both roles overlap greatly when it comes to the “identify problem, solution, and then build something” space. I would not die on a hill defending that distinction.

However, this identify problem, solution, and build space is also the space of engineering.

So why does this bottom box matter so much?

This loop determines the rest of the business’s strategy:

1. It is where client investment is poured into, the lifeblood of a team that builds things for people. It is the major point of cost from this perspective. There are many other perspectives where the client is also investing - marketing being a huge example, but we are deliberately abstracting away.
2. It is also the point of value creation because its output is what the customer consumes in order to achieve their ends.

Therefore, that bottom box is the box that consumes client wealth (as in investment into this work reduces their ability to invest elsewhere) in order to increase customer wealth (customer can now achieve ends better) in such a way that eventually induces the customer to invest in the client.

It is the part of the loop that fuels either a feedback loop, which makes marketing highly lucrative, or fuels attrition, which for the same fixed cost of marketing delivers a completely different value over time curve and indexes the business into an acquisition rather than retention strategy.

To Produce Value, We Need to Be Connected to Value

If the team that is solving, building, and producing has no access to these external ends, then there is no possible way for them to make judgments about what is valuable. The cost of this is either large program failure or stupendous amounts of wasted time and money.

I see a pattern a lot that terrifies me because it conveys to me an ignorance of these kinds of systems by decision-makers. I regularly see ‘observability’ or ‘operating as a service’ that can ‘support’ customers is a ‘fast follow’ or something you add to the system after release. You are playing a very different game to me.

Hopefully, the diagram above shows that the entire system should be designed from the ground up for enabling customer interactions with the client to be translated into meaningful decisions in the future - that is the entire purpose of what is being done. In the systems that terrify me, the lowest bar for this is not difficult or expensive to do - I am more than happy to discuss this with anyone.

Every single customer interaction is an opportunity for investment creation with the client from the customer. Ironically, you do not see this problem in small (aka living on a shoestring - or maybe it’s because if they get it wrong, they are gone) organizations because the people building are the people supporting, or they are so desperate for every single customer interaction for the information. As a result, it gets designed to not need support - or they will pivot to another model that achieves this. Equally, everyone is waiting for customer interactions because it will finally give them real data on what is happening, so all the observability is built in - because there will be a bottle of champagne to open. This is why banks like Starling or Monzo are decimating high street banking.

It is large organizations with many layers between the people who are paying and the people who are building that get confused. These organizations do these things as ‘fast-follows’ for observability, logging, customer support, etc., that not only decimate their own ability to justify and grow themselves but also produce terrible customer experience and so unknowable customer-client interactions (until the client’s call center overflows). It is tragic that people can get so confused by the layers of management that they miss the forest of meaning and then institutionalize into thinking not only this is normal but it is good - because that is how the last engagement was done.

They get confused because they become obsessed with managing and producing a thing - but that ‘thing’ is used by customers who have complex relationships of their own, and that thing only has meaning and value in those contexts. If we do not build a ‘thing’ that helps us capture and understand that, then we have missed the entire objective of the client.

That is why these things terrify me; it is because it is possible to work alongside very bright, well-meaning people who do very similar actions but for completely different reasons. It all looks very similar until decisions suddenly veer off a cliff, and we end up with team structures that map onto building things not onto understanding and maximizing value.

Every single penny spent on solving, building, and producing should be relatable to some hypothesis of how customers will derive value + what that derivation of value means for customers' future investment into the client.

If we do not know these things then - seriously - why on earth are we taking investment from clients to build things for customers? It can only be selfish / contractual, and the client is ignorant enough to not ask for these answers. It is fundamentally disingenuous and from my perspective represents some kind of moral prerogative.

To state this in a more utilitarian way - much like (as above) if customer experience is bad then it converts a business strategy from retention to acquisition then from the perspective of an organization who gets paid by clients (even if you are an IT dept this is true) then, it is far more effective to enable that client to grow and be able to increase its investment than do a thing and then find a new client.

I want to not only deliver value for customers but also to work with clients to help show them how these integrated well-designed systems help them make better investment decisions because it better enables me to make better decisions with them.

Not doing this is an incredibly short-sighted strategy that identifies people as people who think the valuable part of what they do is simply building ‘things’ for clients without understanding the ecosystem of customer-client relationships and the pivotal role they occupy in influencing the investment strategy of those customers and so, by inference, the client.

If the teams solving, building, and producing do not understand these interactions, they are living in fantasy land. I see many fantasy land deliveries.

Delivery model determines business strategy

Simple failures in delivery and team structures - because they are on the bottleneck of value delivery to the businesses customers - are actually catastrophic for the businesses growth prospects. Next post will focus on the team structures - it had to be stripped out of here because of size.

As a result of the above, you would expect delivery managers to be trained and experts in all this stuff. But they are not, too often they are the people maintaining spreadsheets and arguing about costs to clients without being armed with any information about value. It is a disservice to both them and the client.