“We’ve run out of money.” That was the cold, hard truth. It was July, 2006, and I was working to launch Naked Bus, my new startup, in three months. I’d put all my money and effort into it. My then future wife, who totally believed in me, had lent me much of her life savings as well.
We were building the entire IT system that we needed to run the business. And the developers were telling me that there wasn’t enough time or money to complete all the requirements.
I looked at what I had asked the developers to do – the requirements – they were all necessary, which was why they were called requirements.
Should I cut some features? If I did, the system would be incomplete. I needed everything for the business to work. I had already cut everything that I didn’t need – the “nice to haves”
Should I try to raise more money? Should I delay the launch and miss the busy Summer period? That was unthinkable.
But I had run out of money.
And both options – delaying launch, or cutting features – looked impossible.
But I knew there had to be a way.
I looked at the requirements again.
One requirement was for customers to be able to change a booking. Plans change, and I knew that would be an important feature.
And then it struck me.
The ability to change bookings was important, but not before launch. Not many people would need to change a booking before the buses started running, and for those few who did, we could do it manually.
We could build that feature later, once the money started coming in.
As I thought about that, I realised that the change booking requirement wasn’t actually a requirement at launch. Which made me wonder what other “requirements” were not actually requirements.
I thought about the reporting function. We were using third party bus operators to provide the bus services, and we were sharing revenue with them, so we needed to know how much to pay them. I had designed reports that would provide that information. But I now realised we wouldn’t need these for more than a month after launch – until we were actually paying them.
That was another significant piece of development we could delay until after launch.
I went through the “requirements” with a fine tooth comb, and found several more examples.
I talked with the developers, who told me that if we cut out all those requirements, they could deliver on time and on budget.
And we did. We launched on time, with no change booking and no reporting. Every evening my partner and I would sit on the couch. I would read out the value of each booking and she would add them up on her phone. That was all the reporting we had for over a month.
But it worked. We carried 3 people on the first day. By the end of the first month, it took too long to add up all the day’s bookings and we were both hugely relieved when the reporting function went live.
What I learned during this process has been one of my most valuable lessons. Of course, I wasn’t the first person to discover this.
Let me take you back to the 19th Century. At this time, newspaper articles were written along the following lines: “The president left the White House around 11am. He performed this official duty and that, and then he went to dinner. After dinner, he went to the theatre, where a stranger came up to him. The stranger pulled out a gun and shot him in the head. The president was taken to the hospital, where he later died”.
Now, I think you would agree, the most important part, the crucial detail, is that the president was killed. But it is left until the end.
This narrative, or story telling style was common at the time. But the arrival of the telegraph changed all that. Instead of writing a story and sending it by messenger, which could take hours or even days, the journalist could send it by telegraph in a few minutes.
But there was a problem. The telegraph was not terribly reliable. The transmission could cut out half way through. Imagine what would have happened if the last sentence of the President’s story had been missed. The whole point of the story would have been lost.
So journalists started writing their stories differently. They started putting the most important piece of information first, followed by the second most important piece, and so on. It meant that, even if the unreliable telegraph broke down, the most important information would get through. This style of writing became known as “inverting the pyramid*” and is still how most newspaper articles are written.
The fact that the President had dinner was less important than the fact that he was killed. The ability to change a booking is less important than the ability to make a booking.
Inverting the pyramid can be applied to software development just as much as to journalism.
And it is just as crucial. If you build every feature that you can think of, the likelihood of failure is incredibly high. You have all heard of large software projects that failed. This is the reason why.
Dave McClure once said of software development: “a new feature is like sex; one mistake, and you’re supporting it for life”.
What that means is this: Everything you build, whether it is software, a machine or a house, needs to be maintained. That is expensive. So for that reason alone, you should only build what is really important.
Inverting the pyramid forces you to decide what is really important.
I believe that “inverting the pyramid” is a rule that we can use in almost any endeavour. Whether it is building a business, building a relationship, managing your career, or planning a holiday.
It forces you to answer the question: why are we doing this? What is important here?
Making a booking is more important than changing a booking. The president’s death is more important than his dinner.
As I had been designing the system for Naked Bus, I had thought about everything that I needed. But I hadn’t tried to figure out the most important things. Until I had to. I thought everything was necessary. Everything was a requirement. Until it wasn’t.
This is not a story about software. Nor is it a story about journalism. It is a story about what is important in what you do.
So, if you are bogged down with too many things to do, if you don’t know where to start, or you are running out of time, try inverting the pyramid. Figure out what is the most important thing and do that first. Figure out what is absolutely necessary, and do only that. When you have done that, you can worry about the other stuff.
This is what we did at Naked Bus, and what we do at ThinkLazy.
If you’d like to find out more about how we work, contact us at firstname.lastname@example.org or 021 324 441
*Thanks to Clarke Ching, a Kiwi agile expert for this analogy: for more, I thoroughly recommend “Rolling Rocks Downhill”