Position, Position, Position!

The mantra in real estate is “location, location, location.” You can upgrade kitchens and bathrooms all day, but if you’re in the wrong neighborhood it won’t sell.

The same is true for products. Focusing on individual features and experiences is good, but you should never forget about the position you’re trying to hold.

A product’s position is a “location” in a more abstract space — the space of trade-offs. The decisions you make about which features to build and how to integrate them places you “closer” or “further” from other products.

Your position also affects whether you’re in or out of the competitive set when a “hiring” moment arises. That is, when a person reaches for a product to solve their problem, are you the right fit? Which problems are good fits for you and which ones are bad fits?

When you know your position, you can say “no.” When you don’t know, you say “yes” out of fear. You build a feature because you’re afraid of what will happen if you don’t. That’s not a strong place to be competitively and it’s not a coherent place to be in terms of your product design.

Snickers and Milky Way

Let’s make this less abstract. The thing that made this click for me is a story about Snickers and Milky Way. Once upon a time, they were marketed identically. “Smooth chocolately flavor” etc. The teams took on a challenge to outsell each other, under the assumption they were competitors in the same space — the “chocolate candy bar” position.

Both teams did some unconventional research, and big distances appeared between them. Snickers is chewy like food. A little salty, a little crunchy. People ate it when they missed meals and needed a snack. They ate it in public.

Milky Way melts in your mouth. It’s an indulgence. People ate it after an emotional event when they needed a boost. They ate it in private.

The marketing story is famous. Snickers became “You’re not you when you’re hungry.” Young guys bite into them between plays on a football field. That’s a lot different from “Get lost in a Milky Way”, as the happy customer closers their eyes and time stretches out.

What’s important from a product design perspective is this: Snickers can’t take a feature request to be “more melty” and then win over some new customers. Milky Way can’t “add a little crunch” to hit two birds with one stone. These are trade-offs. The trade-offs are both what make them different, what define their competitive sets, and what make them suitable for different hiring moments.

Basecamp’s trade-offs

Each product has its own version of “melty vs chewy.”

At Basecamp, we have an informal understanding about what the product should be and what it shouldn’t be in order to hold its position.

A metaphor from math can create a picture. There are a few trade-offs that you can think of like dimensions that position us in an n-dimensional space.

An abstract space

We could spend months or years building a multiperson live editor ala Google Docs. It’s a “collaboration” feature right? But Basecamp errs on the side of asynchronous communication instead of live editing. Basecamp should make your business a calmer, more orderly place. We want to help you respond to things when you have time, suggest edits when you have time to think, etc.

We could build high-end project management charts that map every dependency between every task. But we want Basecamp to help you make sure key things don’t slip through the cracks. We’d rather make sure you don’t forget something than help you plan to the millimeter.

You can store anything you want in Basecamp. But it’s going to work best if you use it to share and discuss read-only, flat rendered files. Screenshots, PDFs, proofs of copy, video edit #23, etc. Other tools are better for the constant churn of uploading/download or opening/saving that happens with an original PSD file.

We could build custom features that let you tune Basecamp to your exact workflow. But then you’d have to learn how to configure it, navigate all the options and setup flows, and train your team on the inevitably complicated UI. Instead we try to be more like Post-It notes. Something anybody can understand because they don’t have time to learn and set up a more complicated system.

Colors in the ocean

The book Blue Ocean Strategy captures this notion well. The trade-offs you make and the features you integrate position you differently relative to other offerings and hiring situations. With the space of trade-offs in mind, you can visualize how some areas are more attractive than others depending on who else is there. The authors talk about “red oceans” where competitors make similar trade-offs and “blue oceans” where there’s space for something new.

Red and blue “oceans” — positions you want to target or avoid

Communicating with your team

In this year’s strategy retrospective we used an informal table to remind ourselves of how we want to make trade-offs going into 2017.

The “less about / more about” format is a quick way to stake out a position. No math class required.

Position, position, position

Without a clear point of view on what makes you different, it’s easy to wander. Especially in the software industry. New feature requests come in every day, and if you can’t say “no”, who knows where on the map you’ll land.

Like in real estate, it’s easy to repeat the mantra but hard to make the right bet. If you find it hard to clearly define where you belong in the market, you’re not alone. We struggled with it ourselves when Basecamp’s customer base grew into all kinds of industries and use cases. In our case, techniques like the “job to be done” interview technique that Bob Moesta and Chris Spiek teach at their “Switch” workshops were very helpful.

As Clay Christensen says, “questions create the space where answers can appear” — so at the very least, thinking about your product’s position can set you on the right path for gaining more clarity down the road.

Position, Position, Position! was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Original post by Ryan Singer and software by Elliott Back