Why the 6 month timeframe didn\u2019t work<\/h2>\n
The simple truth for any product team is this: the further out you plan, the more suspect the commitments become.
\n![\"The](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2017\/02\/The_Goldilocks_of_Timeframes_Inline_02.jpg\")
<\/p>\n
Making far-out planning commitments with your product team actually has compound negative interest:<\/p>\n
![\"Making](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2017\/02\/The_Goldilocks_of_Timeframes_Inline.jpg\")
<\/p>\n
- \n
- 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.<\/li>\n
- 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\u2019s too cautious), and likely de-energised.<\/li>\n
- Teams outside R&D will soon realise that the plans aren\u2019t reliable, so R&D loses credibility.<\/li>\n
- Your plans feel like strait-jackets that you\u2019re constantly having to re-adjust, but from which you\u2019re never able to actually break free.<\/li>\n<\/ul>\n
So instead of using a 6 month cycle, now we keep our roadmaps unbound by time: they\u2019re simply the next 5 projects that a team is going to work on, in prioritized order. That\u2019s it.<\/p>\n
It might take the team two months to finish those 5 projects, or it could take two quarters. Doesn\u2019t matter. This simple list of 5 projects unlocks the next step \u2013 the 6 week cycle.<\/p>\n
6 week cycles are about execution<\/h2>\n
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.<\/p>\n
Here\u2019s how the 6 week cycle works in a little more detail.<\/p>\n
Goals, not plans<\/h3>\n
We don\u2019t 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\u2019t need a detailed plan to have high confidence in your goals. This keeps it lightweight.<\/p>\n
Then the team nominates one primary goal. This is the goal for which you\u2019ll 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 (\u201cCrap, Project A is taking longer than expected. What should we do?\u201d) refreshingly easy (\u201cActually, it\u2019s clear. Let\u2019s stop work on Project B and commit everyone to A.\u201d)<\/p>\n
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.<\/p>\n
And we include candidate goals as well. These are goals we considered but rejected. This helps us think about what we\u2019re choosing not to do this cycle<\/em>. It\u2019s important to be explicit about this.<\/p>\n
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\u2019s main goal:<\/p>\n
![\"Example](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2017\/02\/Goals-spreasheet-example.png\")
<\/p>\nAccountability matters<\/h3>\n
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 \u2013 you don\u2019t want teams to become cautious, otherwise they won\u2019t hit any goal. So we don\u2019t expect perfection. Missing goals happens. But teams should feel good about what they\u2019re committing to \u2013 that it\u2019s achievable and something they\u2019d feel proud about delivering in 6 weeks. It should hurt to miss your goals.<\/p>\n
They\u2019re not<\/em> delivery cycles<\/h3>\n
Our planning and commitment timeframe is 6 weeks, but we don\u2019t 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\u2019ll hit your main goal in week 3 or 4. That\u2019s all totally fine. 6 weeks is simply our planning and commitment cadence. It\u2019s our structure to help give the teams the right level of predictability and foresight.<\/p>\n
6 weeks is the Goldilocks of timeframes \u2013 just right<\/h2>\n
Building good software is really hard. You need your processes to support you, not pull you down. We\u2019ve 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.<\/p>\n