You build it, you run it

What are the limits of “run it”? Fixing bugs, yes. Monitoring capacity and performance? Probably. Answering user queries? Depends…

Let’s say our team builds (and runs) a mobile app for a shoe retailer. If the app breaks, we fix it. If a marketing video suddenly goes viral and causes way more traffic than anyone expected and uncovers some previously unknown bottleneck, we get in there and alleviate it, if we can. If the merchandising team can’t update details of some new line of Converse, do we help them? How about when a customer can’t update their payment card?

What I’m saying is, there are probably limits. And somewhere along the line, there’s an end to what we consider “running it”. And… I think that’s unhelpful.

I’m not saying a team that looks after a mobile app should be dealing with every customer service query – clearly that would be ridiculously expensive and not provide a good outcome. (Staying calm when being shouted at by some frustrated person whose shoes haven’t turned up in time for a special event is not a skill everyone has.) I am saying it’s Our Business to know what’s going on at the sharp end of customer service.

Our product is the end-to-end experience. And that means understanding our users, and the impact designing and engineering a digital product has on how their day is going. And we can get some great insight from our colleagues who mostly talk to them when things are going wrong.

We don’t “run it” – we run the digital part of a complex system, a bigger part of which is made of humans, and all of which can be made better or worse by us. If we lose sight of that we risk getting a little big for our boots, a little siloed, and a little detached from what it means to serve our users and provide value to our business.