A powerful technique for navigating complex problem domains: adjacency maps.

In these kinds of domains, it's unclear where to get started.

There are hundreds of possible toeholds, in a big swirling chaotic soup of possibility.

It's unclear which toeholds will turn out to be viable.

A number of toeholds have obvious adjacencies to grow into if they turn out to be viable.

Which toehold to start with is not just its own value, but the indirect value of the adjacent things to grow into.

It's hard to decide which toehold to start at if you're just one person.

But coordinating that choice is even harder with a team.

The difficulty of coordinating the choice goes up super-linearly with the size of the team.

That's where adjacency maps are useful.

Think of them like a tech tree from the game Civilization.

First, you ask everyone in the team to come up with every toehold of value that might plausibly have even one user who would find it valuable.

You want a comprehensive enumeration of all possible use cases.

The bar for inclusion is deliberately very low, favoring comprehensiveness.

Then, you factor them into a tree.

Each node represents a use case.

Use cases have a connection to a parent use case if they are dependencies of the parent.

That is, to build the use case you would have had to at least build out the parent use cases and then layer on more work on top.

The dimensions that they can be dependencies:

Engineering - Code that has to be written

UX - User experiences that have to be designed

Data - Any data quality that has to be above some quality threshold.

Behavior - Any user behaviors and expectations that have to be established to activate this use case.

For each dimension, "t-shirt size" the expected effort.

Lay out the tree so that use cases expand from left to right, with the root note at the left.

Having this shared adjacency map changes the game.

Now everyone can see that their use case is on the map.

They don't have to continually advocate for it, because they can see it's on the map.

People can see that items on the left have fewer dependencies than those on the right.

People can also see which use cases are "upstream" of nearly everything.

"We all see that this use case exists. We disagree on how valuable it is, but we all agree that it is upstream of almost every use case. So we can agree to prototype it."

When you prototype a use case, if it's getting good traction, invest more into it, up a ladder of audiences:

The person building it finds it surprisingly compelling

The team finds it surprisingly compelling

A broader internal dogfood group finds it surprisingly compelling

An external trusted testers group finds it surprisingly compelling

An external beta finds it surprisingly compelling

General release

At each time step, pick the use case with the fewest unbuilt dependencies.

If any audience found it surprisingly compelling, invest a bit more to get to the next rung of the audience ladder.

At any point if interest wanes from the expanded audience, pick the next use case that is downstream of this use case that has the most value downstream of it.

As you go and learn more, update your map with more use cases and better estimates of costs.

The typical approach to this kind of problem is to have a charismatic and powerful lead pick a single vision.

This solves the coordination problem, but at the cost of being significantly less resilient.

The vision is likely to be wrong in such a complex and unknown environment.

If the vision the leader picked was wrong, the project will fail.

Even if the leader projects total confidence, the organization will likely gossip and whisper about oversights in the plan, undermining the likelihood it actually works.

The leader's confidence is fundamentally a show, bravado, unearned confidence, designed to be strong enough to coordinate the team to.

The adjacency map process is wildly different from the typical approach; it resolves a coordination challenge and allows adaptation and growth as you surf through the problem space.

Instead of pretending you know everything and have an infallible vision, you embrace the uncertainty, and surf it.

Of course, this is a thing that I built a hobby open-source project around a couple years ago: https://github.com/jkomoros/adjacency-map

The project allows creating a shared interactive map, and also comparing different "scenarios" (e.g. different costs and value guesses from different parts of the team) to navigate the map.