Development Cadence

An object in motion stays in motion…

One of the foundational challenges of scaling a startup is crafting an efficient development engine across product, engineering, and design that maximizes throughput of product innovation with as little thrash, burnout, or stagnation as possible. The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders.

Developing a “brisk but not burning” development cadence is one of the most high value things a startup can do, if not the single best way to align teams around a strategy, build and fortify a market position, and create an enduring company.

But how do you establish and measure development cadence? It’s a question I’ve thought a lot about and continue to iterate on with company leaders that I meet. Below are a few tactics I’ve practiced or observed:

1) Launch. Just as winning begets winning, shipping begets shipping. A company that has a healthy development cadence ships regularly. This might seem obvious, but aspirational market leaders in tech like Apple are able to get away with launching just a couple of times a year. Startups don’t enjoy the same luxury — a startup’s single biggest structural advantage over incumbents is speed.

One way to establish a good development cadence is to commit to a predictable launch schedule and avoid slipping by pushing out features, not time. Some organizations commit to launching every month with the notion of ticks (small feature releases/fixes) and tocks (bigger, marketable moments). Even companies that ship to production every day can benefit from packaging releases internally into product “launches” to further internalize a consistent launch tempo. Notably, this is as relevant to internal tools as it is to customer-facing features.

Of course, a startup’s given product or market may not align with quite such a regular public launch cadence. In that case — and in all cases, really — it’s useful to “ship” internal betas and tests to the team on a regular, ideally weekly, basis. Establishing a practice of showing and sharing work helps ensure accountability, builds momentum and enthusiasm, and brings a roadmap to life for internal collaborators and stakeholders.

2) Roadmap effectively (and ruthlessly). Having a written down, accessible product roadmap is core to driving alignment within a fast growing startup, where it can be challenging to bring everyone along as the product, business, and team evolve in real time. Transparent launch calendars are critical for establishing a cadence around launches. Here is an example product roadmap viewed as a launch calendar, with a few features of note.

P0-P5: prioritize the features and fixes for every release so that everyone is clear about relative trade-offs. Rather than pushing out a launch and losing development momentum, cut P5s and get the rest out the door. Just the act of acknowledging relative priority and then having to cut features to make a date has the effect of instilling a sense of urgency.

DRIs: each feature should have a “Directly Responsible Individual.” This person could be in any function but is typically an engineer, PM, or designer. They are the internal stakeholder for all questions, concerns, and ensuring that development is on the rails. While I’m a big believer in small, highly collaborative development teams, having a single point of contact ensures internal clarity of roles and expectations.

P/P/F: I find it helpful to have a notion of “Past/Present/Future” in each release, with the ‘past’ representing bug fixes/technical debt, ‘present’ reflecting known product omissions or top requests from customers, and ‘future’ illustrating the unfolding of the product — the innovation or new-new thing. Naturally releases don’t always come together this cleanly, but it’s a good framework for ensuring that a startup isn’t building a tech stack of bubble gum and toothpicks that will have to be painfully re-platformed, or ignoring obvious customer feature requests.

As a side note, for most startups, I suggest having two quarters of releases spec’ed out, with another two quarters of visibility beyond that, though typically with less fidelity.

3) Meetings as a metronome. While I have a bias for small teams working collaboratively across functions to build and ship product, it’s critical that there are regular moments of alignment with the founder/CEO and other executive stakeholders. These typically take the form of product reviews and are useful for ensuring cohesion with the founder’s view. They provide the team with the space to present their work and get feedback, and the founder with focused time to go deep without creating ad hoc thrash.

It’s useful when these reviews are held weekly and lead with i) a snapshot of the product’s KPIs, and follow with ii) review on things the team said they were going to do last week and the things they actually did, iii) any problems or roadblocks encountered during development, iv) things the team is going to do this week, and finally v) ample time for discussion topics. Some organizations alternatively use the “Progress, Plans & Problems” framework in reviews. Here is bare bones template that can be easily updated week-over-week.

People often wonder if this template for product reviews is too much process for a startup, but in my view no process is still a process unto itself — just not an efficient one — and putting the infrastructure in place even at 20 people helps maintain ongoing alignment as the company grows. Product reviews are best when they include product, engineering, and design leaders to set a metronome of development and accountability.

Development cadence is ultimately the pulse of any startup. Establishing a brisk but not burning one early is critical, and finding ways to measure yours over time ensures ongoing velocity. Above are a few tactics I’ve observed or practiced, but I’m always interested to hear more.

How do you establish and measure your company’s development cadence?