How We Build Products At Drift (The Burndown Framework)

An introduction to how we build products at Drift
  • 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.
  • 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.
  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.

Is Burndown Right for My Team?

  • 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

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!



Product Manager @Drift. Always learning. Sharing some of what I already have.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Matt Bilotti

Matt Bilotti

Product Manager @Drift. Always learning. Sharing some of what I already have.