In my last post about managing product managers I had mentioned about upcoming post on how to build product management team. So here it is.
I’d like to share things that I have kept in mind while forming the Product teams in past. Will explain it via a hypothetical example. We’ll see what a product head needs to take care of, while forming the team.
Hypothetical Scenario: Say, you are heading the Products for an organisation that makes product for helping people manage their personal finances. And let’s say, the company is in growth phase now and you are in a position where you need to form the product management team to realise the vision of letting people manage their finances without hassle.
Here’re the six key points:
- Identifying the goals
- Identifying the structure and size
- Hiring the right people
- Plan the interim structures
- Self sustainability of the team
- Develop the team
1. Identifying the goals
We need to identify what do we need Product Managers for. This roughly translates to what products do we need.
Typically these are the questions help you answer that:
What products are required in our long term vision?
In our hypothetical example it could be “Product to let people manage/track funds allocation, expenses” and “Product to recommend people on how should they allocate funds”.
What products are required for our short term plans?
This one typically revolves around some rough unproven concepts/bets, market waves, or the product that would typically be required initially, and be just maintained down the line. Sometimes you want to try a part of the product first before expanding it to other dimensions. e.g. You might want to try Mobile web first, before you get into Mobile App (in which case, that can be construed as a separate product). In our case it could be “Product that can integrate with different banks” or “Gamified platform where people can be rated on their finance management skills”.
What inefficiencies are there in building our products or running operations that can be solved via product driven approach?
In our case it could be “Product to allow easy onboarding and integration of financial institutions”. Generally, a look at structure of your product strategy/roadmap also gives a hint on what all are the main product lines you need.
2. Identifying the structure and size
Then we need to identify how many product managers do we need and what kind.
This question is typically answered by identifying following:
- What would be the structure of product org
- Here you should strive to make somewhat independent product units within the org, with their clear mandates
- I’ve done this exercise multiple times, and have spent many days on it, but the right solution always remained elusive. Every structure that you come up with would have some downsides. You need to go with the one that best suits your product ethos and long term vision. Very importantly, everyone needs to accept that structure in spite of its shortcomings.
- If you have put a structure to your product strategy/roadmap, that probably would get translated here too.
- The ratio of product managers to developers: There are many theories on this. I have mine. Will talk about it in some of the subsequent posts. For now, go with the number you have been comfortable so far.
- Growth ambitions and Budget: Basically, how fast does your company want to grow and whether it has appetites and budgets to match that. And then how deeply do you want to go in individual items. E.g. Is “recommendation engine” a feature or something that you want to spend big R&D team to?
- Size of the problems being solved: Some problems require a full time attention of a product manager, while there are some problems which are okay even if a partial attention is given to them. You need to identify those, and those will tell you how many people do you need.
In our example case, let’s say you could come up with something like this (Just a sample, not recommended one. It would require proper brainstorming to arrive at right one, even in this hypothetical example):
| Section | Finance tracker | Allocation Recommender | Operations Improvement | |
| Mission | Make it easy for users to manage and track their finances and funds. | Make sure users’ funds are allocated for best results, and it is easy to do so | Make sure we have maximum output of the manual efforts we put in, in our operations | |
| Size | One senior PM
One associate PM |
Two PMs | One associate PM | |
| One for the research on science of recommender | One for the interface of recommender | |||
| Products for moonshots to be taken up by all individuals as bandwidth permits (as per the priority in roadmap). | ||||
3. Hiring the right people
When you have the structure of the product org, you would typically know what kind of people you need for which role. While hiring, keep those things in mind. E.g. In our example above, in case of “Recommender”, the PM working on the recommendation science needs to be someone who gets excited about such things, while the other one could be more UX oriented.
However, of course you should be somewhat open as well, as sometimes you’d find some gems which would make you open your box of those dormant moonshots and let them run with them, or there would be some who could take care of one big ship.
4. Plan the interim structures
Once you have the org structure vision, you would take quite some time till you reach the stage that you have envisioned. Hiring right product managers takes time after all. So, you need to have a plan for what would the interim structures be. Engine has to keep running, and you can’t stop the innovation and development waiting for the right structure.
Also, with this you might want to plan which roles to hire first, as they will be critical for your interim structures. E.g. In our example, you might want to prioritise the senior PM for “Tracker” first, as Tracker is the first interaction user would have with your product, and them being senior, they would be able to double up for other sections too.
Then, whenever a new person is hired, review and reshuffle the structure as required.
It is important to keep the team informed that these structures are interim. Show them what your final vision is, and keep them ready for the reshuffling that would happen as team grows.
5. Self sustainability of the team
Depending on the stage of the company, budget and growth ambitions, you might want to put a bit of mix of seniority in your team.
Attrition happens for various good reasons, e.g. People wanting to go for higher studies, entrepreneurship, breaks, different domains etc. Keeping a mix of seniority helps relatively junior people step up and prove their mettle.
Even if nobody leaves, you grow the junior people and prepare the senior people for next level leadership. Having a mix of seniority helps senior hone their mentorship skills, juniors develop themselves faster, and good camaraderie sets in the team.
This would allow team to become self sustainable and self managed as well, as they would be able to execute lot of things themselves and you can focus on strategic things like scaling product in new dimensions, think of ways to go faster etc.
6. Develop the team
In my last post I talked about managing the team on quite a few points. Once team is formed, it is important to make sure team is high on spirits and output. On high level here are a few things I feel critical for developing a team:
- Keep reiterating the vision
- Give ownership
- Build security and give room to grow
- Invest yourself in people and develop them
- Build camaraderie
- Prepare for next gen leaders
- Engage, Communicate.
- Build good practices, guidelines and discipline
Hope this helps! Please do share your thoughts on this and points that I might have missed.
I feel I haven’t done justice to some topics mentioned here, especially “Hiring right people” and “Identifying structure and size of the team”. They need more elaborate explanation. Lot of pitfalls to be avoided there. I’ll write about them in my subsequent posts. Which of the two should I pick next? Or something else? 🙂