When we decided that Product Owners would change roles within the product team and become Product Managers, not even the name change was instantaneous – and even today someone sometimes gets careless and calls me PO! Labels aside, it was a profound change that to this day is having a very positive impact on the way we develop product .
It is noteworthy that in some companies, these roles coexist: Product Manager defines Vision and Roadmap, Product Owner defines user stories. The PM looks more outward (customers, market, etc.) and the PO’s focus is inward (time, delivery). In our case, however, both responsibilities shifted to the Product Manager. I’ll explain how:
The Context and Importance of the Product Owner
When Scrum introduced the role of Product Owner, it solved a series of problems caused by the amount of information, requirements and interferences that a development team can suffer when there is no single interface that represents the customer figure .
In the context of Scrum, the Product Owner is the customer, and to the development team, it doesn’t matter how many different people are inputting the PO, whether those inputs are contradictory, whether people are changing their minds, or whether there are needs that aren’t being met. Once the PO’s user story is written and prioritized, it is the team’s role to organize to make that delivery.
It is also the role of the PO to participate in all team ceremonies and be 100% available to guide and answer questions about the path to be followed in development.
For a long time, this role made sense and fulfilled the needs of our product team. Until things started to change.
The expert teams
As the product began to grow and scale, we began to need expert teams on each front of action. The teams were reorganized to be multidisciplinary – product, design, development, quality – and each specialty became a chapter:
If you look closely at the first row, there with white hair, there are… Product Owners! Well, the model that inspired our reorganization was Spotify and this image is how they explain the structure.
However, when we were still planning the transition, we realized that the product would lack a broader vision. In the previous model, our Product Head was also responsible for looking at the business, the market and the customer’s pain, bringing the Epics (or Features) to the POs to be studied and broken down into user stories. With the change, we realized that the structure of a single pro looking at the Epics and the Roadmap simply wouldn’t scale.
In addition to the Software Engineering part, it was also necessary that each team could, on its own:
- Evolve your knowledge of the Business – both Digital Marketing in general, and the team’s specialty;
- Identify, understand and develop Empathy for customer issues;
- Have a broad view of the Market, Trends and Opportunities;
- Work closely with other areas of the company (Marketing, Sales, Customer Success, etc.) in exchanging ideas and information; and mainly
- Develop a Roadmap and revise it whenever appropriate, ensuring a long-term vision of the paths that the product vertical should follow.
These roles, now more external than internal , added a whole strategic layer to the professional who was previously the Product Owner, dedicated more to the tactical and in some cases, even operational layer . These are responsibilities that are directly linked to the figure of the Product Manager, or Product Manager, and it made much more sense to call these professionals that way.
The name change was not just a name change : it also marked the new responsibilities of the product professional and served as a “watershed”.
The Product Manager on the team
With specialization, teams stopped being software teams and became product teams , each one having autonomy, as if it were a “mini start-up”: investigating, testing, validating and creating on their own, in alignment with the general strategy of RD Station, which continues to be defined by the Head of the area, together with the CEO and the heads of some areas.
In the structure of the team as a start-up, the division of responsibilities and the relationship between the Product Manager and Tech Leader is the same as that between a CEO and a CTO. Although everything is discussed and decided together, it is the responsibility of the former to define what to do and where to go , while the latter is responsible for the equally difficult definition of how to get there .
Despite this division, an important PO attribution was maintained by the PM in this new structure: he still receives the team’s deliveries at the end of each Sprint. Therefore, it is still up to the PM to define, in planning meetings, which is the DoD (definition of done) of each work package. On the other hand, PM tasks that are directly related to the team, such as Roadmap and Product Vision, are also delivered to the team in a similar ceremony, which ensures greater team involvement with the steps prior to writing user stories and developing solution.
New challenges, new solutions
When we took on these new responsibilities, our days didn’t last 48 hours, so we had to split between roles! The role of the Product Owner continued to be important, but it had to be done in less time and as expected, some alerts lit up. I decided to share two of them in this post:
1. Team support
The first was that the Product professional was no longer 100% with the team. If before it was possible to solve a doubt immediately, with the change, developers could now find themselves stuck in the progress of a task, not knowing which way to go.
It is noteworthy that, with the specialization of the team, everyone had to study more deeply the concepts and difficulties of their theme, but even so, doubts and impediments related to the Product and the solution continue to arise on a daily basis and it remains a responsibility PM have a deeper understanding of the customer and the business.
The solution for this was to invest in alignment and autonomy . In interactions with the team, especially in the early stages of study and planning, the Product Manager needs to “ tell the story of the Epic ” in more detail, usually at the time of presenting the Press Release . This ensures greater alignment and consequently gives the team autonomy and security to make small product and solution decisions, removing some impediments on its own. In other words, the team becomes more agile, responding promptly to changes and new discoveries.
2. Interactions with the customer
Another challenge was the amount of Product Managers’ interactions with customers. In our Product Kanban , there is a very important phase called Problem Study. This phase is fully investigative and involves quantitative data, conversations with professionals from other areas of HR and interviews with clients. Afterwards, there is another phase, of experimentation and validation of the hypothesis, usually by an MVP , which is often available to a group of clients that we compare with a control group. Towards the end, we have the Launch phase, which again involves contacting the customer.
Try to imagine 10 different teams interviewing customers, running experiments, launching new features, etc. In addition to annoying the customer with the excess of interactions, each hour starting from a different person, it became increasingly difficult to form experimentation and control groups that did not have some overlap with groups formed by experiments from other teams.
The solution to this problem came from two roles that are currently in the Marketing area: Product Marketing and Customer Marketing. Among other things, these two roles share responsibilities regarding interactions with customers, invitations to Alpha tests, launch strategies, etc., avoiding excessive emails and conversations. In a future post, we can go deeper into what this has been like for us!
Like every Product Manager, I’m passionate about problems to be solved. The possibility of a more panoramic view, as well as the approximation with customers and other areas of the company, allow me to study each problem much more deeply and not only create the Epics, but also develop a Product Vision and translate it into a Roadmap that tells a story and that makes sense over time.
Furthermore, with the Product Managers exercising their roles from within the team, everyone on the team gained a product vision in the medium and long term. Some developers have engaged in the study, investigation and solution process, which has added a lot. Interactions with Designers were also very rich and this exchange has been of great value in all stages of Kanban.
This transition process has brought some pains and new challenges, but so far the balance is totally positive and I’m sure we’ve “up a level” in our way of thinking and developing the product.