Two Day Sprints: Converging on a Product People Love
Week 2 of YC’s Startup School focused on “Building Product” and more specifically on building a product people love. My co-founder Travis and I struggled and failed for four years trying to build something people love and when we finally did I realized that making a product people want is an impossible task but converging on a product people want is possible.
Over the past eight months, we’ve used Two Day Sprints to converge towards a product that people love with Sunsama. I wanted to share the story that inspired us to try Two Day Sprints and also show you how you can implement it with your team.
Four Years of Products People Didn’t Want
Travis and I spent four years building five different products in the time/calendar/productivity space. Up until this year, we used a traditional product development approach with longer sprint cycles and long roadmaps of features sets that we’d tackle for months.
Last year, we’d built a collaborative meeting documentation and management tool with lots of features. A few months after launch we struggled mightily to grow our user base and revenue. There were no tricks left up our sleeve to grow it. It was obvious, we hadn’t built something that people wanted. With just a few months of runway left, we had two options: shut down or try and build something people want.
Through the years, Travis and I had talked to hundreds of users. We’d looked at their calendars, learned about their workflows by shadowing them at work and sitting in on their meetings. We felt uniquely qualified to build something that would make our fellow knowledge workers more mindful and productive with their days. There were a lot of adjacent problems in our space that we thought we could tackle. We kicked off our new direction with a five day Design Sprint. At the end of our five day design sprint we had a handful of ideas on what to build next. But, we didn’t know which of these ideas would be the most successful and our team was deadlocked on which what we should build next.
And that’s when the Two Day Sprint was born. We weren’t sure which of our ideas would really stick so we decided we’d continue with the rapid iteration cycles we’d loved in “Sprint” but instead of mockups and prototypes we would ship product in Two Day increments. We picked two days because we could easily bail out a feature after two days if a certain feature didn’t pan out, we could try out a bunch of different ideas and would only need to wait a few days to find out which ones worked (instead of weeks), and it forced us to break down big grand ideas into features that we could build in just two days (critical given our shortening runway).
Launch your product when it’s better than what’s out there — Paul Buchheit, creator of Gmail.
So off we went for our first Two Day Sprint and what we came up with was the first iteration of the “Daily Kanban” in Sunsama. You can only build so much in two days and as a result it didn’t do much and it was missing most of the features it has today but it did one thing that didn’t exist: it let you organize tasks on a day by day basis alongside your calendar.
In order to get it in front of users as soon as possible we launched it right within our meeting documentation tool that we’d been working on. We quickly noticed that our top power user from the meeting documentation product started using this new Daily Kanban feature more than any of the feature he had originally paid for! We were on to something! So we continued working with our existing user base one Two Day sprint after another. About 8 sprints in we launched on ProductHunt and things started taking off!
Why Two Day Sprints lead to a better product
Two days is not a lot of time. You might say “I can’t build anything of consequence, that’s actually reliable and not filled with bugs in two days”. I want to highlight a few reasons why Two Day Sprints will minimize the impact of mistakes, maximize agility and learning, and compound into a “product improvement engine” that make you converge on a product people love.
One Sprint, One Quantum of Utility.
“it’s often better not to aim for perfection initially. In software, especially, it usually works best to get something in front of users as soon as it has a quantum of utility, and then see what they do with it”
— Paul Graham, Do Things that Don’t Scale.
The goal of each Two Day Sprint is to build and ship a “Quantum of Utility”. The Two Day Sprint forces your hand, there’s a lot of stuff that you cannot build in just two days, but there’s a lot of hard ideas and features that can transformed or broken into something that your users can use and can be built in just two days. In fact, when you have to build something in just two days it’s easier to bring something new into the world that has never existed than to build a feature that exists in another product that comes with all the baggage and extra work of meeting your user’s pre-existing expectations.
Here’s a few reasons to try Two Day Sprints:
Enforce Simplicity with Two Day Sprints
“most hard ideas can be restated as an easy idea if you just understand what bits of your hard idea are both useless and hard. And most of the time there are useless and hard bits in hard ideas that can just be removed.”
— Michael Seibel, Building Product
As a matter of necessity, you’ll be forced to build something simpler than what you’d initially imagined. This has two effects. First, you’re building something simpler, which means it gets done faster, it is less prone to bugs and is probably less confusing to your users. The second order effect is the creativity and focus that it generates. After a few weeks of doing Two Day Sprints, you’ll get in the habit of rethinking user requests and feature ideas as things that your team can build in just two days. You’ll also become a really sensitive bullshit detector. When you only have 14 hours to ship an entire feature, you can’t tolerate any incarnation of fake work creeping into your day; or you just won’t ship on time.
Take more shots on goal with Two Day Sprints
Even if you start the way most successful startups have, by building something you yourself need, the first thing you build is never quite right.
— Paul Graham, Do Things that Don’t Scale
Eventually, you’re going to make bad product decisions. In the world of Two Day Sprints, you are only penalized two days in dev time when you make a bad product decision. For example, we spent a sprint cycle building a Github Integration in Sunsama. Personally, I thought users would love this feature and that we’d keep piling on those “quanta of utility” in subsequent sprints. Well it turns out, lots of people used it but very few people felt very strongly about it. So we stopped after one sprint. If I had gone with my original intuition, I’d have totally overbuilt the feature and put two weeks into it instead of 2 days. So we ended up winning on two different fronts. First, we didn’t spend time building extra features into our Github integration that people didn’t need. Second, because we were forced into a 2 Day Sprint, we built the simplest possible integration that our users needed.
The flip side is that Two Day Sprints give you a safe space to experiment with product features you aren’t sure about. It’s okay to proceed with uncertainty. Unfortunately, figuring out if something is truly a “quantum of utility” and “something people want” is more art than science. But if you’re only going to lose two days taking a shot on something that might make your product significantly better— why not?
The longer your development cycles are the more pressure you’ll feel to build things that you’re sure will work. If you’re honest about the fact that you don’t actually know what will work, then you’ll want to optimize for a system that allows you take more shots to find what actually work and what doesn’t.
Create a responsive and open minded culture with Two Day Sprints
“To do this cycle right, you have to get very close to your users. Literally watch them use your product. Sit in their office if you can. Value both what they tell you and what they actually do.”
— Sam Altman, Startup Playbook
Let’s say your product team is busy building “Feature X” for the next two months and during that month you learn from your sales team that “Feature Y” is the thing that is going to convert your free users to paid. If you’re using Two Day Sprints, you can re-evaluate what you’re going to do every two days. That way, no one has to be the gal who demoralizes the product team by telling them to stop everything they’ve been working hard on for the past two weeks and to work on something else.
When your whole team knows that they could be working on something totally different every couple of days, they’ll be psychologically ready and less resistant to accommodate what you’ve learned by talking to users.
Make reliable and predictable progress with Two Day Sprints
Two Day Sprints lead to reliable development cycles and estimates. Most people have no idea what they can and can’t build in a two week sprint, and the longer the sprint is the more feature creep and unknown unknowns you deal with. I find, roughly speaking, the tangibility of time decreases exponentially with the size of the time horizon in question. e.g. I have a pretty clear idea of what I can accomplish in 2 hours, but I’ve got no idea of what I can accomplish in 2 months. When you kick off a 2 Day Sprint it’s easy to think about what you can actually build in that 16 hour time frame. As a result, you start with a concrete idea of everything that you’re going to build and saying no to feature creep becomes trivially easy — because even a meeting to entertain the idea of a creeping feature could eat into 7% of your time to ship the feature.
As a short aside, I take issue with the adage “time is our most precious resource”. It’s an obvious statement that provides little wisdom on grappling with this “precious resource”. Instead, I think it’s more useful to say “time is an intangible resource”. With that in mind, you’ll naturally start looking for ways to make your time more tangible and as a side effect you’ll make the most of that precious resource. One of my core motivations for building Sunsama is to build a tool that helps us make time feel more tangible.
Long Term Success with a High Frequency “Product Improvement Engine”
“You want to build a “product improvement engine” in your company. You should talk to your users and watch them use your product, figure out what parts are sub-par, and then make your product better. Then do it again. This cycle should be the number one focus of the company, and it should drive everything else. If you improve your product 5% every week, it will really compound. ”
— Sam Altman, Startup Playbook
Sam Altman says “product improvement engine” as the only viable long term strategy for growth. The idea being that improving your product week after week will compound into big gains over time.
He goes on to add, “The faster the repeat rate of this cycle, the better the company usually turns out.” And if nothing else I’ve said convinces you to switch to Two Day Sprints, hopefully this idea of compounding product improvements shows you why short sprints are valuable in the long term.
Altman is invoking the concept of compound interest but instead of money he’s talking about your product (and hence your company). A quick look at the equation shows that the repeat rate is really the only quantity that you truly have control over manipulating (and perhaps ‘r’ to some degree).
Implementing Two Day Sprints
So maybe you are sold on this crazy idea and are wondering, how do I go about implementing this. Fear not, in my not so shameless plug for Sunsama, I’ll show you exactly how to organize your team’s Two Day Sprint Workflow inside of Sunsama. If you believe written words are going the way of the dinosaur then check out this video instead of reading further.
Cadence
Our cadence is as follows: Two day sprint on Monday and Tuesday, another two day sprint on Wednesday and Thursday and a mini-sprint/bonus day on Fridays.
Step 1: Sprint Planning
We kick off a sprints on Monday and Wednesday morning. Our meeting is at 9 AM and usually lasts 30 minutes. In Sunsama, I’ve created a meeting that repeats on Monday and Wednesday at 9 AM, and I’ve applied the “Sprint Planning” playbook so that we can get a jump start on our notes.
The meeting is simple, we start with a quick discussion of any open issues and also jam on possible ideas of what we could work on during this iteration. We try to come to an agreement at a high level of what we’ll work on this iteration and who will be responsible for each item. Next, each person is responsible for splitting that out into more granular tasks that they place on their Daily Kanban board.
Step 2: Progress
We don’t do daily standups. For one, there’s only one morning between kickoff and ship in a Two Day Sprint. And second, everyone’s progress is self evident in Sunsama. During the day, I can scroll down a column or look in the calendar to see what tasks have been completed or what commits have been made. Additionally, each morning, I can look at my colleagues column from the day before to see what they got done.
In Sunsama, we’ve configured automated stand-ups in Slack. Every morning, we get a quick overview of what everyone accomplished yesterday and what everyone’s got on their plate for today.
Step 3: Sprint Retrospective
On Tuesday and Thursday afternoons we’ve got another recurring meeting also set up with the “Sprint Retrospective” playbook. This meeting is quick and fun. We review our goals and give very high level updates, a quick demo of what we built and then decide if what we’ve built is good enough to ship to production. If so, we do it.
Bonus Day
We think of the bonus day as a mini-sprint where we build and ship something (or fix bugs) in a single day. Our other rule, is that you can do anything you want i.e. the rest of the team doesn’t need to voice their opinion on this.
This is our way of prioritizing our own intuition and letting one another experiment with improving the product without trying to build consensus.
During the week as I encounter customer feedback, requests and bugs in Intercom I create a stack of work to do on Friday. It stays out of sight as I’m focused on other things during the sprint but once Friday rolls around it’s already at the top of my list.
Two day sprints make you change how you think about making a product people want. I hope you can skip the years of failure and implement a process from the get go that helps you converge on making something people want.
Why Not?
There are cases where performing two day sprints won’t make sense. I want to highlight a few of the costs and downsides to this methodology so you can decide if it makes sense for you or not.
Also, it’s important to mention that we’ve only attempted this with a really tiny team of two to four people. I can’t honestly tell you how it would scale as your team size grew beyond ten.
Burnout
The most obvious downside is that it leads to fatigue. About 10 sprints in we started realizing that we were on the verge of mental burnout. In those 10 sprints we’d accomplished a lot but pacing is important.
If you want to stick with two day sprints here are some ways to mitigate the burnout.
- Take every or every other Bonus Day (Friday) off entirely. Don’t worry, if you’re doing two day sprints you’ll get a lot more done even with the days off.
- After 6–8 sprints, spend a full week off of the the cycle. Knowing that you have the whole week to get something production ready feels like a lot of breathing room after two day sprints.
- Only use two day sprints when you aren’t sure what you should be building and agility is important.
Quality & Technical Debt
In doing these sprints, we’ve shipped a couple of features that I’ll call imperfect. On the whole, I think this is okay because you can use subsequent sprints to improve a certain feature that you rolled out.
With only two days, there’s also a lot of pressure to ship. So there’s pressure to take shortcuts. It all depends on your situation — when we first implemented two day sprints our choice was between accruing tech debt or our startup failing. In that case, it’s obvious to choose staying alive. You’ll need to evaluate your unique situation yourself.
Senseless Sprinting
We ran into a couple situations where after a stack of sprints we continued sprinting without a clear direction of where we should be sprinting. Speed of iteration is no good if you aren’t taking the time to occasionally pause to process what’s happened and incorporate what you’ve learned from users.
Slow Down
To avoid the downsides, I’d say simply: take breaks. You’ll need to figure out the cadence that makes sense for your team. Some simple way you can do that: take the occasional (or all) Fridays off, split your week by moving your bonus day to Wednesday, and after a 4–8 sprints take a week to re-group and catch up.
Challenge
If you’ve read this far, let me end with a challenge: For the next two weeks, run two day sprints with your team.
I want to hear how it changes how you and your team think about product. So please e-mail me at ashutosh [at] sunsama [dot] com to tell me what you learned. If you take me up on my challenge, feel free to use any tools you’re comfortable with, but if you do use Sunsama for it, I’ll be happy to hook you up with some account credits so you can do it via the Pro plan!
