In a nutshell
The BFS framework gives a common language to prioritize tasks that needs to be done several times per quarter. The main idea is to make those tasks either Better, Faster or Scalable. The concept is simple, but it brings enormous results if applied with consistency. It has the added benefit of avoiding a lot of the early-employees frustration about “having too much to do” after one year into the job.
What is the BFS?
Early startups are made of “one-[wo]men-teams”: individuals that are capable to handle all of the necessary parts of a department. It’s for example the marketing magician than can do SEO, content, ads and webinars, while crafting the new branding, announce your new fundraising in the press, and designing your new goodies.
As startups grow, teams grow, and each team leader’s responsibilities expand. SEO need to be more precise, content must be of higher quality, product marketing comes into play, and… the marketing magician becomes busier. After hundreds of 1:1 with my team leaders, I have noticed a clear pattern: over time, team leaders stack up more and more things on their daily to-do list, and they don’t remove much from it. After a while, the to-do list becomes so bloated that the same conversations pop up in every meeting:
– “I’m overload”
– “I need more resources ($, people, consulting, etc.)”
– “If only we had launched [xxx] 6 months ago”
Sometimes those comments are legit concerns. They can reflect a misalignment between the company’s ambitions and the resources allowed. But most of the time, they come from a lack of anticipation. Thus, I came up with a simple framework to help my team leaders prioritize their projects months after months. I called it the BFS: Better, Faster, Scale.
Following the BFS improves the impact and the scalability of their department over time. By doing so, it’s easier for them to delegate, grow and get to the next level.
How to use BFS?
Easy! Each month, take the list of all the tasks you did and that need to be done again. Then for each of them, decide if you will make them better, do them faster or make them scale. The secret lies into this rule: only pick one adjective per task.
Every task should fall into one of these categories. As you gain experience doing a task, doing it again in the same conditions should be at least faster. If you spend the same time as before, you should be able to improve the quality of the task. And if you want to get rid of this task in your to-do list in the long run, you should spend time making it scalable.
Let’s say you have three objectives in your list on month #1. After doing the labeling, you should have the same amount of time devoted to those objectives in month #2 but split differently.
Does it sound obvious? It is. But as labeling tasks like this may seem simple, you need to clearly know when to choose one label over the others, and how to execute on them.
When to use BFS?
We can put the projects we work on in two categories: run and build. Run are the things you need to do to get your company moving. Not doing them would immediately hamper your growth. Ex: meeting clients, fixing bugs, handling your AdWords campaign, managerial one-one, etc. Run projects are usually in your daily or weekly to-do list and will be done again and again.
Build projects are things that make your company scale. They are the projects you do to make your growth curve as steep as possible. Your Build should improve your Run. Ex: launching a new feature, crafting a new sales presentation, launching a referral program, etc. Build projects are usually harder and more exciting.
The BFS framework is useful to improve your Run. BFS can be used with any project that has already been done at least once.
Faster
Faster is the easy one. Did you prepare your first webinar in 4 hours? Try to craft the next one in 3 hours! One of the common mistakes I see is accepting that doing the same task should take the same time. So, before starting the project, define a time limit. If you don’t, your project will take more time than needed, it’s 100% guaranteed (as stated by Parkison’s law).
If you didn’t know how much time you spend the first time you did it, it’s time to measure! Understanding your time is critical to your productivity (and to your CFO’s forecasts). Using timeboxing or pomodoro will help you. At Supermood, some of my colleagues are religious about using Toggl.
Better
When you choose to make something better, you need to deliberately spend more time than usual on the task. This time will allow you to improve the impact of the project.
Better = focus. As your time is limited, focus on improving only one or two dimensions of the task. Let’s say you chose to make your second webinar Better. You have several options: improving the overall satisfaction of the viewers, improving the number of leads it will generate, or bringing more qualified leads to the show. Each of those options needs different plans. If you try to do address all of the options at once, you won’t make it in a reasonable time. So, pick one dimension, make it better, and you will work on the others next month. It takes time to go deep into something, so be sure to not dilute your focus.
When you “Better” something, be sure to measure it. Define KPIs that measure the incremental value you are trying to deliver. Those KPIs will guide your choices during the task and will give you a sense of fulfilment when the task is done. As a bonus, it makes it easier to display and prove your success to your colleagues and boss.
Try to make KPIs as quantitative as possible, and outcome-based. But don’t obsess over it and don’t over-engineer complex KPIs. A few simple KPIs are always better than 10 complex ones.
From experience, defining what “Better” means for each task takes time. Finding the right KPIs takes time. Confronting your choices with other team members takes discussions. Creating smart dashboards takes time, sometimes a little help from the tech/data guys, and many minutes to define the exact color that fits with your mood for each graph…! 🙂
Take into account this time in your planning
Scale
Scaling means that for a given task, its outcomes can be exponential while the efforts are linear. Scaling comes into a lot of shapes: you can automate a task, delegate it to a teammate, hire someone dedicated to the task, outsource it, decentralize it, etc.
Example: to scale “responding to users demands”, you can create a knowledge base about your product, you can hire someone dedicated to Customer Support, you can automate answers with support systems, you can hire an external agency (bad idea!), or you can do some swarming, where everyone in your company becomes responsible for support.
Scaling something always takes more time than doing it once. The idea is to spend most of the time dedicated to the task to prepare its repeatability, so that the task can be executed quickly later.
Scaling is where most projects should end up. Successful startups are startups that scaled a lot of their operations.
Common mistakes
– Not focusing on one dimension of the BFS. Ex: trying do to “a little bit faster and a little bit better”. That’s the default. And so, you don’t pay attention to the time spent on the project, and you will accept having the same results than last time.
– Scaling things too early, or too late.
– Not accepting to pay the debt.
How to choose between Faster and Better?
From the three options, faster is my least favourite. Making a task in less time than before optimize for only one thing: your personal time. You sure are more productive as an individual, but the group doesn’t benefit much from the gain. Better and Scale do have an impact on the whole company in the long run. So, by default, I won’t go for Faster in my first task review.
That being said, Faster has an extraordinary benefit: freeing your time for more critical tasks. So, actually, most of your tasks will end up in the Faster section.
When the results of a task are not good enough, choose Better. “Doing crap faster only makes thing crappier”. Keep in mind that most projects have tipping points. The success of a project often depends on a minimum level of reach, quality or “magic”. So, by pushing the task further, you may unlock exponential value. Example: your sales presentation won’t close more deals if you don’t reach more leads. So before improving your deck, make sure you have enough leads in your pipe.
Doing things better or faster follow the law of diminishing returns. The further you Better or Faster things, the harder it gets. Takes this into account when you pick between the two options. If your enterprise client meeting lasts for 45 minutes, it will be difficult to compress the timing. You’d better Better it, and make sure to make those 45 minutes more valuable.
One of the most common mistakes I see is to try to Better and Faster a task at the same time. Doing so is the default. Usually, it ends up taking the same time with minor added benefits. Faster means “dumping the task out of your mind as quickly as possible”. Better means “think how you can improve the task’s output”. It’s impossible to think of both at the same time. So, focus on one dimension: either Better or Faster.
When to switch to Scale?
You have many reasons to scale things. Scaling a task often means splitting it into many small parts, test some of those parts, make sure that it works 10 times, etc. So, before scaling, make sure things are good and fast enough. Scaling crap is even worse than doing crap Faster. If your webinar doesn’t generate enough qualified leads and the overall satisfaction is low, do spend more time on it to make it Better. This way, you will be able to highlight the most important parts, get rid of the useless ones, and get to a quality good enough for each moment of the webinar. THEN, when the script is mastered, the audio quality fine, and the landing page converts, you can scale things. Don’t scale everything at the same time. First, scale the landing page and the script. Then, do check that your “Scaled” version gives the same results than the previous one. If it does, continue. If not, go back to Scale.
Make sure to do an RoI-check before Scaling something. Let’s say you have to copy-paste data from one Trello card to the other every day. In average you have 10 copy-pastes to do. It’s boring, so you want to code a small script to automatically link the two Trello cards. Writing and testing the script will take you 1h, from start to finish. When done, you will gain 3 seconds per copy-paste. When will the Scaling be profitable? Well, after 3600/(10*3) = 120 times = 120 days. Was it worth it? Depends. If copy-pasting makes you insane, so yes. If you just wanted to save time: no, it was certainly not.
This last example leads me to another topic about Scale. It’s ok to Scale things not to gain time, but for comfort. Making things faster or easier often leads to more usage, awareness and quality. One of the commons tech dilemmas in early startups is “when to implement Continuous Integration (CI)?”. When the codebase is small, testing the code once a week and releasing after that is totally ok. So, scaling testing may not seem a big deal at first. Actually, it is. By implementing CI, you won’t gain much time at first. But you gain so much comfort: just launch a script and everything will be production-ready. The result: as it’s easier to push a live version of your work → you will change your release rhythm and you will be able to iterate quickly on your product → you can take risks → you innovate quicker à Scaling was 100% worth it. Not because it makes things faster, but because it enables another way to work.
A piece of good advice taken from the book “Lean Analytics” is to draw a line in the sand to scale your project. It means defining at what point you will start to Scale the project, before starting the project.
Let’s say you want to scale “Customer Training”. You know that a good solution to Scale it is to switch from physical training to a video repository available online. You won’t be able to Scale the task right away, as you have absolutely no idea about what customers want in their training. So, you start doing one physical training. Then another. Then another. After your 10th training, you’re pretty sure to have understood 90% of the customers’ needs. It’s time to scale, right? Yes! But what happens usually is that the 11th customer is super important. Or you want to try this one last thing to make the training better. Or, you just don’t have time to invest in Scale, because things got busy. So, you end up doing the 11th training physically. And the 12th? Same old song. Fast forward: you did 50th training before turning them into videos. Even worse: it’s now videos version 1. You will have to iterate on videos version 2, 3, 4, etc. before it’s as good as your training number 50. Imagine how much time you lost between training 10th and 50th. All this time could have been spent to improve your videos.
So, what’s the solution? Plan before training #1 to Scale training after the Nth one. Let’s say 10. Then, when you are at training #10, scale it. No excuse, no exception.
It has many benefits. First: if you have defined the number before, you will commit and won’t be pressured by the moment. Second: it will force you to test many things before the 10th one, so your chance of having a good webinar #1 increase.
Finally, scaling things is a good idea when you are not alone on the project. Scale forces you to deeply understand your task, formalize it and identify the moving parts. Doing so makes it easier to hand the project over to someone else, being a freelance or a new team member.
When NOT to Scale?
If you have an engineering background like me, you will have a natural tendency to optimize everything from the start. So, you spend more time on Scale than on anything else. Even if it feels good, most of the time it’s not cost-efficient on the short and long term.
First, don’t scale when you don’t understand the process and you didn’t go through it multiple times.
Second, some things just don’t scale. Don’t try to automate your Enterprise sale meeting: people are not ready to talk to a robot (yet!). Instead, try to Scale the inner parts of a sale meeting that can be optimized: invoice generation, social proof, etc.
Always remember that by scaling something, you remove yourself from the equation. It means that you won’t spend much time “living the thing” anymore. So, if you delegate sales meetings or webinars, you will progressively lose touch with your leads. It seems ok at first, but a startup employee that loses touch with the customer becomes irrelevant pretty quickly. So, as a CEO, I “scaled sales” by hiring a sales team a few years ago. But I’m still closing deals, not to improve Supermood’s growth, but to keep understanding our customers.
How to use BFS in your growing team
The first rule is: don’t BFS everything. BFS is a super useful framework, but it induces some brain load. You won’t have the time to Better or Scale everything. You won’t have the energy to race against the clock to make things Faster every day. So, use BFS for your most important projects. Repeat the others without any worry.
Knowing this, as a department’s leader, one of your top 3 priority must be to fire yourself out of your job. I love the expression “let go of your legos” (if you haven’t heard of this article, go read it immediately). There are so many legos to play within a startup that you don’t have to worry about having nothing to do after a while. The legos just become broader and more impactful. The problem is: if you don’t use some kind of BFS, you will never be able to handle tasks effectively.
Let’s take two young Head of Marketing (HoM) in an early startup. Both start the department from scratch. They both have 6 tasks to handle in the year. The first HoM want to push the startup hard and see himself has the one-man team the startup needs. The second HoM want to build solid foundations and uses the BFS.
This is what happens 6 months in:
As you see, it’s almost impossible for the first HoM to delegate part of his job. Nothing is really polished or structured. The second HoM tackled fewer subjects (he completely ignored SEA, CRM and Brand), but he can delegate his tasks quite easily. Who gets a chance to become a manager and earned deep expertise?
Bonus: most startups get high growth through only one acquisition channel. So, the further you “hack” one channel, the better. And hacking comes from making a few things Better and Better again, not “spreading and praying” your energy on billions of solutions.
Finally, one last thing that I do want to address, and that could be one article by itself. It’s the mindset to be humble enough to accept to pay our debt.
As a department leader, you may be overworked because your company objectives are too ambitious. But most of the time, it’s just that you didn’t spend enough time to use the BFS. You didn’t spend time to Scale your department, and so “working debt” accumulates. After a while, you have to pay this debt. And paying debt has always a hard cost and requires hard work. Worse: the more responsibilities you have in a company, the more expensive the debt is. So, don’t complain only about your company crazy ambitions or about the lack of resources. Be humble enough to pay the debt.
And it’s ok. Everybody pays debts. It’s impossible to have a perfectly fluid growth. So, don’t blame yourself too harshly, pay your debt and use the BFS. 🙂
Musing 