If the company you’re in is doing well then it will expand eventually. Maybe it’s already in the process of expanding…

True growth means that your R&D is also expanding, because at the end of the day – someone needs to build what everyone is talking about or promising to the customers.

If it’s your R&D team/group which is growing then it’s great news! However, it also means you are going to be busier.

Now, growth could mean several things for you, depending on exact ‘position’ on the product leadership ladder. Let’s discuss the various scenarios.

What expansion means to non product leaders

If you don’t have subordinates and you are not considered part of the product leadership (yet) then things are simpler – there is a certain amount of developers you can handle, and above this number – your boss will need to hire another product manager to handle the load. 

The industry standard for how many developers to associate with each product manager is about 4-10 (of course there are exceptions but 99% of the scenarios fall within this range).

The exact figure depends on many parameters, but I’d say that from my experience 9-10 is quite high for most practical scenarios and configurations. I mean, if you are both talented, experienced and productive you might indeed be able to deal with 10 developers. However, how much time will you really have to ‘get your head above the water’? To think a bit ahead of what’s right in front of you? To meet customers? To spend some time ‘in the market’ and learning the trends?

Not much. Trust me.

You’ll probably do a much better job if you have 6-7 developers assigned to you, because, again, not everything is about producing specs and working items.

That’s most of what you need to consider if you are not a product leader in your organization. I am saying ‘most’ because we still need to discuss the product designers and the product data analysts who are associated with the product team as well. We’ll reach it in a second.

When you are product leader

If you are a product leader, however, things are getting a bit more complicated, because you’ll need to put some more thought into how it’d be best to construct your product team.

The ratio mentioned above is the basic guideline as for whether you need more product managers in your team or not. However, it’s far from being the sole consideration.

When should you start thinking about expanding your team?

The product strategy you are working according to should provide vague hints on when and if such a growth is expected down the road. Your roadmap, however, is a much better indicator of when this should actually take place. It may be that you’ll reach it a quarter later than originally predicted – but it’s there nevertheless and you should plan for it.

It’s quite rare and usually indicates ‘thinking too small’ if your roadmap doesn’t indicate modules and expansions which will involve additional developers, so let’s assume that this is not the case.

What may put your plans on hold, however, are budget constraints or change of focus. As for a change of focus (when the management decides to stir the ship to another direction) – this is out of the scope of this post, as this requires many changes on your side and not just the size of the team. We’ll deal with this in the future.

However, budget constraints are more common and therefore you should monitor this topic much more closely, especially if your company is fundraising.

You see, whether your company is in the process of fundraising or it’s a well established company with recurring revenues will have a tremendous effect on the point in time when such expansion takes place.

On the first scenario – two things need to happen:

1. The company secured the funds successfully
2. Your team is about 3 months from the point in time where you need a bigger team according to your roadmap.

In the second scenario, when the company is well funded, it’s mainly up to your team and how well you are making progress according to the roadmap.

So going back to the original question and answering it – you should have your hiring & expansion plans ready at least a quarter before the team reaches the relevant stage in the roadmap.

Ok, let’s talk about planning for the expansion

The first thing to do is to communicate to your boss and/or the management team when a specific stage in your roadmap requires a bigger team in order to take the product to the next stage.

You will need to communicate this right after the roadmap is approved (or during the discussions on the roadmap itself) and remind them again when your team is getting near this stage. By ‘near’ I mean about a quarter before.

Note that you can’t finalize your roadmap if it relies on such a growth, but the management can’t commit to such a growth. It means your roadmap is not aligned with the reality and you’ll need to downsize it. But since we’re not on the topic of roadmap planning – we’ll assume everyone is aligned on that.

Once you communicate that, everyone is signed on your roadmap, funding is secured and you are about a quarter away from the projected expansion – it’s time to delve into the details of your plan.

The expansion plan

1. Meet with the R&D team/group leader. Go together over the roadmap and roughly assess the additional developers needed and how many teams. You’ll probably be more accurate with predicting the amount of the needed teams than the exact number of developers. This is because the teams can be much more easily mapped to various aspects of the product.
2. Determine whether you want your product managers to be ‘vertical’ or ‘horizontal’. Meaning – determine whether you want your product managers to specialize in specific product modules (for example – frontend, security, biz logic1, biz logic2, etc…) or you want your product managers to be able to work cross teams and take features end-2-end. My recommendation: for groups up to 20-30 developers – have your PMs be horizontal, no matter how many teams it involves. It’s important that they will be able to take as many features as they can from ideation to production without involving other PMs. However, as the group gets bigger, the system gets more complex and naturally the product itself splits to several divisions. At this stage it may be too complex for your PMs to take on such cross-groups features on their own, and it will probably become a mutual project of several PMs. Depending on your seniority – such projects may even involve PMs out of your group.
3. Determine whether you want to hire senior PMs or junior PMs. Senior PMs can start delivering much faster, but they cost more and there is more demand for them – so the hiring process can take more time. On the other hand – junior PMs require more attention, but are easier to find and cheaper. My recommendation – prefer junior PMs if you have the time to do mentoring. My reasoning – it’s much easier to find ‘raw talent’ for such positions, the candidates are more ‘hungry’ and willing to learn and less spoiled. From what I’ve seen – senior PMs also come very often with several bad habits that you’ll need to work them to change (not sure why is that. Could it be because there is no ‘official’ product management qualification?). Hence, junior PMs will take more attention from your side, but not much more than senior PMs as you’d have imagined…. Anyway – depending on the team and configuration you might decide to hire a mixture of the two…
4. Start the hiring process a quarter before you need the PMs in place. Watch closely how the R&D hiring is progressing. If it stalls – you may want to slow down or even pause your hiring process. No point in hiring PMs if they have no development force to work with. In fact you can even start your hiring process after several developers have actually signed. Recall that developers need a training period before you can assign them tasks, and recall it’s relatively quicker to hire PMs than developers (well… at this period of time, at least).

What about product designers and product data analysts?

Both product designers and product data analysts are most likely to be associated with the product team, and it makes a lot of sense indeed (I’m putting UI and UX designers under the same umbrella for this context, though they are not exactly the same). I’m not gonna delve into the reasoning behind this, since it’s a bit out of scope.

Accepting this as an axiom for the context of this post – it means your plans must cater for them as well.

If one of the teams that are going to be formed up, or even just expanded, include a lot of frontend development – then maybe you’ll also need an additional product designer? Do you even have an in-house product designer? If not – maybe it’s a signal that it’s time to hire one? If you have one or more in place but they are overloaded – then maybe it’s time to hire another to ease the load? 

Consult your highest UX/UI authority in your company about this. Different companies have different approaches as for how to utilize product designers. Some are assigned to specific teams while some work cross-teams. Such a UX/UI authority can work with you on your needs and you both might reach a conclusion that it’s time to expand the team.

As for product data analysts – it seems like there are never enough of these people. If you don’t have a product data analyst – hire one now. You’ll thank me later. Everyone wants their own dashboard and wants more insights about the data. Like the product designer, it’s very likely that there is a relevant BI or data authority in your company that can provide you with guidance. So if you already have an analyst or two catering the needs of your team, but they seem to be flooded with work – ask for guidance as for how to plan for the growth of this team. If there is no such an authority – then my advice would be to grow linearly over time, whenever you see there is simply too much work for these guys.

In reality

What I described above is a plan for when everything goes plus-minus according to the plan. Sadly, reality is a mess, so this is almost never the case. Your company will most likely raise less or more than planned, the pace of securing the funds is going to be different than expected, the market will signal you to make changes to your roadmap and other thousand things will go differently than anticipated.

Therefore, consider the above as guidelines because the principles will stay the same even though the plan itself will change. Remember that the pace in which the R&D team is growing is the main consideration for growing your own team. Just make sure their growth doesn’t take you by surprise…

That wraps up the post for today.

If you found this post/series useful – please let me know in the comments. If you think others can benefit from it – feel free to share it with them.

Thank you, and until next time 🙂