Patrick Joyce

June 20, 2013

How do you end up with a great product a year from now?

Nail the next two weeks. 26 times in a row.

At the beginning of a startup there generally isn't a lot of ceremony regarding planning. The founders agreed on some problem that needs solving and the engineers and designers get to work.

The problem could be something like "let's build a thermostat that doesn't suck" to "let's help small distillers sell booze on the internet."

But the many, many decisions and tasks that go into actually solving that problem aren't mapped out.

I think this is because in the early stages everyone is fully aware of how little they know. You're still learning about the problem, so why bother pretending you know what you need to do in a month, let alone a year?

What's the plan?

This will change if you manage to build a product that gets some traction. The company will grow. Your investors will want more detail about where the product is going. Employees who aren't engineers or designers will join and ask to know what's coming. And the pressure to create detailed product development roadmaps will grow.

Resist this pressure.

There isn't anything wrong with planning, per se. I don't advocate thinking only of the short term. You should be able to articulate medium to long term goals for what you're building. However, those goals will by definition fuzzy.

In my experience teams work best—and produce the most successful products—when they understand the problem they're solving but have a maniacal focus on constant, incremental improvement.

Easier said than done

You need to define what success looks like, how you're going to measure it, and make sure everyone working on the product knows what it is.

When we first started working on Daily Deals at LivingSocial there were 4 things we focused on:

  1. Were we able to sign up merchants to offer deals?
  2. How many subscribers were we acquiring?
  3. How many of those subscribers were becoming purchasers?
  4. Did those customers come back and buy again?

If we failed at any one of those things then we wouldn't have a business. And if we nailed all four of those things then it looked like we'd have something.

Find what those four things are for your product. You may have only two or three key questions, but you shouldn't have more than four. If you come up with six things then I don't think you've honestly prioritized.

Prioritization and planning become much easier once you have those four agreed upon goals. Every proposed feature can be evaluated with "which of these four things will it help?" and if the answer is "none of them" then you get to stop talking about it.

To be clear, this doesn't mean that every individual feature or test you run has to directly move one of those four metrics. Those four metrics are intentionally high level. It is going to be hard to move them. But there should be a plausible story connecting everything you build to one of those four goals.

As an example, you may want to work on improving the design of your email templates. There is a reasonable hope that better email templates will drive people to buy more. If we're looking at the four things we cared about in the early days of LivingSocial, this feature is tied to question #3 (new customers) and question #4 (repeat customers)

However, measuring a direct effect on purchasing from an email template change is hard. Because the base conversion rate is so low, you need a massive sample. So for a first test it may make sense to measure click rates. It is reasonable to assume that if you increase the number of people clicking to your site you'll get more purchases.1

So don't worry so much about roadmaps, or what you're going to build in Q2 of next year. Instead, make sure you know what you need to do to be a successful business.

Then spend the next 2 weeks shipping things that will help those problems.

Then do it another 25 times.


  1. This isn’t always true, and you need to be careful that you don’t cheat. If you pick your top level problems correctly its hard to cheat on them. Revenue is revenue, and its hard to juke the stats when the stats consist of someone paying you. But the intermediate metrics can sometimes be manipulated, often unintentionally. For example, in the email example you could remove prices from your email. Now to find out how much something costs people have to click. This will probably increase clicks, but it no longer follows that purchase rate will necessarily increase because you’re generating less qualified clicks that may convert at a massively lower rate.

More Articles on Software & Product Development

Agile With a Lowercase “a”
”Agile“ is an adjective. It is not a noun. It isn’t something you do, it is something you are.
Build it Twice
Resist the urge to abstract until you've learned what is general to a class of problems and what is specific to each problem.