We're all familiar with the constant stream of app updates waiting to be installed. And seemingly every description includes something akin to the Silicon Valley colloquialism, "Bug fixes and performance improvements."
Each individual update doesn't seem significant, and perhaps one update alone isn't all that groundbreaking. But the regularity with which these updates appear is more important than you might expect.
During Facebook's early days, their internal motto "move fast and break things" leaked out into the wider parlance of the tech scene as companies began embracing a rapid pace of iteration and evolution. This modern-day industrial revolution had a number of residual effects.
It forced industry incumbents who had been stagnate for years, even decades, to reinvest in R&D (or risk becoming obsolete).
It caused consumers to expect a new version on a regularly scheduled cadence (and get upset when it's delayed).
It sent a message to the torrent of starry-eyed founders: never slow down.
And so companies learned to ship. No matter the economic or political landscape, no matter the market readiness (often to their detriment), no matter snow nor rain nor heat nor gloom of night, they shipped.
By being forced to ship on a deadline, you learn to break down larger features into bite-sized increments.
By being forced to ship on a deadline, you shorten the feedback loop. If you build and ship an early version of something in two weeks, then it's live and you can get real user feedback to iterate on it as opposed to building and shipping a more refined version in six weeks and now you're four weeks behind on user feedback.
By being forced to ship on a deadline, you're practicing "done over perfect" which allows you to consistently improve while and not get hung up on the little things.
By being forced to ship on a deadline, you don't stall out deciding which ideas to work on. You know that in two weeks, you'll be able to reevaluate and work on something new.
By being forced to ship on a deadline, your customers come to expect that bugs will get fixed quickly. They're less likely to give up on you if they see you actively listening and taking action on their complaints.
Shipping on a regular cadence is surprisingly difficult. Deadlines alone can be hard to hit. That difficulty is only compounded when you factor in the coordination of research, design, engineering, quality control, product marketing and sales teams. How you structure your Product Development Cycles (PDCs) is a foundational step toward easing the burden.
Earlier on in a company's lifespan, you can get away with much shorter PDCs.
One of the co-founders of Twitch, Michael Seibel, was part of a startup called Socialcam which shipped in two-week cycles.
"At Socialcam we were building for iOS so we settled on a two week cycle, which allowed us to thoroughly test before releasing to the App Store."
—Michael Seibel, (link)
At Check, we're early stage enough to also maintain a two-week PDC. With only a handful of team members, we can hash out problems and make decisions quickly. We try to finish testing on the Friday of the second week and release the following Monday evening.
Finishing on Friday allows us to finish out a cycle at the end of the week which naturally makes you feel more accomplished going into the weekend. But we don't push the release until Monday evening for two reasons:
As the company grows, more people are added to the team and more complex features are added to the roadmap, the cycle may lengthen a bit to accommodate the additional friction introduced to the process. Companies like Basecamp, Intercom and Buffer ship in six-week cycles.
"Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely."
—Basecamp, Shape Up (link)
"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."
—Intercom (link)
"Six weeks gives us enough time to build something useful and high-quality and provides enough of a definite time limit to force us to be smart about our priorities and make necessary tradeoffs. The six-week cycle is a focused cadence of work, not a sprint, so it worked well with our value to “work smarter, not harder”."
—Katie Womersley, Buffer (link)
When deciding on a development cycle, you want to optimize for a few variables:
What type of product are you building? Hardware will have longer cycles than software. Mobile apps will have longer cycles than web apps.
What are your competitors doing? Are you able to outpace or keep pace with them? You can't always use competition as a guide (eg. Apple releases features that Android has had for ages) but it's a good variable to consider.
Plans change quickly. You need a time frame that allows you to adapt quickly as well, so the next sprint can't be months away.
Visible progress to customers. It's beneficial if they see you consistently improving and listening. Not only will they be more forgiving with bugs and feature deficits, they'll also become more loyal because they believe you will actually listen to what they are saying.
Visible progress to employees. Craft your PDC so that it's short enough to keep team morale high. As employees, we all want to feel like we are innovating and evolving the product. So if we're stuck in a 3-month development cycle, it can get discouraging.
Consider the size of the features that you want to build. Typically, if you can tackle one really large task or a couple medium-sized tasks in a sprint, you're working in the right time-frame. If you can barely complete a medium-sized task, lengthen your PDC and if you can complete multiple large tasks, shorten your PDC. Anything that is so large that it would potentially take multiple sprints to complete should be broken up into smaller components that can each be a focus of a sprint.
Why is shipping cadence such an incredible indicator of product success? Because it fundamentally changes the way a company develops a product. It forces you to listen to users, work quickly, be decisive and make something real for the world. Those principles are embedded in the DNA of all successful companies. Shorter, consistent Product Development Cycles act as a catalyst that forces companies to embrace these principles sooner rather than later.