In today’s entry in the product management from the trenches series, we are going to talk about product teams.
As those of you who have followed the series already know, I was, as CPO, the first employee of the product practice in a company where there was no dedicated product function, but rather it was spread throughout the organization.
Initial Context#
In other entries, we have talked about diagnosing the situation and the bandwidth of the product team once it was formed, but you don’t have that from day one, or at least I didn’t.
It’s true that when you go through the selection process for these types of positions, you usually do a business case in which you try to outline the main challenges the hiring team presents to you about the organizational context you will face (we will talk about this another day, but I would like to know your opinion on doing this type of “pro-bono” consulting work when applying for a job. In the end, I find it interesting and like a puzzle, but it also has an opportunity cost, so the question is how to dimension it so that it is not too tedious for the candidate). In these cases, I usually introduce a vision of the team needed to tackle the challenges and proposed solutions outlined in the case. As we well know, product management is a team sport and, although the product manager has traditionally been a quite generalist profile (more specialized in recent years), it must be acknowledged that no matter how good a product manager is, they cannot perform miracles.
Importance of the Team#
Therefore, for me, the most important thing as CPO, if I wanted to move the needle of the organization and have more impact, was not just to influence from backlog management; I had to start building a team of change agents who would carry this practice in the daily interaction with the main stakeholders. In this sense, what I sought from early stages was to have access to and control over the development teams. This is not always possible, but if you can achieve it, you will have more control over your own destiny. In this case, I negotiated with the organization and the CTO to have the figures in charge of managing the teams in this organization, which was the team of product owners (POs).
Definition of Roles#
There is quite a bit of literature about what a PO and a Product Manager (PM) are, and you can take a look at the book Inspired by Marty Cagan for a more canonical definition. I won’t go into fine detail, but for me, a PO is a role that comes from agile methodologies and is more focused on delivery, while the PM is more focused on strategy and business. In this specific case, the POs were basically scribes, or translators of requirements into user stories, and I believe there was a lot of untapped talent. My original intention was to recycle these POs as much as possible to turn them into the first PMs.
Team Organization#
Once these development resources were captured, I was able to determine what the teams would focus on. One of the aspects I have learned when managing product teams is that they must be organized in a way that reflects the company’s strategy. There must be intentionality in their definition of objectives. That is, if your strategic lines include focusing on growth, it is normal to have a team dedicated to that at least 80% of their time. Of course, it all depends on the number of teams you have. Let’s not forget that having a strategy is deciding what you are not going to do.
This is done because there are studies indicating that the more stability there is in the context of the teams’ tasks, the higher their performance is, because obviously there are fewer context changes, which allows for greater concentration on the problem to be solved and many synergies between initiatives. In a way, you get teams to think about problems in the three Bs (Bed, Bus, and Bathroom). In organizations like Amazon, they often talk about an STL, Single Thread Leader (which is the natural evolution of the two-pizza team; take a look at the book Working Backwards to expand on this concept). In this case, our STL would be the PM of this team.
Strategic Alignment#
In the context of a company acquired by a private equity fund, you probably need to have a team dedicated to paying attention to product needs around inorganic growth from acquisitions (M&A), another team dedicated to BAU (business as usual), i.e., the current products and needs of your mainstream customers, and probably another team for core initiatives or special transformation projects (the home renovations that will lead to the company’s revaluation).
Roadmap vs. Release Plan#
Of course, this alignment of teams and strategy will be directed by a commonly used artifact: the roadmap. This word, on the other hand, is quite abused and used in several senses that often go against the product mindset. There is also a lot of literature written about roadmaps; I particularly like the book Roadmap Relaunch by Todd Lombardo, but what I would really like to do is to discern the roadmap document from the deployment plan (or release plan).
The first is strategic, subject to change, and serves to have a conversation (it is a communication tool) about the what and the why. It usually has certain time horizons, but it does not usually have delivery commitments (although in certain situations they can be, we shouldn’t be too dogmatic. As I told you in the first entries, there could be a case where you have a project with a clear start and end, and in that case, the dates are a must, for example, for adaptation to a new regulation X).
The release plan or rollout plan is the delivery plan, which is tactical and tells you the how, what functionalities and when they will be delivered. Normally, there is less uncertainty and that is why it is preferred by many organizations because it gives a greater sense of control, even if it is at the expense of results.
Remember that product teams commit to results, which is precisely what you define in the roadmap, but they do not commit to functionality, since the objective could be achieved through various functionalities or various initiatives. In this sense, it gives more empowerment to the teams.
In my case, working for a PE fund, I tried to work with both artifacts with the teams. However, we worked with the roadmap on a longer time horizon and the release plan on a shorter one, precisely because of this difference in the level of uncertainty.
On the other hand, as we said, having a strategy is to renounce (Rumelt approves), but for the part you have decided to do, and as we mentioned in the previous post, you are going to have limited bandwidth to do things with the teams. That is, you will have an installed capacity with which to work that will allow you to do more or fewer things and, therefore, also establish the time horizons to achieve the expected results.
Conclusion#
In summary, the formation of product teams must be intentional and aligned with the overall strategy of your portfolio. There are various artifacts with different levels of uncertainty, as well as time horizons, that you can use to convey initiatives, strategically like the roadmap and tactically like the release plan, and to establish these time horizons and initiatives you will have to tend to and elaborate your capacity plan.
I hope you enjoyed this new entry. In the next entry, I will go into detail on how to compose product teams. Have you faced this situation? How have you captured your development resources? Do you use both artifacts like the roadmap and the release plan? Write to me and let’s discuss it. See you next week!