Focus, Cadence and Shipping

Some startups/companies seem to constantly be shipping awesome features, growing steadily, and generally becoming more awesome day after day.

For instance, if you take a look at the Stripe blog it’s post after post of awesome, new features that make accepting and managing payments on the web way easier. GitHub is another company that instantly comes to mind for it’s ability to ship features on a consistent basis.

When I see startups like that I get shipping envy. I want to build a company that is known for constantly shipping and improving.

When Zapier was just Bryan, Mike and I and we didn’t have many users, it was pretty easy to constantly ship new or improved features. Since October we’ve added our first three employees and tripled the number of users on Zapier. As a result, it’s not quite as easy to ship on a consistant basis as it was before.

Because of this, I’ve started thinking about how to structure our little company so that it can continue to ship features at a steady pace and grow up into a sustainable business.

The three things that have worked so far? Focus, Cadence, and Shipping.

What is Focus?

Focus at Zapier is pretty straight forward.

Everyone has some part of the product experience they are responsible for. That can be backend for Bryan. Frontend for Mike. Support for Micah. You get the picture.

While each person does have a focus there’s nothing that says they have to exclusively do that thing (for instance everyone at Zapier does support). At the end of the day though, that’s the piece of the Zapier puzzle they are responsible for. So if something isn’t up to snuff they are the ones who get the credit for fixing it (or blame for not).

Knowing that you are responsible for a piece of the puzzle helps guide what you do on a day-to-day basis.

The second part of focus is honing in on specific things you can do to improve Zapier. Usually this revolves around a key metric.

The key metric may not be static either, depending on the current goals. For instance, right now the main frontend goal is increasing retention for first time users. Two months ago that might not have been the biggest issue, but for the foreseeable future it is.

So now it’s Mike’s job (with everyone else’s input) to decide what features, A/B tests, and product improvements he should focus on to improve that performance metric.

What is Cadence?

Cadence is the timing mechanism behind focus. It’s entirely possible to either A) spend a bunch of time focusing on some piece of the product without ever delivering on anything or B) go on an all out sprint and deliver something really quickly, but end up burned out as a result.

So cadence is a way to make sure that for some loose time period something is getting delivered. This could be a new feature, another set of A/B tests, N pieces of content for the blog, or an improvement in current processes that results in higher performance for the above focus metrics.

At Zapier, we’re experimenting with developers having a three week cadence when they can work “in the zone” on a project and then one week off when they are on-call for bug duty and support.

This three week cadence provides ample time to make significant progress on whatever focus element someone is currently working on, while also providing a well-defined endpoint so that things are constantly getting released into the wild.

Which leads to the final piece of the puzzle.

What is Shipping?

Shipping is the goal of this entire process. The culmination of each cadence is that significant progress has been made on each focus area and as a results we are constantly shipping new features out the door.

The key bit is that at the end of the cadence you ship. Regardless of “completeness” you ship. So in practice what happens is that towards the end of the cadence you start to realize what you can realistically deliver and you focus in on the most important parts of what you are building, you strip out the unnecessary pieces. This results in a simpler and more focused product getting shipped.

So far this has worked pretty well and led to a new frontend being released and hoards of new triggers/actions/services going live on Zapier.

This Sounds Familiar

If it sounds familiar, that’s probably because it is. It borrows pretty heavily from agile development and other lean philosophies. In fact, I’m sure there’s very little that is original about this at all.

That said, there’s a lot I like about it.

  1. It’s light weight and not prescriptive at all. Instead it’s a loose framework for helping everyone make meaningful progress on whatever part of Zapier they are responsible for. But at the same time it lets them solve problems creatively and doesn’t impose some sort of daily checklist that everyone has to complete.

  2. It has the added benefit of letting people have flexible work schedules. As long as at the end of a cadence something is being shipped then it’s not a big deal if you want a day off here or there, work at night, or adhere to some other non-standard work schedule.

  3. The end result is steady and continuous improvement. The company is always getting better. While some cadences might be more successful than others, you can somewhat avoid the severe roller coaster ride that is most startups. And over the period of a few cadences significant improvement is made.

Making the Transition

I don’t see all that many startups writing about making the transition from a few founders to a few employees. I’d love to hear how others make this switch and are able to continue to ship new stuff at a steady and consistent basis.

Posted on March 17th, 2013

Theme design by Wade Foster.