Distribution Before Design

Development is no longer the determining factor in building a successful product. Distribution is.

This has been true for a long time and it's become even more true with the improvements we're seeing in AI software development. Distribution and strategy aren't quite the same thing to most people, so to be clear about how I'm using the words: when I talk about distribution, I'm talking about the strategy for how a product reaches people and grows. If that's the key determinant of a product's success, then before we design anything, we need a clear distribution plan.

Building A GTM Plan

Everyone has a product dream and it doesn't matter if it's the next Uber or a lifestyle business. We have to separate that product dream (Uber) from the current reality (we don't have an app at all). That means separating the 0→1 Go To Market (GTM) plan from the 1→100 plan. These are two different things, and we can't design the 1→100 plan until after 0→1 is complete.

The best 0→1 plans are simple. They feel elegant when you read them. They aren't complex, with multiple things that have to go right at each step. They're filled with simple steps and actions rooted in first principles, human behavior, and the application's objectives. When you read it, you should be nodding your head thinking - that makes a lot of sense.

For example, we recently built a trusted review app where users can share recommendations with friends and family.

The GTM plan is simple: target travel recommendations. You can leave reviews for anything and everything, but we don't want to dilute the value across dozens of use cases at the start. We want a clean focus. Sharing travel recommendations is a natural activity, a job to be done that consumers already perform today.

That's the beachhead - travel recommendations.

Then we look at how people share travel recommendations and where the value is in the application. One day, in the far, far future, this app could have millions or billions of reviews. That isn't today though. Features like maps and deep search wouldn’t be valuable now.

So we focused on lists and user invites instead. Consider an interaction between two friends. One is going to Rome and, prompted or unprompted, the other wants to share recommendations. We enable this with easy list creation and sharing using deferred deep links (ulink.ly).

That's the growth strategy - users want to share recommended travel places. They can invite other users to the app to see their lists.

If you designed the product first, you'd have dozens of screens and features built for a future state of millions of users and reviews. What really matters right now is lists and the ability to share them.

Why All of This Matters

In the previous example I showed how simple the app can be in the 0→1 phase. Simple matters more than almost anything else here, because it gives us more chances to succeed.

Every product is limited by budget in its early stages. No one has an unlimited budget, and I die a little inside every time a prospective client tells me there's no budget. Of course there is. So for our example, let's say the budget is $100k.

There's only so much you can do with $100k. If you spend all of it on the initial build, you have nothing left for the changes you'll inevitably need, and nothing to run the product or support users when issues come up. You've spent everything before you've learned anything.

Now imagine you spend a quarter of it, $25k, on a lean build that nails the beachhead (lists and the invite flow) along with the GTM plan to launch it. That choice gives your future self a real gift: optionality and downside protection. If the app gets no traction and turns out to be a dud, you've spent $25k finding that out instead of $100k. You still have $75k. On the other hand, if you launch and a handful of users love it, raving about it and can't stop using it, now you're onto something, and you have $75k left to put toward marketing and improvements that drive real growth.

The numbers matter less than the ratio. Spend a fraction up front to learn whether you have something, and hold the rest in reserve for the outcome where you do. Keeping a simple GTM plan is what makes that possible, and it gives the product the best chance of success.

So, What Does Design Do?

The designers reading this might be thinking, "Hey, isn't that my job?" And a lot of it is. Here's how I see the division: the Product Manager owns the strategy, the decision to focus on lists and the invite flow, and design makes that strategy real and effortless to use.

This is where I want to be careful, because plenty of great products won on design. Apple, Linear, and Notion are obvious examples. The point isn't that design doesn't matter. It's that design works best in service of the distribution strategy. Once we've decided the growth motion is sharing lists and inviting friends, design's job is to build the brand around trusted recommendations and to make that motion obvious and frictionless: a UI that's intuitive and simple while actively pulling users toward the features that drive growth, like creating lists, sharing them, and inviting new people.

I've believed for a while that waterfall design is just as dead as waterfall software development. PM and design have to be collaborative to build something great. The distribution strategy just has to come first, and design's power is in making that strategy land.

The Lifecycle of Building An App

With this change, distribution before design, we've adjusted our app development process.

First, we work to turn the client's vision into something that can land. It needs a clear, simple, and attainable beachhead. Then we design the experience around it. Almost always this involves some form of deferred deep linking for invites and referrals, though every GTM motion is different.

After designs are done, the project follows its normal path of development and release. The advantage is that by the time we reach the finish line, we already know what comes next. Clients can even use the development window to prepare their GTM motion. That means no time is wasted: the moment the product is ready to ship, they're ready to launch it.

A GTM report isn't the same as a GTM motion, and it's certainly not the same as a successful one. This is still hard, real work, and I don't want to suggest that producing a report produces a successful product. It doesn't. What it does is produce a product that's aligned with its GTM strategy, so the two work together. And when GTM strategy and product design work together, the product has the highest probability of success we can give it.