12th December, 2021
Week 50/52
Swiss Bobsled team racing at PyongChang Winter Olympics, 2018, photo by me.
This is week 50 of this mad project … three to go!
Up until now I’ve included this note in the footer each week:
Top Three is a weekly collection of things I notice in 2021. I’m writing it for myself, and will include a lot of half-formed work-in-progress, but please feel free to follow along and share it if it’s interesting to you.
But, that wasn’t entirely honest.
I started the year with ~120 drafts, some of which had been unpublished and living rent free in my head for many years. It’s been so good to finally get these out into the world. I’m delighted that people have found them interesting. I have enjoyed the feedback - please keep it coming.
As I’ve mentioned already a couple of times, I’m publishing updated versions of all of the posts that are evergreen on RowanSimpson.com. I have 38 essays there now, and more coming soon.
Here are some links to those that have been published in the last week:
Leap of Faith
It’s important that we don’t confuse risk with uncertaintyGetting Lucky
How do we break luck down into its component parts, so we can create luck for ourselves and for others…Tyranny of Distance
New Zealand is often condescendingly described as a small island a long way from anywhere. Is it, though?Machines & Phases
There are so many different ways to measure a startup. It’s easy to drown in metrics. How do we know what we should focus on?Compensate
A startup that goes well can be very rewarding. How do we ensure that everybody involved gets their fair share?
Please have a read and share them with anybody who you think might find them useful.
I have a handful of drafts remaining, so this is my plan: for the next two weeks I will try and mop up those (Top Three is more accurately Top Four this week, maybe even more next week, depending how many I can get to). And then we will conclude finally on Boxing Day by looking backwards and forwards…
🍂 Fall
Having users invariably makes us wrong. Then, hopefully, it makes us humble.
Anybody building software usually starts with the same goal, more-or-less. We all want to have lots of happy users.1
And yet, most software is terrible - it's complicated; it's unreliable; it's bloated with options and settings, which often feel like a long list of secret handshakes that we'll never learn.
It's actually even worse than that: because we're so rarely in the room with those people who are using the software we build, mostly these frustrations are invisible and overlooked, if not completely ignored.
We need to aim higher. The challenge isn't to make it possible for users to be successful. The goal is to make that the default. Or, in the very least, by far and away the majority outcome.
This requires humility and empathy.2
Getting to the Third User
There is a pattern in software development that I’ve seen repeated so many times now that I think it’s worth codifying:
Imagine we are observing the first usability test on some software we have built.3
The first user to try it out completely misses the seemingly obvious cues in the user interface. The button they need to tap might well be big and red and flashing with a marching ants border, but they just don’t see it.4
“Dumb user” everybody thinks.
The second user also quickly ends up hopelessly lost.
“Two stupid users in a row … what are the odds?”
The third user. Same story.
At this point, we're all hopefully slapping our foreheads and thinking “how could we do this better?”
The key is getting to the third user. Until then we haven’t really learnt anything.
This exact same pattern applies to bug reporting, once the software we’ve built is out in the wild - the first alert is probably random noise, the second is annoying, the third is a sign that there are actually two problems: something is wrong with the software and something is wrong with the person who ignored the first two warnings!
Rather than treating testing as validation, we need to have the mindset that we’re likely wrong and that users can teach us how to be less wrong.
The Pit of Success
People are complex. It's easy to say we just need to imagine being in their shoes, or watch them while they use our software, or be more mindful of errors that are reported. But actually we need to get in their heads and try to understand their context. We need to be aware of the other tools they currently use and are more familiar with that will inform how they expect our new thing will work.
That’s really hard work.
It’s commonly forgotten, as we get carried away by the buzz of building something new, and get sucked into the challenges and complications involved in the engineering and construction.
Our goal should be to build a "pit of success"5 - a hole that people will just immediately fall into without even having to think about it (ideally without even realising it) and which leads them in the correct direction. We need to make this the path of least resistance, like a bobsled track - once we get users moving they should gather momentum and slide on down!
(If we see users repeatedly taking a different route then we should pay attention to that, rather than putting up fences to stop them going that way - sometimes desire paths reveal a different and better product).
If we don't have happy users, it's not their fault. It's our fault. We didn't make it easy enough. We can do better.
It's not what the software does, it's what the user does that matters.
Perhaps, as a start, it would help to more often think of our users as real people...
🏟 Visualise
I love the buzz of a big crowd.
It's exciting to soak up the atmosphere created when lots of people are all in the same physical space at the same time.
For those lucky enough to be the band, or sports team or keynote speaker who are the focus of a crowds attention, that is quite powerful.
(Or terrifying, I suppose, depending on their mood!)
When lots of people are in the same place at the same time it's easy to visualise crowd sizes. But when we're working on a product, especially a software product, it's much harder to get feedback like this. Our customers are everywhere and nowhere, so we have to work harder to have them in mind.
One technique that's useful is to go back, in our minds, to real crowds.
For example, imagine we're working on a tool that has 2,000 people using it. This is approximately equivalent to the number of people who fit into the Kiri Te Kanawa Theatre at the Aotea Center in Auckland, when it's full. Imagine that many people all in one space together, and the noise and activity they generate. Having this crowd in mind can change the way that we think about the people who are using the features we build.
A common mistake in product teams is to dismiss a subset of the potential customer base, because they only represent a small percentage of the overall audience. But, again, it can help to imagine these people as a distinct group.
For example, when considering accessibility, we can imagine all of the impacted customers together in one space - those who struggle to read small fonts, or who are colour blind (or completely blind), or those still using an older device. How would we explain our design decisions to them, in person? Perhaps on a percentage basis they don't seem significant, and so are too easily overlooked, but it's more difficult to imagine standing in front of them and telling them to their face that they don't matter.
Or, when planning upgrades, if we don't think it's a big deal for things to stop working or for the website to be offline while we make changes, think of all of the people who will be trying to access the service during that time, and imagine what it would feel like to have them all in the room while we flick the switch. No matter how small that number, it would probably feel like a lot of people. And we might be motivated to get the service back up more quickly if they were all standing behind us impatiently looking over our shoulder.
We can use this technique to put any audience size in perspective.
It's amazing the difference it makes when we start thinking of our users as real people.
For example…
2 people = your parents!
5 people = a car full
15 people = the members of a rugby team
30 people = the students in a school class
80 people = passengers on a full bus (seated and standing)
120 people = a parliament full of MPs
340 people = all of the passengers on a Boeing 777
675 people = capacity of ASB Theatre in Auckland 6
1,350 people = all of the passengers on an Interislander ferry
2,400 people = seated capacity at Civic Theatre in Auckland
3,600 people = capacity of TSB Arena in Wellington (seated)
6,000 people = capacity of the TSB Arena in Wellington (standing)
12,000 people = capacity of the Spark Arena in Auckland
35,000 people = capacity of Sky Stadium in Wellington
60,000 people = capacity of Eden Park in Auckland
100,000 people = capacity of MCG in Melbourne, Australia
250,000 people = capacity of St Peter's Square in Rome
500,000 people = the entire population of greater Wellington region
When the numbers get bigger than that, we need different techniques!
🗄 Categorise
Those of us who work on technology startups often like to spend our time talking to other people who are themselves working on startups. That makes sense. It’s often a lonely experience, and it can help to share that with others who empathise.
These are easy conversations.
However, technology startups are a broad church. There is a lot of noise to try and filter out in order to get to the signal. Perhaps there are better ways to categorise ourselves that would be more useful.
Working with the Timely team unlocked this idea for me...
In the beginning we incorrectly categorised ourselves as a technology company targeting customers in the health and beauty industry.
But eventually we realised we were ourselves part of the health and beauty industry and that our product was technology services.7
This might seems a subtle difference, but it resulted in a big change in how we positioned our product, how we spent our time, and who we spent it with.
Rather than talking mostly to other technology people in very different sectors, we prioritised talking to our peers in the health and beauty sector. We found we had a lot more to learn from them.
Rather than describing the technology and the features, we switched to focusing on the problems we were hoping to solve for our customers and talking about our solution using language and a style that was more familiar to them.
Rather than talking with other startup founders who were the same age and stage as us, we tried to connect with those who understood the most about the customers we were trying to reach. Some of them were self-employed. Some of them were working in much larger businesses. Some of them became customers themselves or referred others. Some of them later join our team and became employees (or board members!)
These are hard conversations.
When we do this we are no longer preaching to the choir. We are exposed to different people who will challenge our thinking. However, hopefully this helps us to better understand the customers we're hoping to serve.
It's useful to ask: should we categorise ourselves based on the conversations that are comfortable and easy or uncomfortable and hard?
(This can cut both ways: I've also seen examples of startups where the founders have a deep network in the specific sector they are working in, who never break out of that bubble and connect with other startup founders who could help them quickly understand some of the specific challenges with operating at that age and stage of the business. As is so often the case, the optimal answer is: a bit of both!)
This is what I mean when I say there is no such thing as a technology sector.
It's 2021. Technology impacts every sector. Categorising ourselves on that basis isn't especially useful anymore. The fact that we have engineers and designers on our payroll shouldn't be the most interesting thing about our companies.8
We don't call our local cafe an electricity company, just because that's how they power their coffee machines.
When we work on a technology startup we need to think about what sector our customers are in and then lean into the hard conversations that will, over time, make us part of that sector.
🎼 Compose
I hope we passed the audition
I spent 8 hours watching The Beatles: Get Back documentary, and loved every minute. If you haven’t seen it yet I cannot recommend it enough.
It is a long fly-on-the-wall view of the making of Let It Be, originally filmed over a month in 1970. The footage has been restored so that it really feels like we’re in the room at the moment when songs that have become iconic in the 50 years since were created.
For example, this short clip has been widely shared on social media, showing the moment when Paul McCartney first settled on the melody of Get Back, which was the first single from the album:
As the tweet notes, just 45 seconds from nothing to a hit single.
But, was it really?
Let’s think of some of the components that are easily overlooked…
Paul doesn’t start from nothing.
By 1970 he’d personally spent half his life working on his songwriting craft and countless hours practising and performing. And during that time he’d had the benefit of bouncing off two other great songwriters (John and George) who no doubt pushed him into areas he might not have discovered on his own.
It’s maybe not obvious, but there is a huge amount of muscle memory in the process he’s using to try and find this melody.
There is a lot more to a hit than a hook.
At the end of this clip they definitely don’t have a song yet, let alone a single. There is a tune that we now recognise, and the beginnings of some lyrics, but even in the remaining hours of the documentary they show the band rehearsing and iterating and improving and polishing this many times before they capture a version on tape they are happy to share with the world.
Even this epic documentary is only a subset, edited down from 57 hours of original footage and 150+ hours of audio, including 60 different takes of this particular song - they recorded 10 takes with Billy Preston on January 23rd, another 14 takes on January 27th and several more the following day, when they added a new ending (this was added to the best take from the previous day to create the single version).9
It’s easy to think that the important moment is a magic spark, but it’s actually the long grind.
Last but not least…
It’s not a one man band.
At the beginning of this clip George is yawning and Ringo is half asleep. But they both have an important role to play.
Around the 90 second mark George interrupts to give Paul some feedback and encouragement:
Yeah, it’s good. You know, musically, it’s great.
Prompted by that Ringo starts to tap his foot and clap in time with Paul, experimenting with different rhythms, and in the process moving one step closer to the song we recognise.
There is a huge amount of patience involved in this process, and willingness to sit gently with something that is imperfect and unfinished (see: Being Spartan with Ideas). We should all be so lucky to have collaborators like that who turn up and make things better, even though they won’t even share the songwriting credits.
Anyway, another great example of three myths that we’ve talked about here this year: the myth of the magic spark, the myth of the lone genius and the myth of overnight success.
Noting, via Jimmy Gutterman, that there are only two types of vendors who refer to their customers as "users": those who sell software and those who sell illegal drugs.
At Trade Me we stumbled into calling people who used our software “members” who were part of the “community” of buyers and sellers. Unfortunately not every product has such a tidy alternative, but it’s worth taking the time to think about the labels we use within our product teams to describe the people who will eventually use what we’re making - hopefully to do great things.
Recall what I wrote a couple of weeks ago:
When we're putting together a team to work on a new product there are two types of people we need: some who are heads down and some who are heads up.
…
Some people start with the technology and ask “How does this work, on the inside?”
…
Others start with the technology too, but they have a different question: "How do people use this?"
Over the years the book I've most often recommended to anybody building a software product is Don't Make Me Think by Steve Krug. It's pretty dated now (it was originally published way back in 2000, although there is a revised edition from 2013), so most of the examples are throw backs to a previous era of web design, but it is still worth reading just for the simple explanation of usability testing.
Anybody who has worked with me on UI design will be familiar with my sarcastic request for a marching ants border, as a cynical reminder that just making things more obvious to us isn't always the solution.
I believe the “pit of success” was first described by Rico Mariani at Microsoft (see the reference in this old blog post by Brad Abrams), but I first discovered it via Jeff Atwood: Falling into the pit of success
Alternatively, the number of civilians packed onto US Airforce C-17, when evacuated from Kabul earlier this year
See: Ryan Baker on Twitter
Although, if you have no engineers or designers on your payroll that is increasingly remarkable, and not in a good way. If that's true for your team it's probably a reason to pause and think a bit harder.