Our work creating digital products and services always starts with a discovery phase. But our clients often want to truncate discovery and get right to the making part. I kinda get it. Especially when we tell them we want to conduct our own interviews of team stakeholders, and we want to do our own user research. It takes time and costs money, and for clients who have already conducted research, it can feel like they’re buying the same horse twice. Of course we’ll take whatever they have—“Bury us!” we say—but we still insist on identifying for ourselves the inputs that will inform whatever recommendations we’ll eventually make.
I call it “getting stuff in the box.” It’s a reference to that scene from the movie Apollo 13, where they realize the C02 filters are failing, and they need to rebuild the extra square ones on the command module so they fit in a round receptacle. “I suggest you gentlemen invent a way to put a square peg in a round hole.” (So good.) Anyhow, in the next scene there’s a bunch of NASA guys dumping a huge box of random stuff on the table with a mandate to “make this, fit into the hole for this, with nothing but that.”
Discovery is how we get the stuff in the box that we’re going to need to solve your problem. Don’t let “nothing but that” characterize the stuff our team has to work with when it comes time to tackle your biggest challenges. Because here’s the thing: those NASA guys would no doubt have done their level best with a nearly empty box of sad bric-a-brac. But how great is it that they had duct tape, and a spool of wire, and a space suit, and some pliers, and a hose? Likewise, we’ll devise a solution with whatever information and insights are available to us. But as long as we’re in the phase where we’re putting stuff in the box, let’s assemble a rich profusion of insights and ideas, quotes and context, so when it’s time to get to work, we have inspiring material to work with.
Credit to Steven Johnson, who first pointed me to this inspiring scene in his excellent book "Where Do Ideas Come From: The Natural History of Innovation". I read it 12 years ago and think about it once a week.
Here’s a story from the #failureFiles.
Once upon a time, a civilian owned space exploration company who shall not be named approached us about designing part of the user interface in their ship’s command module. Yup. They wanted us to design a spaceship UI. For a team of sci-fi fanatics, this was pretty the most astoundingly exciting thing that had ever happened. By far.
The brief was thin on details. Apparently almost all ship functions were handled by mission control on the surface, but at a certain point—in an emergency, or perhaps when docking with the International Space Station—the crew played a critical role in controlling the ship. That was about all they would tell us. They wanted to talk that very week. But determined to prepare a mind-blowing pitch, we convinced them to give us a couple of extra days. In the absence of a detailed brief, we figured we would give them a window into how we thought. So we studied spaceship UIs from TV and movies, and demonstrated how these did or didn’t align with best practices of great interface design. We also redesigned about half our case studies. In the end the deck was more than 60 pages long. It was glossy and beautiful and we were incredibly excited to share it.
So we flew down for the pitch--I remember we dressed much better than usual. We gladly accepted their offer of a facility tour, during which we ooh’d and ahh’d like starstruck kids. The pitch itself was a blur. We only got through about half the slides. We flew home with fingers crossed.
We didn’t get the job. But they did tell us why, which is rare, and very much appreciated.
In an adjacent sliver of the multiverse, the sun’s light scattered through an atmosphere laden with Saharan dust, primordial chemicals, and wildfire smoke, revealing the vivid dawn of a planet almost identical to our own. Except in this world, we’d received a simple brief for a tight little project. Our clients were under extreme time and budget pressures. They wanted a partner who could roll up their sleeves and working side by side with their people, rapidly explore, prototype and produce a rock solid design solution. They wanted pragmatics, not pitches. This was yeoman's work, not portfolio fodder. Recognizing this and acknowledging our obvious lack of experience designing spaceship UIs, we determined it was enough to just be sponges. Having offered to meet them as soon as possible, we sent a small group who came prepared with nothing but a long list of questions. They offered us a tour and we said, “Sure, if it’s important, but our preference would be to spend our time together learning more about this particular challenge…”
Back in our slightly sadder sliver of the multiverse, I’m reminded that some situations demand the opposite response to what our emotions may dictate. Buy stock when it’s low, sell when it’s high. Swim parallel to shore in a rip tide. And, next time you get a chance to design a spaceship UI, play it cool and put your client first.
We live in a dynamic age. In the interest of avoiding snap judgements and sclerotic thinking, it’s worth remembering that big ideas, particularly the truly novel and disruptive ones, will rapidly evolve in predictable ways.
First, there is a Hypothesis, a supposition based on limited evidence. Then an idea becomes a Thesis, a statement or theory that is put forward as a premise to be maintained. Then there’s the Antithesis, when people come to think in an opposite way about the original idea. And then there’s a Synthesis, when the idea outgrows its hypothesis and thesis, and makes a certain peace with its antithesis.
Here’s an example: The four theses of Crypto.
Hypothesis: Blockchain technology when applied to money will democratize finance.
Thesis: Financial democratization will come through widespread consumer participation in large exchanges like Coinbase and FTX.
Antithesis: Cryptocurrencies are dead, the provenance of swindlers and scofflaws, profoundly unreliable, risky, a terrible hedge against inflation and incapable of holding value.
Synthesis: Inefficient aspects of the traditional banking industry will be disrupted by digital currency transactions that can be reliably verified and maintained, while conforming to basic standards of compliance and accounting.
Consider Steamchain Corp. (Full disclosure, we’ve worked with Steamchain, but I didn’t wake up today planning to log-roll for them.) Steamchain Corp. created smart contract software using the Ethereum (ERC20) blockchain to facilitate currency conversion between trading partners. Traditional banks charge exorbitant hidden fees and can take days to process these transactions, which introduces uncertainty as currencies fluctuate. Steamchain processes transactions at a fraction of the cost, in minutes. That's good ol’ fashioned innovation.
I was 37 when I started working in design strategy, old enough to know not to shout out “Turtle Excluder Device!” as the meeting wrapped up. Most people avoided my gaze and walked away. I managed to catch the sleeve of one colleague gathering up his things. “No, really, you have to hear this.” (It was like that moment in The Rhyme of the Ancient Mariner, which begins with a bedraggled uninvited “grey haired loon” accosting guests at a wedding so he could tell a longish ghost story about why you shouldn’t slay an albatross. In my tale, you’re the wedding guest, I’m the loon.)
In college Bio we learned that there used to be a whole industry around tourists helping newly hatched loggerhead turtles get to the ocean. So many hatchlings were getting run over while crossing roads on their way to the sea! So many were being eaten by gulls! If we could only save more baby turtles, the thinking went, their populations would rebound. But then a young graduate student named Deborah Crouse conducted a population modeling exercise for her PhD thesis, and discovered that no matter how many hatchlings were saved, the number of turtles laying eggs wasn’t increasing. And breeding pairs are what you need to make more turtles (I’ll cover turtle sex in a separate post.) Her work uncovered the real problem: that turtles weren’t surviving adolescence because when they got big enough, they’d get trapped in fishermen’s nets. This insight eventually led to the invention of metal hatches called Turtle Excluder Devices (TEDs) that were built into fishing nets. When a sufficiently heavy turtle gets caught in a net, it springs the hatch and the turtle swims free. Today TEDs are often mandatory, and the turtle populations are far healthier as a result.
What lessons in product strategy can companies learn from the Turtle Excluder Device?
Fast forward almost 20 years to me blurting out, “Turtle Excluder Device!” We’d helped our client design V1 of their telematics platform, after which people came out of the woodwork with bright ideas about what features they'd like to see next. Sales, Service, Maintenance, Product Management—everyone had thoughts about what they’d like to see in V2. Our challenge was to find a way to shepherd these ideas far enough along that they could be honestly evaluated, and potentially cross the gauntlet of doubt about their feasibility, likelihood of adoption and cost. So we created a workshop that incubated numerous ideas, deeply considering how they’d come to life and be experienced over time. And we had a large swath of critical stakeholders participate in shaping each idea, which helped because, well, everyone likes to have a say. The output we created was a marketing story for each—a website—that made it look like the idea was complete, built and launched. We shared these mock marketing websites with customers, other users, and senior leaders who eventually aligned on which ideas to fund and which to pass on. We created a Turtle Excluder Device—for ideas!
Since then, I’ve realized that many companies have problems that could be solved by some version of a metaphorical TED. Maybe their strategy isn’t surviving the design phase because it was thrown over the wall from some long gone consultant. Or their design intent is getting lost in development, because engineers never had a chance to weigh in on its feasibility. Or the finished product isn’t surviving launch because Marketing isn’t clear on its true benefits. In each case, what’s needed is a process that can shepherd great ideas to fruition, and keep them from perishing in corporate environments that are weirdly effective at killing them off.
That’s what we do at Supply. We help our clients succeed not just through expert digital design and development, but by helping them efficiently and effectively set up teams and processes to improve the parts of the product development lifecycle that need it most. Sometimes, that means building a Turtle Excluder Device.
(Big thank you to my bio teacher Dr. Paulette Bierzychudek at Lewis and Clark College, who told us a good story about great science that I’ll never forget.)