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.
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.
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.
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!