Our road to building better product teams

Two steps forward, one step back

This would be my most accurate one-liner of what it feels like to build a company from a three-person founding team to a few-million revenue/30+ headcount business.

And the same is true for the product team where we've evolved from early years of rapid experimentation ("let's try agile", "adopt Jira company-wide", "idea + execution on the same day") to a more stable and well-functioning product development pace which has been paying off.

Break up into three teams🔗

In the last 12 months, we've broken down the product team into three autonomous teams with their own projects and tasks. This meant we had to hire at least four more people for the product team. We still have some open roles.

So now every team has a dedicated product designer and a mix of frontend and backend developers.

Fun fact: our team uses Elvis Presleys song titles: Mystery Train, Tutti Frutti and Hot Dog.

Breaking up those teams was a logical decision to further scale the product team. Many business books mention the 'autonomous teams' approach which certainly feels like the right way forward.

The outcome of this change is that team members work together more closely and are better focused on the projects assigned to their respective teams.

We've also carried through that team split in Linear, where every team has its own space, projects and stories (that have a different prefix). This change has resulted in more collaboration (within teams) and a more predictable pace. Two steps forward!

🔗One step back

But there are some downsides to this approach:

• Everyone stays in the same team. This impacts the overall social dynamics and reduces the amount of information sharing.
• More work to assign and plan issues. Because bugs now belong to a team there is more work in triaging/allocating the right person as one needs to think about which team is responsible for that part of the product.
• Harder to deal with holidays. If a person in a 4-5 person team takes a holiday you lose 25% productivity. That planning is almost impossible if that person is the designer or the only backend developer in that team.

🔗Company challenges

And reflecting a bit more on the recurring problems we've been experiencing as a company I keep coming back to three main areas:

1. Doing too many things simultaneously: Both Jesse and I have a hands-on approach which I believe gets us to start too many things with no clear end in sight.
2. Being founder driven: You must have heard this quote 'going from 0 to 1 million ARR is a lot easier than going from 1 to 5 million. That is because you can get to the first million with a few talented individuals (and you don't need management skills).
3. Working/Overspending on stuff that's not that important: I have many projects that I am 100% sure took us way more time, energy, and resources than we’d ever wanted to spend upfront. Heck, we should have probably never even tried if we knew it would take that long.

And 1. and 3. can kill motivation as team members feel like projects are going on and on with no end in sight.

The company we want to be🔗

We're big believers in "the calm company" approach where teams are given enough freedom and responsibility to plan their own work. In this flat structure, work is organised by the people rather than a top-down command-and-control leadership style.

But while it's easy to hand out copies of 'It does not have to be crazy at work' it's much harder to implement. I have discovered that this is a long-term transformation that touches many aspects of the business: hiring, mission/vision, and most importantly an internal transformation going from management to leadership which are two entirely different things.

Product team reorganisation🔗

I'm not the biggest fan of being too strict about applying so-called "proven methodology". We use a set of concepts from different methodologies where we cherry-pick and adopt the stuff that works for us.

Still, I was pondering how to improve the way we work together and ship stuff within Prezly and I found inspiration in two books/concepts:

🔗Shape-Up (by Basecamp)

Shape-up is a project/product management method by Basecamp with good principles and guidelines on how to work together as a product team.

As software teams start to grow, some common struggles appear:
​​
​- Team members feel like projects go on and on, with no end in sight.
​- Product managers can’t find time to think strategically about the product.
​- Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”
​​
​From Basecamp book Chapter 1: Growing Pains

This spoke to me a lot. In fact, it's a better-written version of some of the challenges I highlighted in the company challenges part. And there are three things I think we should implement within Prezly:

1) Strong focus on scoping (shaping)

Everyone who wants to suggest a change/improvement needs to spend time on shaping/defining the problem well.

In practice, it is mostly senior people or me/Jesse that start shaping ideas. But having an explicit process (shapings documents, betting table) enables us to think about the problem enough and let the team work on the solution (within certain constraints).

2) Circuit Breaker / Appetite

The idea is that every project comes with a certain appetite which reflects how much time/money/resources you want to spend on a problem. Teams get a fixed amount of time to work on an issue; after that, the 'circuit breaker' mechanism kicks in, forcing the team to stop working.

This concept is extremely empowering for the people pitching and shaping the idea.

3) The Betting Process

When first reading the Shape-Up book, I internalised the betting process as some kind of democratic/point-based voting system where the pitch with the most points wins.

But it's nothing like that.

The betting process is more like a conversation that keeps many different aspects of the business into account:

• Who would be the right person to work on this?
• Is that person free right now? Do they have a holiday planned?
• How well does this project align with current business objectives?

These are simple questions to answer individually, but together they create some kind of puzzle that is hard to explain.

In the video, Ryan mentions that the betting process probably deserves its own book which I think is much harder to write as I it's more of an art than a technique.

In the first betting session, I noticed that the conversation creates alignment between leadership. The conversation is not about who is right (because no one knows) but about which experiment we're doing first and how much we want to spend.

Reduce team distractions🔗

You want to avoid any distractions for a team that is allocated to a shaped project. This is critically important as a team accepts the challenge of solving a specific business problem within the provided timeframe (appetite). ​
​​
​But, if you're going to distract that team by assigning P1 issues or allocating them to client todos there is a big chance the whole shape-up method will fail. But then again, some things can't wait.

Quick Reaction Force (QRF Model)🔗

A while back I read a great medium article about creating a dedicated team for interruptions which they call the QRF (Quick Reaction Force).

This model will work well with our Shape-Up experiment as it will ensure we have an available team for interruptions.

The truth is, some things can’t wait. Compliance demands, a new employee onboarding, a large customer’s tiny configuration change — these are activity-generated work that just needs to get done with some sort of time-sensitive cadence.
​​
​From Medium.com - The QRF Team Model

The model that works🔗

By combining the Shape-Up method and the QRF Team Model the structure of the product team will look a bit like this:

I'm confident this combination will address some of the issues raised by the team during the last retrospectives. Additionally, the QRF model might create room to work on essential tasks (refactoring, admin tools) that currently do not get enough attention and might never be planned/shaped.

At the end of each cycle, we form new project teams and move people around based on availability/expertise. I believe this rotation might positively impact team culture and knowledge sharing, but that's all to be confirmed.

I will post back in a few months with better insights.
​​
​Inspiration/Good reads:

• Shape-Up (by Basecamp)
• The QRF Model by Joseph Gefroh
• Linear.App - Method
• Why Squads are a Popular Failure for product teams by Spotify