Nothing New

the continued rise of customer centered development

Someone posted a comment on an old blog post this week (the old blog - not the old old blog). It’s a post from 2012 called The Rise of the Customer which (in short) is about how we (as developers) need to stop building what we (still developers) think is cool and interesting and instead, figure out what our customers need instead.

I wonder if 12 years later if we’ve learned anything since then.

But but…

Two things I always have to call out when I stress the importance of building what the customers need instead of what we think they need.

First is good old Modern Testing (Delivery) Principle #5:

We believe that the customer is the only one capable to judge and evaluate the quality of our product.

This doesn’t mean that we “make the customers do our testing” - but it means that we collect usage data and prioritize fast feedback loops so we can make better guesses what the customers want.

Second call out is the inevitable reference to the quote that may or may not be from Henry Ford:

“If I had asked people what they wanted, they would have said faster horses.”

…it’s debatable of whether he actually said that, but if he did, he’s an idiot. Product delivery - whether it’s a car or a an app requires that we understand what the problems or pain points are. People don’t want software, they want their problem solved. People didn’t want faster horses - they wanted a way to get from point A to point B more quickly, and to stay dry in the rain. One solution would be a faster hourse in a huge umbrella - another solution is an automobile.

DORA 2023

Coincidentally, I’ve. been reading and re-reading the output of the 2023 State of DevOps Report - which shows (among other things) that teams that focus on the user have higher organizational performance. Worth noting that most teams would say they care about the user, but the study focused on questions around listening to customers and prioritizing work based on feedback. I’ve talked for many years about “Field of Dreams” development, where teams build something, and then wait for the users to come and use it (“build it and they will come”). This approach may work for a baseball field in the middle of a corn field, but it fails on consumer projects.

I was then happy to see this callout to Platform Engineering in the section on user-centric development.

Platform engineering teams might adopt a “build it and they will come” approach to building out a platform. A more successful approach might be in treating developers as users of their platform. This shift in focus requires platform engineering teams to understand how developers work today to successfully identify and eliminate areas of friction. Teams can use the software delivery and operational performance measures as signals to monitor whether platform efforts are helping teams achieve better results.

I’ve seen Platform Engineering (or DevX, or DevOps, or …) teams do this wrong too many times. Whether it’s a bespoke workflow automation tool that’s difficult to use, a custom CI solution written in F-sharp, or a bug database written in Visual Basic (I made this last mistake myself in 1993), it’s inexcusable for an internally focused software team to not have a user-centric approach. Your customers are sitting next to you! (or are at least in the address book).

User-Centric

So - how does a platform team become more user-centric? It doesn’t mean that you do every thing that your developers ask - they may ask for dumb things. I have been asked to build a lot of dumb things in my career, and I’ve managed to actually build almost none of them. A user-centric (or customer-centric) approach is to get past the request and focus on the problem that needs to be solved. A colleage (Jim Moore), when presented with “interesting” requests used to famously ask, “Imagine you had all of that today. What would you do with it?” That was a fantastic shortcut to figuring out what people actually wanted to do (rather than imposing their solution).

Bad Ass

Badass: Making Users Awesome by Kathy Sierra focuses on the idea that successful products or services are not just about making users love the product, but about making the users feel more competent and capable in the context in which they use the product. It’s so good, and so relevant that it’s one of the few books I keep in arms reach on a small desktop bookshelf.

The points in Badass are highly relevant for platform engineering teams. The point of platform engineering teams is, largely, to accelerate development teams by making sure that development teams have the tools and knowledge necessary in order to achieve their goals efficiently and consistently. Emphasis on continuous skill development, reducing cognitive load, and maintaining user flow ensures that internal tools and platforms are not just functional but also intuitive and easy to master. By prioritizing user-centric design and feedback, platform engineering teams can create tools that evolve with the needs of the organization, ensuring long-term sustainability and alignment with business goals.

An Observation and a Question

I think the DORA report this year may be the most insightful version I’ve ever read. I love seeing the emphasis on user-centric approaches and the callout for internal teams to embrace this approach. Add to that the resurfacing of a 12 year old blog post, and it’s a blast of serendipity that made my week.

But I have to ask…twelve years after that post, why isn’t the software industry better at focusing on the customer? I feel like it’s lip service from everyone, but action by few. A previous employer had a company value of “Users First” - but took action after action to screw their users. Other companies (and internal teams) build things that they think are cool - and then blame the customer for not adopting their changes. I just think that more organizations should be better at putting solving customer problems at the center of their planning. Am I wrong?

Certainly a lot to think about. I, of course, have ideas, but those will have to wait for another day.

-A