3 August 2021
How to Change the World
by Doug Alcorn
I want to talk about changing the world. While I would like to talk about reducing poverty, suffering, and violence while increasing love, empathy, and joy, those aren’t things we get to work on at Gaslight very often. Still, I believe we change the world with each project we take on. One of my favorite books is User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton. He makes this wonderful, perspective-shifting claim in the first few pages of the book:
The goal of product development isn’t to make products. The goal is to change the world.
Too often we talk about “the system should do …” or “when I click on this it should …”. I want us to talk about the small and not-so-small ways technology can change the world for people who use it. If we’re not solving some real-world problems for real people we’re wasting time and money.
I would highly recommend everyone involved in the process of building and maintaining software products read Jeff Patton’s book, not just developers and designers. Here’s what has stuck with me.
How do we begin changing the world?
Here’s a simple way to start making change. Think about the situation now and later. Right now, there’s a group of people who are confused, frustrated, or upset about something, presumably about the same thing. What could we do to make their lives better? That piece, the what-we-do-to-improve-their-lives bit, is our output. Later, those same people will use something we’ve built, our output, and their lives will be different. Some will be happy with the change and some not. Either way, we’ve changed their world.
We have ideas about what our output should be—what we can do to change their world. Sometimes we call these ideas “requirements”, “features”, or “enhancements.” But, really, they are just guesses at how to make these people happy. We won’t know for sure until we build it and see how their world changes. We take those ideas, go through a process to implement them, and then see how their world is different because of what we built, good or bad. And if bad, hopefully, we get the opportunity to make it better.
It isn’t about what we build
What we have to remember is that what makes them happy isn’t actually the software itself. What they are happy about is that their problem has been solved. Short of maybe video games, rarely does anyone enjoy the software. They enjoy what it does for them. The result of what the software does for them is called an outcome.
We measure outcomes, not in lines of code written, features delivered to production, or even capabilities the person can do. We measure outcomes in terms of what people actually do differently and whether we’ve made their lives better.
When we talk about and build features, we want to understand who the feature is for. What do they do now and how things will change for them later? That change is what we’re really after.
It’s not just about people
I know, I just wrote a lot of words stating that our goal is to make people’s lives better, and while that holds true, our goal is two-fold. There is also a business involved in this equation. And as a company, as well as our clients’ company, if we don’t stay healthy we won’t be around to help people anymore. Ultimately, we believe that helping customers get what they want will enable us to get what we want. I might call that selfish altruism.
There’s a game we like to play called “Popping the Why Stack.” It starts like this: someone suggests we could do X. The immediate question is, “Why?” And usually, there’s a pretty good reason that follows. But here’s where it gets fun. Ask “Why?” again—and again. Ultimately, because we’re a business and our clients are too, the answer should come down to:
- It will increase our revenue (or expand market share)
- It will decrease our cost
- It will protect our market share (or reduce risk)
So, in addition to the people whose lives we’re trying to change, there are people within our organization who are also disappointed or unhappy with something. And while we’re building products for our customers that will hopefully improve their lives, we have to also consider how those products improve our organization. That is the impact of the outcomes we achieve. We can observe the outcomes relatively quickly, but the impact takes time to achieve.
Less is More
Here’s another Jeff Patton quote I use at least once a week:
There’s always more to build than time or money allows – always.
One of the things we try to do at Gaslight is focused on the efficiency and effectiveness, or how quickly we can deliver value, of development. The better we are at our craft and the better tools we choose, the faster we are at building features and products. But that is a game of diminishing returns.
No matter how good or fast you are, there is always more to build than time and money allow—always. So really, we are in the business of deciding what to say “no” to. We need to minimize our output and maximize our outcomes and impact. What things can we do that will most dramatically affect outcomes and impact? What things only modestly so?
The word we all roll our eyes at
Ultimately all these ideas, experiments, features, and products end up as “requirements.” It’s such an overpowering word. Here are the requirements. They are required. If you don’t do everything that is required, you haven’t finished the work.
Here’s what my experience has shown: If you build a fraction of what you think is required, you can still make people happy. I don’t like to get too hung up on requirements. I like for us all to have discussions that produce a shared understanding of what we’re trying to accomplish that leads to agreements on what to build. We’re not really here to build products, write software, or satisfy requirements. We’re here to change the world.
If you haven’t read Jeff’s book, User Story Mapping: Discover the Whole Story, Build the Right Product, I highly recommend it. Jeff is known for developing and advocating user story mapping, so it makes sense he named his book after it. I think the title is misleading, though. It sounds obscure and technical. I think I would have given it the title The Best Way to Build Software Products. That properly sets the stage for people new to product development.
