Process for a product team can be suffocating, or process can be liberating. And no process at all? Well that’s fun for maybe a week or two before everything starts to fall apart.
Our team has done a lot of work over the last while reflecting and improving on how we build product. Our goal was to arrive at the minimal process that gives teams a framework to plan and structure their time, and most importantly, to prioritise and make the best tradeoffs.
Previously, we thought about building product over three timelines – 6 weeks, 6 months and 6 years (which Paul catchily referred to as the “666 mindset”). But now the 6 month roadmap is no more. The one constant, the core of that framework that we’re doubling down on, is the 6 week cycle. Here’s how we think about it, and what it looks like in practice.
Why the 6 month timeframe didn’t work
The simple truth for any product team is this: the further out you plan, the more suspect the commitments become.
Making far-out planning commitments with your product team actually has compound negative interest:
Your team spends a too much time planning upfront. Planning is necessary, but great teams want to be building. So much time spent planning means the job has become less fun.
No matter how hard you try, your plans are still largely fiction. So the team feels either scared (because you were really ambitious) or de-motivated (because it’s too cautious), and likely de-energised.
Teams outside R&D will soon realise that the plans aren’t reliable, so R&D loses credibility.
Your plans feel like strait-jackets that you’re constantly having to re-adjust, but from which you’re never able to actually break free.
So instead of using a 6 month cycle, now we keep our roadmaps unbound by time: they’re simply the next 5 projects that a team is going to work on, in prioritized order. That’s it.
It might take the team two months to finish those 5 projects, or it could take two quarters. Doesn’t matter. This simple list of 5 projects unlocks the next step – the 6 week cycle.
6 week cycles are about execution
With a list of projects to work on next, teams can focus exclusively on what they can accomplish in the next 6 weeks. This is actually a big deal. You no longer have to juggle strategy and execution in a single conversation, which is deceptively head-wrecking. Your brain will thank you.
Here’s how the 6 week cycle works in a little more detail.
Goals, not plans
We don’t optimize for detailed planning. Instead we focus on the goals for the cycle. Every 6 weeks, each team proposes a handful of goals for what they want to accomplish that cycle. Because you only have to project 6 weeks out, you don’t need a detailed plan to have high confidence in your goals. This keeps it lightweight.
Then the team nominates one primary goal. This is the goal for which you’ll sacrifice all others to hit when you need to adapt to changing circumstances. Agreeing this upfront makes the typically hard decisions that arise around week 4 (“Crap, Project A is taking longer than expected. What should we do?”) refreshingly easy (“Actually, it’s clear. Let’s stop work on Project B and commit everyone to A.”)
Our main goals are usually about releasing an improvement to all customers. And secondary goals often focus on releasing to beta. We optimize for visible progress for all customers.
And we include candidate goals as well. These are goals we considered but rejected. This helps us think about what we’re choosing not to do this cycle. It’s important to be explicit about this.
Then we pull all these together in a single spreadsheet, which everyone has access to. Here’s the summary tab of our R&D goal spreadsheet, showing an overview of each team’s main goal:
Accountability matters
Each goal of the 6 week cycle is specific and measurable, and teams are held accountable for them, particularly the primary goal. This requires a subtle balance – you don’t want teams to become cautious, otherwise they won’t hit any goal. So we don’t expect perfection. Missing goals happens. But teams should feel good about what they’re committing to – that it’s achievable and something they’d feel proud about delivering in 6 weeks. It should hurt to miss your goals.
They’re not delivery cycles
Our planning and commitment timeframe is 6 weeks, but we don’t use that to artificially constrain projects. One project might be designed, built, and released in just a couple weeks, while others will span across a couple of cycles. You should be releasing product the whole way through a cycle. And sometimes you’ll hit your main goal in week 3 or 4. That’s all totally fine. 6 weeks is simply our planning and commitment cadence. It’s our structure to help give the teams the right level of predictability and foresight.
6 weeks is the Goldilocks of timeframes – just right
Building good software is really hard. You need your processes to support you, not pull you down. We’ve found the 6 week cycle does just that. It helps your team fight for meaningful goals, and gives you flexibility within 6 weeks to adjust and adapt to the inherent uncertainty of shipping product. It strikes the balance between making commitments your team believes in, and giving your team a wide-enough window to use their creativity to actually make it happen.
The team at Basecamp have a different model behind it, but still ultimately share a conviction that 6 weeks works well for building product. That makes us even more confident that 6 weeks is, well, just right.
You should give it a try too.
Comments