In this entry of the Product Management from the Trenches series, I would like to continue with one of the aspects we touched on in the previous entry, where we saw that product teams must align with the company’s strategy. In this new entry, I want to share how I faced the process of creating a product team from scratch.
As I mentioned in the first entry, I was the first product person in the company. When I arrived, the product team was a one-man business, although I was soon assigned a person with good business knowledge, who helped me understand the organization, the competition, and the value proposition, along with the products.
Team Planning#
When you enter a position at this level, you typically do a business case on how to address certain challenges the organization might face in a given context. As part of this process, I already had a team composition map with which I wanted to tackle these challenges. Here it is:
My mental model for building teams is usually the same, something I learned from practicing CPS (Complex Problem Solving). I firmly believe that product development is a problem-centric discipline, and as such, the problem defines the team.
Mental Model: Product Trio#
Additionally, I complement this concept with the product trio. For those who do not know the term, it basically defines the leadership of a product team as a triumvirate between the product manager, the product designer, and the tech lead. Each is responsible for the functional architecture, the information architecture, and the technical architecture, respectively. Hence, the Product Management Team and Customer Experience Team blocks, corresponding to the product managers and product designers teams, respectively, with some nuances that I will discuss a bit later.
We have a great class on how these profiles interact in the Advanced Product Management Course from The Hero Camp.
Dual Tracking#
Another mechanism I like to work with in my teams is the concept of dual tracking. We have a discovery track, which explores the problem space, and a delivery track, which focuses on delivering features. These two modes of operation intertwine in the daily work of the teams, but it is crucial to have profiles that understand and have worked this way.
Team Composition#
Let’s break down why this team approach.
Product Managers#
There were three development teams available, so my first intuition was to assign a product manager to each team to ensure strategic direction. Here I follow the Single-threaded Leadership (STL) model from Amazon, delegating the responsibility of achieving the defined goals.
I also believe that each PM should be provided with a series of development resources, which is why I made a one-to-one assignment to avoid cannibalization of initiatives.
Customer Experience#
For the Customer Experience team, I believed that five people were the right number to assign a product designer to each of the teams, who would handle all the strategic definition of the customer experience, and then have two people who could help these teams work on the customer/user research part to gather information and insights through mainly design thinking mechanisms that allow us to better understand the customers’ pain points as well as potential solutions for them.
Data Team#
For the data team, my thought was to cover three types of activities that I believed were relevant to us as a product team.
First, the data engineer, who would be responsible for getting the data where it needs to be in the required format (I apologize to the more purist for the oversimplification of the role).
Second, the data scientist who would allow me to exploit those data and extract insights from them through machine learning algorithms, for example for churn management, customer segmentation, and a long etcetera.
Finally, a profile more related to visualization, which would help us create the dashboards that we would use as a compass within the teams and direct conversations with the product teams.
Other Team Parts#
Once the teams that make up that product trio are addressed, let’s look at the other teams that I thought made sense to have.
Agile Coach#
The Agile Coach would help us establish mechanisms for optimal performance, creating good practices, and aligning those mechanisms with the company’s strategic lines.
Solution Scouting Manager#
My reasoning is that as part of the M&A strategy, we would need to look outside the organization to see what solutions within the ecosystem could help us complement our value proposition to achieve the objectives agreed with the fund, and a profile that would help me curate that market dynamics information for me as CPO.
In my experience at X by Orange, doing that role, it is a full-time job, hence the inclusion of this role in the product organization.
Experimentation Team#
The last team I included was a team dedicated to experimentation, for several reasons:
- I didn’t know what I would find in the technology department and what bandwidth I would have for implementation, so I wanted to guarantee a minimal development capacity.
- As part of the solution scouting manager initiatives, we might want to launch something in parallel without distracting the product teams.
- Not just implementing but also launching some experiments that for some reason couldn’t be tackled within the product teams and we had to undertake separately.
- In my experience, some CEOs tend to have pet projects, and I wanted to ensure that this wouldn’t distract us from other things.
Reflection and Adjustments#
After reading all these paragraphs about the rationale behind establishing the product team for this specific context, there are some clarifications I would like to make.
The first is that obviously, this team composition was my wish list, which I would soon discover wouldn’t be delivered.
The second is that under the circumstances in which this team was being presented, it served several purposes in the selection process for me:
- To send a message that established my knowledge about the professionalization of the product discipline for a given context.
- To create an anchoring effect on the roles, responsibilities of the team, as well as its size to tackle the challenges presented to me, which for obvious reasons I cannot comment on, but you can imagine knowing the context of a private equity.
- To understand how serious the proposal for modernizing the way of doing product in the organization was, that is, to check a bit what the organization’s skin in the game was.
The third clarification, perhaps more tactical and also more obvious, is that there is a ramp-up in hiring, onboarding the team, etc., and it doesn’t happen from day one. Everything takes time, and you also have to establish principles and a work culture, which is very difficult to manage if many people join an organization at once.
This initial team composition was my ideal, although I soon discovered that not everything would be possible. The final team composition before I left was 24 people, distributed in four teams: Product Managers, Customer Experience, Product Owners, and Product Operations.
Product Managers#
Product managers team, one per team, a combination of people from different parts of the organization but with the potential to become product managers and other interim professional PMs that I hired through product consultancies like Thiga in this case, who helped me be change agents within the organization and had a product mindset already formed.
A learning I had in this area is that I was very reluctant to open a PM position to hire directly in the organization because among my values is having some responsibility for the people you hire. That is, I didn’t feel comfortable bringing a product manager from another organization to bring them into an organization where the practice was still very much in its infancy. But later I realized that despite being a totally valid feeling, it is a very paternalistic sentiment and I think addressed with total transparency to the candidates, it doesn’t have to affect as there are people who are motivated by these types of situations, as happened to me when I took the position as CPO where everything was yet to be built.
Customer Experience#
Customer experience team, here I am very happy with the team’s composition, and I was very lucky to have a person who had joined the organization a couple of months before me and who helped me establish a vision for that team, finally expanding the team to have a PD per team and a couple of floating people covering: Research, user experience design, user interface design, and user tests, and all their associated processes.
Product Owners#
Product owners team, as I mentioned in previous entries, to guarantee development capacity, I kept the POs team. The reality is that in my vision of product teams, as you have seen, I don’t believe in the product owner figure. In this case, for me, it was a transitional team, where some POs would become PMs and others would take other roles in the organization.
The purpose they served in this specific case was to unload the most tedious delivery tasks from the PMs and to act as a link with the development teams that did not have as proactive an attitude as we expected. Within this team, I had some profiles with greater project management capacity, more project managers, who took care of some projects (that is, initiatives with a clear beginning and end, with a scope) but that fell within my functions and that in a way helped me maintain the established course.
Product Operations#
This team was built from recycled profiles from other parts of the organization that helped me streamline the processes and more internal tasks of the product team, also helping to unload tasks from the rest of the team, for example: product training for various stakeholders, report generation, data analysis, preparation of some processes and communications.
Conclusion#
Until we reached this team, it was not an easy path. We adapted based on events that occurred within the organization, department restructurings, organization acquisitions, and gradually trying to fill the gaps we had in the various functions within a product team to achieve the objectives we had set.
Also, the team composition is only one dimension of product team management. There is another significant part that I would like to discuss in the next entry about creating the team culture and in this case the upskilling in the product discipline of the people who made up the team to ensure they became those change agents within the organization towards a product management mindset, because let’s not forget what I said in previous posts, we are all product, and I needed that mindset to be in every conversation we had with various stakeholders.
In summary, creating a product team from scratch is a complex process that requires careful planning and adaptability. Through the combination of different profiles and the implementation of methodologies like the product trio and dual tracking, you can establish a team capable of effectively facing business challenges. The evolution of the team composition and the adaptation to internal and external circumstances are key to success.
That’s all for today’s entry. I hope you enjoyed it and, above all, learned something. I would like you to comment if you would have created the same vision for the product team originally and what other dimensions you would have considered. Greetings and see you next week.