Hey there, it’s jolly good to see you again.
In my last piece, I talked about energy gradients. If you haven’t read that yet, you might be a bit lost with this one, so maybe go back and check it out.
Today, I’m talking about how embracing steep, rocky, unforgiving energy gradients helps you innovate.
First, two quick bites of news:
Got 5 minutes to record yourself thinking aloud as you read a web page? I often do this by recording a voice note on my phone and attaching the recording to an email reply. Basically, this approach. I’ve recently updated the landing page for Set Your First Pivot Triggers, my video that walks you step by step through figuring out and negotiating Pivot Triggers. I’m thinking about changing the way I explain this product, so I’d be very grateful to hear your thoughts as you read the page. When you’re ready to record, here’s the link.
In the spirit of Do 100 Thing (here’s our podcast episode about that idea), I’m gunning to publish 100 posts here (currently at 69) and 100 podcasts (currently at 45). My buddy Brian David Hall is embarking on making 100 email courses. Are you thinking of trying a Do 100 Thing type activity? Hit reply and tell me about it!
OK now let’s get chalked up and climb some energy gradients.
Follow the mountaineers
You’re reading this message via a company called Substack. It’s huge now, but did you know how it started?
The idea came to the founders when they noticed that Ben Thompson, author of the popular Stratechery newsletter1, had managed to cobble together different systems to set up his own subscriber-supported publication. For Ben to have done this, he had to have technical and business capabilities as well as great writing chops. Setting his business up had taken him significant knowledge, energy, patience and experimentation.
So Substack’s founders made a bet. They reckoned that if they could make it easier to set up a Stratechery-style newsletter, then a load of great writers would show up who had the desire but lacked the technical acumen.
They couldn’t estimate the size of their market in advance. Not many people were actively searching for what Substack ended up building. But the existence of a few pioneers like Ben Thompson was a great signal that there was something valuable there to explore, and the bet worked out for them.
Let’s look at the story of Substack in terms of energy gradients by visualising a rugged landscape full of folks pushing concrete wheels about.
In this metaphor, Ben Thompson is an intrepid mountaineer. He made the first ascent of a daunting cliff face, and then dragged his concrete wheel up there too.
Substack’s founders figured that, for Ben to put that much effort in, the top of that mountain must be a desirable spot. They figured that if they could decrease the energy gradient so it was more of a gentle stroll, then many more writers would make like Kate Bush and go runnin’ up that hill2.
What a great hack for innovating new business ideas!
If you can spot a handful of pioneers who’ve orienteered their way to the peak of a ghastly hill, you can bet that a large number of slightly less intrepid people would be keen if the climb were easier.
I spent lots of time with customers in all my roles over the past decade, and in every case I found a few people or teams who had put in outsized effort and “misused” pieces of software to get something to happen. This was often a helpful indicator of something valuable.
Sherpas first, engineering later
When they spot one of these opportunities, it’s tempting for a company that’s very good at optimising slopes to jump into planning how to build a fully optimised experience. This is going to take them a huge amount of time and effort, and it’s terribly easy to optimise far too many hills while still missing some of the hills that matter. You can’t know the nooks and crannies of a mountain by peering at it from miles away. You have to climb it. What’s more, you don’t want to be one of the many companies that failed because they optimised a hill that nobody wanted to go up.
So instead, start by personally assisting the first few potential customers to lug their concrete wheels up that sheer cliff face. This is a bit like you’re acting as their sherpa, sharing the journey and helping them carry the load. It’s still going to be quite a tough climb for those customers, but at least they won’t have to go it alone. They’ll have you as a guide, as well as safety in numbers.
An example of a company who took this approach is Maven, the cohort-based course company, who kinda followed the Substack playbook too. The founders noticed their own intrepid mountaineers: a handful of online teachers who’d put in a huge effort cobbling together different tools, systems and kluges so they could deliver cohort-based courses to paying customers.
The founders didn’t jump straight to building out the smooth and optimised systems they have today. Instead they cobbled together a set of tools and systems like those of the teachers they’d noticed. Then they put out the word that they were looking for a tiny group of early adopters to try setting up cohort based courses. Maven were straightforward with these first customers. This was an early attempt. It would be janky and inefficient. But Maven would provide guidance and help as they figured it out together (and things would then get smoother). The founders worked directly with those first customers, doing a heck of a lot of concrete wheel shoving by hand.
The early adopter cohort was a success, both in terms of customer results and in terms of how much the Maven team learned about what it really took to make the ascent. Over the next couple of years, they brought in progressively larger cohorts of keen teachers. Between each cohort, they could invest in building tools, systems and onboarding processes to shrink and smooth the energy gradients for customers and team members alike.
Crucially, there was no need for debates about features, requirements and deadlines. No MoSCoW or Impact/Effort prioritisation theatre. The team knew exactly which parts of the climb were toughest because they’d personally done them. They also had a strong incentive to make those toughest parts easier before the next cohort arrived to start their ascent. The team could optimise the energy gradients over many iterations, learning and adjusting every time.
3 reasons to do this kind of Hard Test
Maven did what I call a Hard Test:
A Hard Test is when you ship an ugly, tiny-scale, rough, hand-operated, cobbled-together version of Your Big Idea™ to at least one real customer.
There are three big reasons to do a Hard Test before optimising things:
You need to know that the promise your customers can see at the summit is worth some effort. For Maven, there was always a chance that not enough teachers would be bothered about setting up cohort based courses even if they were easier. However, Maven knew that if they could get a few teachers in by offering a service that was ever so slightly less gruelling, then they could feel more confident that they would get thousands of teachers later. They could keep working on the slopes over time, building confidence until it was worth the investment to install a metaphorical cable car and toilet facilities.
You need confidence that the mountain is worth optimising before you commit your resources. It’s very hard to pull the plug on a construction project when you’re 6 months in, even when you’ve realised that it’s doomed. On the other hand, you can run a Hard Test in days instead of months. They’re easy to drop if they’re not working, and you can run dozens of Hard Tests in the time it takes you to ship one fully coded-up system (that nobody wants).
You need to really understand the terrain before you start building or you will build the wrong things. You can’t know what it really takes to climb a mountain until you’ve done it a few times. A Hard Test puts you right on the rock face with your customers. You get to know every handhold, every overhang and every moment of respite. When you’ve done the climb along with customers, you don’t wonder which features to prioritise: you know what matters.
It can feel like going slow because you don’t build anything on day 1. But the more you embrace the Hard Test, the less wrong stuff you need to build and so the faster you get to the point where you have a smooth and profitable system.
It’s a short cut, but it’s a tough climb of a short cut. Which can be a problem …
A Hard Test can look too much like a nasty, steep slope
Let’s get meta for a moment. There’s an energy gradient landscape inside every business too. A landscape of processes, habits and norms.
Often, habitual optimisation behaviours have been done so often that they’ve become smooth, well-trodden grooves. Planning massive builds might be a long distance walk, but the slope is gentle and most of the employees are strolling along it.
Meanwhile, unfamiliar discovery behaviours like the Hard Test look like difficult, scree-covered scrambles that none of your colleagues have dared attempt. “Who cares if it’s a short cut? It feels safer to take the long way round.”
Hidden energy gradients like these inside a business make it basically impossible for the business to actually invest in a Hard Test, even if everyone really wants to.
Talk and good intentions don’t do the trick. Folks in many companies talk all the time about the importance of creating real value for customers, about how we should kill bad ideas much earlier, about how fed up we are with building things nobody wants. They have all these conversations while strolling up and down the same old set of gentle slopes.
To get your teams to stop the optimisation behaviour and try a Hard Test, you might need to change the constraints so that the gentle optimisation slope is suddenly less appealing than the Hard Test scree-scramble.
You’ll know best what might work in your context, but here are a few suggestions:
Set a time limit that means taking the long smooth slope is impossible. If you set yourself only 5 days to help at least one real customer make real progress with something valuable, then building is impossible. You’ll have to resort to delivering the value by hand, perhaps setting up some very minimal systems or repurposing technology you already have.
Set a rule that no engineering effort can be applied to any project until its team has demonstrably sold and delivered real value in the same repeatable way to 10 delighted customers. The teams can be free to explore lots of different offers and ways to deliver value until they can show repeatable success. Doing this across a lot of teams, you’ll quickly get much clearer signals about which mountains are worth climbing and what it’ll really take to optimise them.
Or if you genuinely can’t test ideas without engineering something, run a hackathon. This creates a temporary time-box in which teams can prototype lots of different novel ideas to try out with customers. Get these rough early prototypes into the hands of your most intrepid and understanding customers. Then invest in optimising the ones that work.
Can you think of any other ways to set constraints in your organisation that would make the Hard Test suddenly look more appealing? Hit reply and let me know.
Tom x
Great newsletter, terrible name.
Go runnin’ up that road. With no proble-ems.