As workers of the digital industry, we are constantly looking for new ways of doing things. And not only in the technical or design field: we like to find the most efficient way of solving problems, even if it means disrupting all that we were used to every 6 months.
In my case, since my arrival as Product manager at iAdvize 3 years ago, we’ve completely rethought the organization of our Research & Development team 5 times.
Today, I want to share with you our last experiment in this endless journey towards the most efficient way of building a good product.
We’ve called it Product Swarms!
Why did we need to rethink our organization model?
We are at a decisive moment in our company history. We are 5 years old, have a strong investment and growth strategy, big challenges ahead and a great trust has just been placed in our teams (we just raised funds).
As a product team manager evolving in a fast-growing company, my focus is to find ways to scale our innovation. It means recruiting passionate people with potential and creating the best possible working environment so their talent can be expressed to the full.
More specifically, here’s what we wanted to improve:
- Adopt a scalable organization that will adapt to our company growth
- Give more autonomy to our team
- Empower people in order to help them grow and make sure they will have a direct impact on the product, regardless of their mission
- Encourage the expression of bottom-up ideas, and therefore innovation
Note: there are certainly thousands of different ways to address such topics as a team. The Product Swarm concept is just one experiment :)
What is a Swarm?
Let’s start with a simple definition:
A swarm is a group of animals that aggregate and travel in the same direction.
Nature is a wonderful source of inspiration.
Just replace the word “animal” with “people” and then you can catch sight of a great foundation for a new organizational team framework.
Our definition of Product Swarm
It’s a small, autonomous, and highly motivated group of people focused on one single strategic goal, with a clear deadline.
At iAdvize, each Product Swarm:
- is an aggregation of highly voluntary people (people choose their swarm)
- is focused on achieving a strategic company goal
- reports on 1 single KPI
- proposes its own roadmap (reviewed on a monthly basis)
- is ephemeral (once the goal or deadline is reached)
- is self-organized (can choose its own work methodology)
- has no unique leader but well-defined responsibilities
The people who compose a Swarm
We want to keep things simple and agile, so we established a maximum of 10 people per Swarm, including the following roles:
- 1 Product manager: detects customer needs, communicates it to the Swarm and proposes a roadmap to address it. Also measures success or failure.
- 1 Product designer: solves customer needs with a finely crafted design.
- 1 Lead developer: coaches developers toward the achievement of their goal, estimates complexity and formulates planification hypothesis.
- 2 to 7 Developers: build, test and celebrate the features we ship ✌
We worked hard to define each role, trying to impulse a team spirit which is basically based on trust & clarity. But we also believe that every member of a Swarm must have a strong impact on the product. To achieve this, porosity and constant communication between these different roles should be fostered.
Fun fact: less than 2 weeks after we launched our first Swarms, @cap published a great post about “the Ownership Problem” which is clearly worth the read, if your job has anything to do with one of the roles mentioned above.
We also have helpers in our Product team. Helpers are not part of a specific Swarm, but are in fact part of every Swarm. Their mission is to help every team to reach their goal, by delivering their expertise to anyone who needs it.
Today, we have 2 kinds of helpers in our team:
- Data scientists
- System engineers
Each Swarm can choose its own work methodology, but a lot of people still use scrum with 1 to 3 week iterations.
In order to maintain good levels of communication throughout the entire team, we’ve established some key moments that are shared by everyone:
Daily standup meeting
Having a huge daily standup meeting with 40 people doesn’t make any sense. Instead, each swarm sends one reporter who represents his team in a classic standup mode.
It implies that each Swarm has previously synchronized itself before the global standup, with another meeting or via messaging.
Timing: 15 min
Weekly internal demo
Every Friday, each Swarm gives a demo of what they have accomplished during the week, in front of the whole Product team. Candies & applauses are welcomed.
Timing: 30 to 45 min
Monthly corporate demo
Our big show! The Product team invites the whole company and presents every major product evolution that has been released, communicates some key product usages and talks about the next things coming.
Timing: 60 min
Monthly roadmap review
The Product managers and Lead developers of each Swarm synchronize their watch with the VPs of Product and Engineering. Mostly, we discuss roadmap decisions, talk about the challenges that we will have to deal with in the next months, but also about the progression of every Swarm goal.
Timing: 60 min
Every month, the Swarms stop working on their main goal, and treat transverse topics instead, during 3 days. By transverse, we mean global improvements, popular customer requests, or some important refactoring that is not directly linked to a Swarm goal.
Timing: 3 days
How are goals set?
Our product vision reflects the company vision.
The Swarm goals are impulsed by the VPs of Product and Engineering, based on the input we receive from our customers, our product team or anyone who is in direct communication with our users (Sales, CSM, Marketing, Support, Training…).
Each goal has a clear deadline, generally within 2 to 6 months.
Before we launch a new series of Swarms, each goal is reviewed by the company board. Thus, the top-management is aligned with the Product Swarms priorities, which is a key success factor of this organization.
Sales people must share common goals with Swarms. And the same goes for Marketing or Customer Success teams.
How did we build this framework?
We were also influenced by our common reading about how great teams perform (ie: Google, Spotify, Intercom, …) and had precious feedbacks from some brillant managers who are working at Twilio or Dropbox.
But in fact, the three of us only drew the basic concepts.
We took our Product team outside the office for a whole day, showed them the big picture, and together we built every detail of the new framework.
In fact, I am convinced that if you are a manager and want to rethink the way you work as a team, the only way is to talk about it with your team. Let people engage discussions, help them formalize it and you will learn a lot and see great ideas happen.
So what’s next?
There are a few things we want to test in the next iteration like letting the Swarms set their own objective, or testing wider goal like “improve company’s MRR” and see what happens!
Maybe we will also create some new helper teams in fields like User research in order to make our product management more efficient.
However, we’ve only just started our first Product Swarms. For now, let’s just them accomplish great things!
NB: We are hiring new talents!
If you want to join one of our Product Swarms, you will be happy to know that we are hiring in almost every field:
- Product manager
- Product designer
- Backend engineer
- Frontend engineer
- System engineer
- iOS engineer
- Android engineer
Just get in touch!