How We Build Products At Drift (The Burndown Framework)

[

](https://medium.com/@mattbilotti?source=post_page-----7024357d953b--------------------------------)

An introduction to how we build products at Drift

In the world of product management, we oscillate between two ends of a spectrum. Both, not ideal.

On one end, we have the “Quick ship” releases, which are small, highly incremental just-in-time releases. On the other end we have “Big Bang” releases. These are giant, long undertakings that attempt to have every detail thought through and perfectly executed.

There are some major problems with both of these approaches:

• Quick Ship — Although this approach is fast and incremental, two things which we love, it often leads to parts of the original product design and vision being left on the cutting room floor. It’s also hard to know when something is technically “done.” Since it’s being built in small, tiny parts, it introduces new product states that may not have been accounted for in the original design.
• Big Bang — As the counterbalance to the quick ship releases, big bangs are usually slow, long processes that rarely end up as originally intended. Feature and scope creep takes over and the customer is left out of the process for long periods of time. No visible progress is being made in the eyes of the customer, which leaves the business with a lack of feedback on the decisions they’re making. In addition, the time estimates of these releases are almost always underestimated and can drag on for months later than originally planned and budgeted.

With both of these approaches, we end up spending a lot of time playing telephone with each other internally. Things are constantly changing mid-flight which leaves customers, engineers, designers, execs, marketers, PMs, sales, okay you get the point…it leaves them all feeling like product is under-delivering in one way or another. A single source of truth is often lost amongst all the quick changes and long cycles because information about different releases winds up scattered amongst all the different tools PMs use: Jira, Trello, Prod Pad, Slack, internal wikis, etc. We all know how messy it can get.

At Drift, we’re always looking for ways to craft better processes and over the past year we’ve developed a new approach to building software and product.

We call it Responsive Development, which is based on a set of guiding principles that have been battle tested at Drift, HubSpot and Performable for over seven years. It breaks your product development out of the existing spectrum and lets you move quicker, while increasing your ability to focus on the customer.

We believe RD matches the way people want to live and work, and that the outcome is a better, more useful, reliable product that customers adore.

What are the first principles of Responsive Development?

• It’s flexible: It’s based on principles, not rules. Rules are binding. Principles favor progress and forward momentum.
• It’s customer-driven: Always gather first-hand feedback, not second-hand feedback. Get engineers and designers talking directly to customers.
• It’s iterative: The first attempt is always wrong. You must iterate towards the best possible solution, not try to get it on the first try.
• It’s rapid: Speed gives you more iterations and therefore more opportunities to learn.
• It’s incremental: The power of progression and step-by-step improvements lead to better results.
• It’s always evolving: Learning is never done, this is a living framework and will change overtime.
• It favors data over internal opinions: Results should be measurable and more highly regarded than internal opinions.
• It’s focused: Iterations should be focused, self-contained, and with as few dependencies as possible.

Burndown is the framework that Drift uses to employ the first principles of Responsive Development.

There are four critical core values of the Burndown Framework:

1. Getting customer feedback must be an ongoing process — We feel the customer and end-user’s pain and measure customer adoption, usage, & retention on a daily basis.
2. Speed matters — We believe that an iterative model that evolves quickly based on feedback wins. The speed in which we’re executing matters and burndown encourages keeping that bar high.
3. Consistent reprioritization is key — We try to ensure that at any given moment we’re building only what will have the biggest impact to our business’s key results over time.
4. Flexibility is more important than stability — The needs of the customer and the market change rapidly. The framework is flexible to account for constant changes.

Since Agile is the prevailing method for software development these days, let’s see how it compares to Burndown:

The Burndown framework has been battle-tested and used on a daily basis at Drift for over a year and we’ve found the results to be spectacular (and our customers feel the same, too). As a result of Burndown, our team is constantly focused on the customer and we’ve developed a culture where speed matters and flexibility is a foundation of how our business operates.

Is Burndown Right for My Team?

If you’re like us, you put the customer first. Always. At Drift, we’re building tools to make their lives easier and want to make sure we always stay laser focused on that goal.

In order to implement Burndown, you must have buy-in from everyone who is on your team. They need to see the value in speed and flexibility over rigid plans.

The important thing to keep in mind is that the things like roadmaps and binding sprint cycles that come along with a framework like Agile is that they solve for internal process whereas Burndown is specifically built to match what the customer wants. We’re willing to sacrifice the month-by-month stability that comes along with Agile for the speed that comes with Burndown, and you should too.

If you work in a large, corporate environment, adopting Burndown can be tricky (if not impossible). Gonna be brutally honest here…the more process your company already has in place, the harder it’s going to be to switch.

Companies and teams that would be a good fit for Burndown have the following traits:

• You truly care about your customers and consider yourself a customer-centric business
• Your product teams are small and focused, no more than 6 members when including engineers, designers, and a PM.
• You’re building a software product
• You, as a leader within your team (no matter what role) fundamentally connect with the first principles of Responsive Development
• Your company and your product teams value learning and finding new ways to become more productive

Over the next few months, in a series of Medium posts, I’m going to be sharing the gritty details of the tools and processes you need in order to actually implement the Burndown Framework and take advantage of all that Responsive Development has to offer.

Here is post #2 (How to implement Burndown)

Here is post #3 (How to handle bugs, backlog, prioritization, and communication)

I also wrote a full e-book on this topic with David Cancel. Check it out!