It seems like every post I read or every talk I listen to comes with the same big disclaimer: Warning! This thing that worked for my company may not work for you! Sometimes that disclaimer can turn into a reason not to even try. After all, it’s very unlikely the same tactic will produce the same results as it did for that specific company.
The question is, ‘What if it worked for you?’
I’ve been chasing stories from product teams that have been inspired by another company’s practices, have tried them and gotten positive results. For instance, in a recent post I talked to Mark James, Head of Product at Shedd. He was inspired by Basecamp’s way of working, implemented it and iterated it until it worked for them.
At EnjoyHQ, we’ve been through a series of iterations in the way we work. The most impactful so far has been adopting and adapting Burndown from Drift and we wanted to share some of our war stories — what we changed, what was hard and what was great about it. Enjoy!
Why we decided to try Burndown (Drift)?
Before reading Drift’s post and ebook on Burndown, we were already looking for ways to increase the speed at which we deliver value to our customers — not only shipping improvements and new features faster but also making sure the process had our customers at its core.
From the beginning, we used Trello to manage what was being worked on. As one does, we started very lean, with one kanban-style board (standard columns with ‘next up’, ‘in progress’, ‘tested’ and ‘shipped’). Over time our flow spread to 4 boards — Bugs, customer problem backlogs, engineering and big ideas related to jobs to be done.
We were doing a ton of deep and continuous research on the problems our customers were experiencing but when it came to building solutions and iterating on them we were falling into the typical pattern of big bang releases. Features were taking more than one sprint to get into customers hands and that was getting everybody frustrated on all fronts.
We knew we were working on the right things but speed was an issue. During retrospectives, the problems of missing requirements, being stuck on one thing for too long and not addressing technical debt were always coming up but they were never being addressed. We were ready to change.
We needed a way to break down work so that we could deliver small units of value to customers on a daily or at least weekly basis.
After reading about the framework a couple of times we knew we wanted to give it a go. One of the things that resonated with us was that the process embraced a bit of chaos in the system. We wanted to continue changing priorities easily if those changes were driven by new learnings. Burndown encouraged that.
That flexibility is key but your team needs to have a strong understanding of how decisions are made. Priorities can’t be constantly changing due to customer feedback. That’s not what this framework is for. Completely the opposite, in fact. You change priorities because you learnt something you didn’t know when you started working on the solution. If that understanding comes not only from feedback but also testing, in-depth interviews and a mixture of data points then go for it. It shouldn’t be driven by only one data point. This is why continuous product discovery is so important.
How we communicated it to the team?
Firstly, we shared the ebook and told everybody we wanted to test a new way of working (like we’ve done before). We also said we wanted everybody’s input on the methodology — what they hated, what they liked and what they thought was not possible to adapt.
We left enough time — around 2 weeks — for everybody to read and digest the content and scheduled a session for discussion. Once we agreed that it was worth a try, we planned the first sprint using Burndown.
We made sure we were constantly asking our engineers how they felt about it, if there was any confusion or if there was anything they were concerned about. From an implementation perspective, we wanted to make sure we could tweak the framework quickly.
In practical terms, this is what we had to do to test the framework:
We completely changed the structure of our Trello boards — as mentioned before, we had 4 separate boards: Bugs, customer problem backlogs, engineering and big ideas related to jobs to be done.
We merged those 4 boards into one called ‘Current Work’. That exercise was itself extremely helpful. We had to mercilessly kill cards and organise our ideas and insights in a more granular and strategic way. One of the interesting things about Burndown is that it forces you to break down work in a way that helps you deliver against a job to be done incrementally and continuously.
For example, we knew we wanted to help our customers do better segmentation of their feedback. That meant helping them use behavioural data and user properties to filter qualitative data.
This feature as a whole was complex and had a lot potential to become one of those slow big-bang releases. With the previous way of working, we’d break the tasks down but because we were focusing on stages of work (Kanban)and not delivering features to customers as fast as possible. Because of this we ended up with a lot of disjointed cards and no clear dependencies or priorities. On paper it sounds good — your card is in ‘next up’, then in ‘in progress’ and then it’s ‘shipped’ — but when the rubber hits the road, your team spends a lot of time updating the Trello board, shuffling cards and everybody else is stuck with no clear picture of the state of the given feature. We used to keep nagging the team to update the card’ status for visibility but now we don’t. It just happens.
With Burndown we were able to break it down in such way that we could deliver value to users on this specific JTBD in less than a week.
How?
- By defining not only the job to be done behind a feature but also the micro jobs that contribute to it.
- By scoping the feature on a very granular level with multiple engineers. We are a remote team and we did this with calls, Lucid Charts and Google Docs.
- By constantly asking, ‘What can we deliver that will add value to users without having to wait for the entire feature AND can we make that thing go live in a day or two?
For example, a feature will look a bit like this on Trello:
The feature or column is owned by an engineer and others can collaborate as needed. We use labels to specify the status of the small jobs/units of value and that helps other engineers to pick the cards they can contribute to. Once all cards are marked as done we archive the column and move on to the next thing. We can have multiple columns active in any given week and can move columns around if we learn something new and changing makes sense.
As Drift puts it:
“There are cases when we get customer feedback or make a strategic shift that re-organizes our priorities, including cards 1–5. While it may seem chaotic, and it sometimes is, the order of the lists change every single day to keep us working on what matters most. This is the most fundamentally important aspect of Burndown.
The result is a constant focus on the most high-leverage items possible, which enables the team to ship maximum value to customers that align with business goals.”
How long it took us to transition to it?
It took us 3 weeks. Why? We had to get better at scoping and breaking down solutions.
Because we were shipping more and faster, we had to reorganise the way we did research and product discovery so that we could have more interactions with customers. For example, we needed to be able to nudge customers before scoping, during scoping and after initial release. Before we would have those conversations at the beginning and end of the process only. This was not good.
What went wrong or was hard?
The engineering team was used to the Kanban flow. Everybody was working toward moving things to the next column.With Burndown it is not about moving cards to a different status column, it is about owning a feature and doing what is needed to get small units of value shipped. That change meant that for a while, people were confused about what to pick next or when we were “finished” with the feature.
Another challenge was understanding how to balance bugs and technical debt. However, once you’ve committed to a different way of thinking about it, it becomes clearer how to prioritise those. We don’t manage bugs, we address them as they come. Some get done faster, others are planned with upcoming features (if they belong to that product area) but we no longer have a nasty list of bugs that haunts the engineering team. Any new bugs get added to the current sprint.
It’s the same with technical debt. It’s still there of course, but now it’s not the big elephant in the room. It actually gets paid more often as we do it while building new features as well. This is more flexible and less daunting for the product and engineering team.
From the ebook:
"There are a few things to keep in mind here. The most important is that the customer does not care about your tech debt. At all. It is irrelevant for them. Tackling tech debt is often a deep, dark rabbit hole. Something that the engineers pitch as a 2-day thing inevitably turns into a 3-week re-write of the entire infrastructure. We’ve all been there.
Here’s our rule about tech debt — It is only tackled when tied to customer value. Tech debt will not be touched until it is tied directly to a new feature that is being rebuilt”
We’ve added one thing to Burndown which wasn’t mentioned in the framework. Each week we create a ‘shipped’ card in the first column. In there we track which complete features were shipped on any given week by linking to the Jobs To Be Done card. This helps us keep a track of progress and step back during planning.
How do we know it works for us?
Momentum — We ship better features faster.
Less frustration — We get to pay more technical debt without “feeling” that we are taking time away from feature development.
Growth — We are delivering more value faster and that has impacted engagement and retention metrics across several customer segments.
What do you need to make it work?
Here are a few things that we found helpful:
- Committing to the idea that you don’t need a roadmap. You need a customer-driven process that focuses on delivering small units of value to people every day/week. That process is mostly driven by your vision and continuous learning.
- Understanding that this type of change is chaotic and that’s fine. That’s the price to pay for speed and flexibility.
- It will take time to get used to it. Give it at least 3–5 sprints before you decide whether it’s working for you. The transition period was quite painful for us as the old cards were not in Burndown style. This meant we had some un-scoped cards that we knew we had to deal with, monster cards which should have been broken down. Instead, we decided to just get them done and move forward.
- You probably need to be already into JTBD.
- Make sure you have an effective way to do product discovery, anything that can help you do better research, faster. We use our own product to do that but, whatever process you use, make sure it’s strong so you can navigate uncertainty and decisions are grounded on customer needs and not on the rush to get things shipped faster.
At this point you may be thinking… 🤔 That sounds all nice and sweet but that would never work in my business. If that is the case, I highly recommend you check out page 67 (ebook), there you will find a very helpful list of reasons why this may probably work for you too and how to overcome objections from your team.
If you’ve tried Burndown or implemented any other major change to your process, we would love to hear about it. If you’re looking for better ways to manage your customer feedback and customer research, pay us a visit here www.getenjoyhq.com 👋
You can sign up for our blog below.