There is no 'right' product cadence

Cadence is not often debated in the product community.

For some reason, the recommendation is always the same: 2-week sprints.

Chat, this is BS.

There is no 'right' product cadence. Here are a few variants I have tried:

• 2-week sprint (the ol' classic)

• 6-week sprint

• 6-week cycle + 2-week cool down (Shape Up style)

• 2-week sprint + 1-day cool down

• No cadence at all (ship when ready)

In a recent newsletter, Beehiiv CEO Tyler Denk shared their cadence:

Tyler Denk on Beehiiv’s product cadence (source)

There is no 'right' cadence. Only the cadence that works for you.

So, which one’s right for you?

---

How to pick the right product cadence

Ultimately, it's a personal choice.

That's it. Good night.

Just kidding.

Here are four ways to experiment with cadence.

1. Are you a 70% or 100% team?

Google is known for setting ambitious goals. Their OKR system requires every individual, every team, and every department to set ambitious goals, emphasis on ambitious.

There's a catch: Googlers rarely reach 100% of their goals. A hit rate of about 70% is considered a success. Anything above 70% (let alone 100%) is, in fact, a sign the goal wasn't ambitious enough. This approach is also shared by Atlassian.

Conversely, companies like IBM or Microsoft have, at times, focused on setting conservative and achievable goals. While this might sound less stressful, missing your 100% target in this environment is a big deal.

Between these two 'philosophies', which one matches your culture?

Do you work in a culture of 'go go go' (but with an understanding that targets will be missed)? Or do you work in a culture of 'safe and steady' (but with an understanding that you'll be slower and failure to hit goals will be dramatic)?

Your culture will influence your sprints.

If you'd rather 'move fast and break things', a 2-week sprint with no cool-down might be best. If you need a more conservative approach, quarterly cycles might be best.

2. Cool-downs

When PMs talk about cadence, we tend to focus on the sprint part. Two weeks, six weeks, three weeks; how much time are we allocating to actual work?

In theory, at the end of the sprint the work is done and we move on to the next one.

In reality, this is rarely the case (particularly if you set ambitious goals).

In the past few years, I've focused on making cool-downs a set part of our cadence.

Example product cadence with a 1-day cool-down.

A cool-down is a bit of time between two sprints to mop things up. This could be fixing small bugs, wrapping up some tests, or adding a nice-to-have.

I have found these extremely valuable. It's time for the team to regroup, breathe a little, and get ready for the next sprint.

Cool-downs aren't for everyone. Some teams would rather keep sprinting. That might be fine. My recommendations, however, are:

1. Implement cool-downs. A scheduled reset is really helpful for the entire team. More about cool-downs in this post.

2. Design your cool-down to be a fraction of your sprint. There is no exact science to this, I target ~20-30% of sprint time:

   1. 2-week sprint -> 1-2 days cool down

   2. 6-week sprint -> 2 weeks cool down

   3. 3-week sprint -> 1 week cool down

3. Product team structure

A typical core product team is six people: one PM, four engineers, and one researcher. In reality, your team might be bigger or smaller.

You will want to adapt your cadence to the size and structure of your team. In my experience, a small team (<5 devs) can adapt to any cadence. If your team is bigger than this, I'd recommend splitting it into sub-teams that match the 'normal' structure above.

If your team is in the messy middle (8-10 devs), here's a fun experiment:

Split your team into two (A & B team) and run 6-week cycles using the Shape Up methodology. Put Team A on a cycle and Team B in a cool-down. Run both teams parallel to each other, then swap.

4. Experiment

Finally, of course, test, test, and test again.

Picking a cadence is a personal decision. Your cadence has to match your culture, your strategy, and even your company goals.

Don't be intimidated by this decision: you can always change it.

Try a 2-week sprint cadence for a quarter. Then try 6-week Shape Up cycles. Then try a hybrid. Even try having no sprint at all.

Make sure you give your team a heads-up. As you experiment, get their feedback. Try to spot whether a particular cadence seems to match their groove.