Infrastructure: it’s different (except when it isn’t)

A wise woman once defined product management as ‘a strong view, softly held’. It really resonated with me at the time, and is a pretty good summary of my approach to product management, these blog posts and, to be honest, to as much of my life as I’m mature and patient enough to manage.

The whole point of the ‘softly held’ part of that is, for me, about being open to challenge, new ideas, or different perspectives. Which is all to say, basically, if you disagree, I am so up for a chat about anything in this post, or any of my others. You can usually find me on twitter.

So, with that in mind, let’s get down to business.

When I joined my current team, I was new to government, data, digital, and agile. I knew a bit about all those things and a bunch of theory, and after 7 years in academic publishing (a subject for a different post, or maybe a chat in the pub), a job at an organisation focused on user needs and making things open seemed like an absolute tonic.

For my first couple of months though, I was often lost. Like lots of imposter-phenomenon-havers, I initially blamed myself. I was learning too slow, or missing things I shouldn’t be. I can’t tell you how relieved I was when someone in the team eventually said “this product is really hard. It’s very complex”, and everyone else nodded emphatically.

Now, though, that feels like a cop-out.

With infrastructure products, the technical complexity isn’t the problem/ Not really. The real problem is the abstraction from end-users, and that problem is actually made a bit worse by being in an organisation that champions the user need (although its ability to inspect and adapt soon fixes that).

Without realising it, we were trying really hard to make stories about database performance and schema evolution into things our users cared about at all, or cared about but wouldn’t articulate the need at the level we were working.

But here’s another thing about infrastructure: users only notice it if it’s broken.

These analogies are tired, but illustrative all the same: how often on a long car journey do you remark, out loud or even in your head, “this road is fine”. I’ll bet it’s never. You’d definitely mention it if the road surface was terrible, or the signage unclear, but if everything was just good enough, it wouldn’t be on your radar.

Similarly, if you’ve been driving the same bit of dodgy road every day for months and it finally gets resurfaced, or has new markings painted, or some fresh signs, you’ll notice it. But you’ll also normalise it pretty soon as just another part of your daily commute. Infrastructure is furniture. The novelty wears off, but that doesn’t mean it isn’t working as it should do. This is why, if infrastructure does manage to be delightful, it only manages it in the short term after it replaces something totally missing or generally terrible, and then it fades into the background. And that’s exactly as it should be.

This also adds a layer of abstraction to user research input for infrastructure products. Users are quite unlikely to say “I’d like this file to have provable and in-built metadata”, but they might say “when I download a file, I need to be able to know and check where it came from, and when”.

Similarly, users probably won’t say “I’d like pagination to be performant, I don’t want the page to index an entire large dataset on the fly” but they might say “I expect all the data to be available to me in real time, on demand”.

This can get frustrating for teams building infrastructure because often, there are two options available to us: meet the immediate and specific need a user has now, or make sure what you’re building at the lower layers doesn’t rule out the thing they need right now. That means that we have to have quite a good idea of things which are on the same plane and can be met with a single low level change, or lots of smaller higher level changes. We can either shift something in the foundations, or make it look like we’ve shifted something in the foundations when you look at the roof.

It’s a balance, and a tricky one. To go back to my (uncharacteristically*) dull analogy, if no roads could be opened for use until all the roads were built, the delay on return on investment or value for users would be intolerable. But if the first ever road was opened and just ran from Oxford to Cambridge and didn’t have any signs, nobody would bother even buying a car, let alone inventing the bus. You don’t get the innovation without investing in the infrastructure. Just ask anyone working on electric cars.

the availability of public charging infrastructure is crucial, and it is a problem that many countries have yet to solve.
Currently, electric cars still outnumber public charging stations by more than six to one. While the number of public chargers has grown significantly in the last five years, more are needed.

Building something to be agnostic of use case can, therefore, feel a bit thankless sometimes. Instead of that juicy payoff of users loving your thing, you get to confirm you haven’t ruled out a need being met down the line.

The good news is, there are things you can do to make this better, and the even better news is that none of them are new ideas. You’re probably doing them already.

Be open about the tension

My team started plotting pieces of work on a scale from ‘user needs today’ to ‘infrastructure for tomorrow’. We knew we needed to do both, and this process kept us honest and made us think harder about value and trade-off.

A classic (and my personal fave): start with the problem you’re trying to solve

It may not always be especially delightful, but solving a problem that real people have (even if it’s a boring one) generates as many good feels as creating something brand new they never knew they needed.

Don’t give up on user centred design

This one is a biggie. User centred design is still the best (only) place to start, and the best assumption-challenging, course-correcting value generator I know. I won’t go on because other people have already said it all, particularly here, and here.

Find your users

That analogy, one last time. So, nobody is going to be waxing lyrical or tweeting about your squarely 9/10 absolutely fine entirely fit for purpose road anytime soon, but there will be users who are so thrilled, and who will see and love the transformative power of what you’ve done. People who drive for a living, local businesses, town planners, emergency services. Find your users and delight them.

With infrastructure, you’re often helping users who are trying to make things better for their users, but transformation can only be as fast and effective as the infrastructure will allow.

*ask my team about the 90 minute roadmapping kick-off I ran referring to data as hot lava throughout, through a series of analogies and including quite a lot of basic geology and some Sonic the Hedgehog references. Analogies are my thing.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.