To Know What to Build, Start Building
To Know What to Build, Start Building
Res Extensa #41 :: In praise of just get started, and exploring the stepping stones
This post has been in draft for a year. Actually, to call it a "post" then would be generous — really we’re talking the vague idea, the title typed as a fleeting thought that I'd get around to eventually. Since typing it off-the-cuff sometime in 2022, I've variously stewed on, stared at, and thought about the idea repeatedly since. Without any more than two or three additional bullet points added in 12 months, it hadn't advanced at all until two days ago. Every time I'd think about writing it, I'd quickly hit a "well what do I have to say about it?" wall and go no further.
Rich with irony. A classic story of writer's block. The block is really a fear of starting, a fear of typing out something that ends up wrong, dumb, or extremely deleteable. But the way out of this trap of not knowing what to do is to start moving on it.
This idea is one of my deep beliefs: that the best way to formulate the exact solution to a problem — a blog post from an idea, a piece of furniture from a rough sketch — is to get started. In fact, I don't believe you can possibly know all the details of what needs doing until you start taking steps. Even with seemingly simple things.
Framing and shaping
Before we start building, we can get stuck in a perpetual hamster wheel of thinking, whiteboarding, discussing, outlining. One of the things that keeps us stuck there is that we haven't mapped the contours and constraints of the problem — what's even making us think this thing needs doing? What nugget of something led us to a post that needs writing, the feature that needs building?
Ryan Singer, of Basecamp and Shape Up renown, has this mental model of "framing" and "shaping". In framing we're defining the problem and the constraints of what we know aren't the problem, and in shaping we form our solution, based on that frame. So even thought I just denigrated the thinking and whiteboarding, those are part and parcel of understanding the problem.
The fuzzy transitions between framing, shaping, and building are where we hit snags. Where does one end and the next begin? Not always obvious. The part where we actually start writing, or typing code, or putting paint on the canvas — that's when it gets real. It feels like there's "no turning back". So this fear of starting can get us stuck in that hamster wheel, where we think a "little more planning" might de-risk things enough that we won't make a fatal mistake. The truth is, though, with almost all things, most all “starting” is composed of two-way doors. We can put it in reverse if we discover we’re going the wrong way, with minimal impact.
Trust the "soft middle"
I wrote about this a while back in Hard Edges, Soft Middle. One of the best ways to build the confidence to get started and enter the exploratory process of finding a solution is to set as well-defined a search space as you can: outline the "hard edges". Setting this defined space gives you constraints to comfortably work within, almost like a cozy room with padded walls where we've got the freedom to tinker around and look for that solution we don't even know about yet. The upside is that when defining the edges, we don't need to know. Now once we’re exploring, we might find out there is no solution. But without the safety net of the scope and appetite, it feels like we have to explore everything to find our optimal solution.
The intimidation of the massive, poorly-defined problem space repels us — easier to stay over here at the whiteboard "planning". We need to rein things in first. Getting to a satisfying set of edges resolves unknowns and eliminates thousands of possible paths. It may seem like loss aversion might kick in ("But what if the 'right' way isn't possible now?!"), which might happen. Yet the freedom you get from the now-well-bounded soft middle is worth the trade-off:
Any creative work benefits from boundaries, from having constraints on what can be done. The writer is constrained by a deadline or word count. The artist is constrained by the canvas and medium. A product team should be constrained by a hard goal line in terms of time or objective, or preferably both.
It lets us get started so we can start searching.
Stepping Stones
Right now I'm reading a book called Why Greatness Cannot Be Planned, by AI researchers Kenneth Stanley and Joel Lehman. The subtitle is "The Myth of the Objective", which states the thesis: that interesting, ambitious results come about without being the original objective. It's a provocative idea, and they back it up with plenty of evidence.
A useful heuristic in the book is the idea of stepping stones. Every innovation, invention, or Big Result was a final destination along a pathway of stepping stones that led there. At each individual stepping stone, you can proceed to one of several individual next steps — the "adjacent possible". In order to reach an objective, you often have to step along pathways that look counterintuitive. It turns out that from the starting stone, the final one you ended up on isn’t even visible. It’s all the way across the massive lake of space, time, and incremental innovations.
To create the personal computer, you wouldn't think you needed vacuum tubes, but they were a necessary stepping stone. For the Wright Brothers to build their flyer, we first had to find the induction coil, which then led to internal combustion engines. Innovations are all the product of a magic accumulation of previous stepping stones.
To be clear, they're mostly referring to ambitious goals — things like AGI, fusion power, cures for cancer, not necessarily things like blog posts or software features. But the same principles are useful in getting unstuck, and realizing that the only way to the destination is find the next stepping stones and pick one.
Just Get Started
In my experience, even though it seems paradoxical, more time spent perpetually "framing and shaping" can cause us to psych ourselves out of getting started. It seems like countless times I've witnessed a team (or myself), through nothing but talking and rehashing, blow a project up to several times its actual size. I’m sure it’s happened to you: you stewed on a doing a project for months that turned out to take a few minutes once you got started. The starting was the missing piece.
Whatever view I had of where this post would go, when it was just a title in a text file, is definitely not where I ended up. That's the beauty of just getting moving: you find yourself at a novel result.
It turns out, once I actually started typing this post, it only took me a couple hours to go from "only typed a title" to clicking Publish.
Well, a couple hours plus 12 months. Maybe I should take my own advice more often.