One of the most common questions we hear about Make Time is: How can I use this with my team? We can help you find your own answer in our Make Time At Work programs, but we know it’s valuable to read stories of how others have done it.
Earlier this year, we worked with Bothrs to develop the Make Time App. (Check out the whitepaper for more about that project.)
As I got to know the team, I was struck by how effective and focused they were — and how calm they seemed, despite moving quickly in a client-oriented business where responsiveness is expected.
When we were wrapping up the project, I asked Stef, the co-founder of Bothrs, if I could interview him. Fortunately, he said yes, and I’m happy to share our conversation with you below. Stef shares a ton of good lessons in this short back and forth, and I hope you’ll take away some ideas you can try with your team.
JZ: What’s unique about Bothrs’s approach to designing and building products?
Stef: Everyone wants to do things better or faster. And, as ambitious as we are, Bothrs aims to do both. The secret ingredient to being better is a lot more obvious than you’d think, and it’s really as simple as not shying away from repeatedly asking your end users what they want, or how they feel about something. You’ve got to do this as early as possible, that’s the real time saver. Validated learning, we call it. Think of it this way: how will you build better digital products if your target audience’s needs and wants are completely alien to you? Creating something you think your users want, will inevitably backfire. Remember Quibi?
One thing that’s key to blasting through design and development, is the type of team that’s putting in the work. Small and cross-functional, that’s the way we like it. Size matters, because the smaller the team, the less overhead. The cross-functional part is equally important. You don’t want certain skills to be locked away in another department, and you need a wide enough array of perspectives to prevent leaving any stones unturned. Couple that with a radically customer-centric approach to product design and you’ve got a winning formula as far as I’m concerned.
JZ: Are there specific processes or frameworks you use as part of this approach?
Stef: Definitely. Bothrs itself is quite literally an amalgamation of ideas and methodologies presented by a handful of books. There’s no shame in that, in my opinion. If anything, more people should do the same; sticking with our own reasoning tends to give us pretty horrendous tunnel vision. That said, both Make Time and Sprint are ingrained in our way of working, like, down to the bone. But the core process we apply to basically any stage of the product development process, is the concept of sprints.
It all started by trying out the Design Sprint. We learned it was actually possible to validate something as crucial as a business concept, or core features of a product or service in a literal week. A week! This is what excites clients the most, every time. Given its success we figured, why not apply this week-based process to the entire roadmap of a project?
So we ended up fabricating:
- Strategy Sprints: Sometimes, it’s a little too early for a Design Sprint. The team on the client’s side might not always be aligned enough to willingly focus on a single project. This week is about getting everyone on the same page and prioritizing challenges.
- Prototyping Sprints: This one’s about validating technical assumptions: we spend a week to roughly piece together all the technical parts needed for the project to function. Kind of like a Design Sprint for your back end.
- Execution Sprints: We broke down the development process that’s ultimately set to yield an MVP in separate weeks. We set our highlights for each week and end things with a client demo, to keep everyone energized throughout the entire development cycle.
- Growth Sprints: When your product is already out in the open, but you’re looking for ways to spur additional growth. Unlike just throwing things at a wall and seeing what sticks, we start from a service blueprint to create and launch targeted marketing experiments.
As you can imagine, this somewhat unorthodox approach can get pretty hectic, pretty fast. Both for clients to adapt to, and for our own designers and developers as well, given how little leeway deadlines tend to have. So we spend a considerable amount of time creating templates for documentation that needs to be drafted for each project, and boilerplates to prevent our developers from having to reinvent the wheel over and over again. To clarify, a boilerplate a piece of code that can easily be repurposed across projects.
JZ: When we first spoke, one thing that amazed me was how you’ve taken the Make Time framework and applied it across your entire company. You don’t just have individuals using the tactics; you’ve adapted and embraced the ideas at a team and company level. Can you explain the details of how you do that?
Stef: Like I mentioned before, Make Time is an equally important framework for us; it’s basically how organize ourselves. The productivity boost you get out of it, comes from the focus it creates, and Bothrs applies the concept of highlights pretty much on every level. Each year, we set clear goals and focal points for the company, which then trickle down to our quarterly OKRs. On a monthly basis, we’ve got what we call chapter goals as well. A chapter is basically a group of people sharing a similar occupation within the company. The idea there is to share expertise and improve internal processes. Beyond that, our teams also set their weekly highlights. Finally, our daily stand-ups make sure everyone remains accountable for their own weekly highlights.
JZ: When I talk to folks working in client-service businesses, they’re often frustrated with the need to be ever-present, always online for their clients. How does Bothrs deal with that? What I’m asking is, how do you balance client responsiveness with your mission to deliver high-quality work quickly?
Stef: Great question, and this is something we’ve been working on since the beginning. In short, the current plan is to batch work our client support obligations on Fridays, to provide some much-needed headspace for our product managers who are essentially scrum masters of their respective teams on top of everything else as well. Though there’s one thing we can always guarantee to our clients: whenever you’re in a sprint week with us, our focus lies solely with your project for that week. Because we all know incessant context switching is god-awful.
That said, it’s true things can quickly devolve into micromanaging all the different channels of communication. It’s easy to shoot someone a message on Slack, but at the same time it’s also very easy to break someone’s concentration by doing so. Which is why we focus more on asynchronous communication. This is where we leverage our templates to eliminate guesswork, and enforce our best practices.
Make no mistake though, our product managers still get a ton of emails from previous clients amidst other projects. We get that people want to stay close-by and have us continue to support their product, but in all honesty, it’s a huge time-sink for our PMs. Which is why we’re building a support hub of sorts to make it easier for people to get what they need, when they need it. Also, to really comfort our clients after a project is completed, we’re currently devising a Handover Sprint. It’s a final week of focus to make sure the client has everything they need to take back full control of their project.
JZ: What advice do you have for teams who want to spend more time on the work that matters, and less time on the stuff that gets in the way?
Stef: What became really apparent early on, was that weekly highlights don’t work on a team level if you can’t hold each other accountable. And arguably the quickest way to do so, is by giving the most direct feedback possible. Radical candor. Care personally, but challenge directly; that sort of thing. If someone keeps distracting you via Slack, for instance, you can and should be upfront about it. Remind that person what really needs to be done that week. Like, don’t be rude about it, but make it apparent you’re not just messing around either.
Check out the Make Time App to see Bothrs’s work in action, and download the whitepaper for the story behind the work.
