Product Operations, or POps as some people have called it, is a role that has appeared with some frequency in product development teams, especially in reasonably large teams with 150 or more people, including engineers, designers and product managers.

Definitions

Anyone who knows me knows how important I think some terms are clearly defined, to ensure that we have the same understanding when we are talking about this term. It is the ubiquitous language, a concept created by Eric Evans in his book Domain-Driven Design, which is the set of terms that must be fully understood by both domain experts (system users) and developers (system implementers).

Operations is one of those very broad and generic terms, which can have different meanings and represent different responsibilities, depending on the company, its culture and its context. However, in the different definitions that we can find on Google, we find as a common denominator that:

Operations is the day-to-day management (of the company or an area) and the search for the efficiency of the processes to generate value in that company or area.

Many companies have operations directors and even a person in top management with the title of COO, Chief Operating Officer. And many companies also have specific areas of operations for some company functions. Sales Ops, Marketing Ops, DevOps, Design Ops. All of them aim to help in the day-to-day management of their respective area and, consequently, help it to be more efficient.

Before being an area, it must be a need

Before we think about creating an area of ​​operations, we first need to understand the need that can culminate in the creation of this area. Usually this need appears when the company starts to grow in number of people. The more people a company has, the greater the chances of inefficiencies in the company’s day-to-day activities.

When a product development area (engineering, design and product management) is small, like 5 to 7 people, everything happens within the team. The team itself takes care of all aspects of the product. This team has a lot of autonomy and ability to generate results quickly and continuously. As the team grows, we tend to divide this team into smaller teams, to maintain autonomy and the ability to generate results quickly and constantly. On the other hand, this division of the big team into smaller teams also brings two points that require attention:

• rework: with autonomous teams it can happen that different teams are working on similar topics, but because they are focused on their objectives, they do not perceive synergies and possible opportunities for efficiency gains.

• misalignment: no matter how autonomous the teams are, they work within the same company and often focus on the same or complementary customers. Therefore, no matter how autonomous they are, the work of one team will eventually be influenced by the work of other teams. When teams are very autonomous, this influence can take time to be noticed, which will certainly have a negative impact on value creation, usually due to delays or impediments.

Once the problem is detected, solutions can be thought of. Often the solution can be for someone from one team to team up with someone from another team to create a solution to that problem. Once the solution is created and implemented, people continue to work in their original teams, and if there is a need for any improvement or adjustment to the solution, they can come together again to make this adjustment. If this need for improvement or adjustment in the solution becomes frequent, then we can think about dedicating someone to continuously focus on these needs for improvements and adjustments.

To help make these concepts tangible, here are some examples of timescale problems and how we solve these problems:

• Design system: Locaweb’s product teams were quite independent, as each team took care of a specific product. We had one team taking care of the website hosting product, another one the email product, another one the webshop product, another one the reseller hosting product, and so on. This independence even made it possible for teams to use different programming languages. On the other hand, this independence created certain reworks. One of those reworks that we tackled first was the design of the interfaces for these products. Each product looked like it was made by a different company. That’s when we decided to create Locastyle, a front-end framework for behavior and style, that is, Locaweb’s Design System. It was developed as a side hustle of some design and engineering people and when there was maintenance, or a need to create a new component, these people would get together and make the necessary adjustments. There was no need to create a permanent team to take care of this issue. In Conta Azul, the creation of Mágica happened in the same way, but after it was created, we chose to have a designer person being a team of 1 person from DesignOps. This person, in addition to looking at the design system, also looked at the design processes, along with the head of the area. After some time, this Design Ops team grew to 2 people, with a UX Writer taking care of communication consistency. At Gympass, we set up a Design Ops team with a designer and a front-end that created and maintained Yoga. This team later grew with UX Writer taking care of the tone of voice and translations and Research Ops to coordinate research efforts made by more than one team with the same user. At Lopes there was also an effort, exercised part-time by the people of the design team, to create the Lopes design style guide.

• Tools: at Locaweb we also saw several opportunities to centralize the development and maintenance of some tools. For example, all teams need authentication and authorization on their products, and several teams wanted to offer APIs for their products. Instead of each team doing its own authentication and authorization and its own API infrastructure, it made more sense to create a centralized one. With that in mind, we created a team of tools that had exactly this objective, to create tools for product teams to be more productive. We put two of our most senior developers on this team. We also created this team in the Azul account, with the name Foundation, but the path was a little different. One of the tribes, the one that took care of the sales registration and invoice issuance functionalities, decided to offer these functionalities as an API as well. So this tribe created the API infrastructure to put the endpoints they needed. This tribe would talk to tech leaders from the other tribes, show them what they were doing and gather feedback. When another tribe, which took care of financial functionality, also decided to make its functionalities accessible via API, we started to think about assembling a team to take care of this API infrastructure, and other needs of the product teams, in a centralized way, and we called this Foundation team.

• Ideas portal: at a certain point, the Conta Azul GPMs started to bring to our weekly meeting the need to collect customer suggestions in a more structured way. Instead of each GPM collecting these suggestions independently, we decided to do it more centrally, since the customer was the same, regardless of which part of the product he was using. Then came the idea of ​​building an Ideas Portal exclusively for Conta Azul customers. Our purpose was to create something simple that only Conta Azul customers could access, make suggestions, view, comment and vote on other customers’ suggestions. The head product design person decided to take this initiative, looking for a market solution. With the help of a designer, he adjusted the layout and, with the help of a developer, made the integration with the customer authentication system of Conta Azul. Once the solution was implemented, maintenance was minimal, and no one dedicated was needed. When there was a need for some maintenance, someone would dedicate a few hours to that maintenance. I imagine that in a larger team, the construction and maintenance of an ideas portal like this could be taken care of by a Product Ops team, or even a Design Ops team. As well as a system for NPS research.

• Data: at Locaweb, access to some business-related data was exclusive to the BI team, which was required to generate reports and insights and, obviously, had a prioritization queue. To avoid this bottleneck, since Conta Azul I have been working with teams in a culture of data democratization, that is, giving access to data to more people in the company so that everyone can generate their reports and insights from the data. At Conta Azul we implemented Metabase as a tool that allows for this democratization of data. I remember that when I had access to the Metabase of Conta Azul for the first time, I spent about 10 days going to sleep at 3:00 am, having fun building dashboards! We did the same at Gympass and Lopes. The implementation of this tool, connecting it to the company’s databases and maintaining it, giving access to people from the product development team and the entire company, and helping people to get to know and take better advantage of it has always been a responsibility of one of the structural teams that we had in these companies, the data team.

• Quarterly OKRs: at Lopes we were organized into teams focused on each of the actors in our marketplace. We had a team focused on the end customer, another team focused on who is selling the property and a third team focused on who does the intermediation, the brokers. We also had the marketing team, focused on generating demand, and the central systems team, focused on the systems used internally. At the end of each quarter, these teams defined their OKRs for the next quarter. Although all teams work with the same focus of helping people to conquer their place, connecting them to the most appropriate property through the best broker, each team ended up looking at its main focus. So once the teams finished defining their OKRs, I would review and find overlaps and complementarities, align with the teams on those findings, and change the teams’ OKRs to take advantage of those overlaps and complementarities. it’s an alignment job, part of a product head person’s job description. We are talking here about 5 teams with an average of 3 to 5 goals per quarter, each with 3 to 5 key results, that is, 20 goals and 80 key results. Of course, with the number of teams greater and, consequently, the number of OKRs also greater, the need for coordination will be greater and may require someone dedicated more time to this alignment, which can be a Product Operations assignment.

It is worth mentioning some important points in relation to the examples above:

• the initiatives were created and run by people with leadership experience and the ability to see the big picture, that is, senior people.
• another important point to highlight is that, before thinking about creating a new area, we thought about how to solve the problem in question with the current teams, shifting a little effort from day to day to solve the problem.
• only when the recurring need for maintenance and improvement of the initiative became clear, did we think about creating an area with this focus.
• every new area should start with one or at most two people.
• as this/these person/people is/are) showing results, reducing the rework of the teams and helping in their alignment, it may make sense to grow the area by adding more people.
• with the evolution of this area, it may make sense to have a structure and mindset closer to those of a product development team, with product managers, engineers, and designers. In this case, the product manager will be creating products to solve problems and meet the needs of the product development teams.

Summing up

• Product Operations, or POps as some people have called it, is a role that has appeared with some frequency in product development teams, especially in reasonably large teams with 150 or more people, including engineers, designers and product managers.
• Operations is the day-to-day management (of the company or an area) and the search for the efficiency of the processes to generate value in that company or area.As the company grows, it ends up being subdivided into smaller areas and teams so that these areas can have autonomy and the ability to generate results quickly and constantly.
• This division into smaller teams also brings up two points that require attention, rework and misalignment.
• The solution to these points of attention may be the temporary effort of one or more people to create and implement solutions to these problems.
• These solutions may eventually require more constant attention and maintenance, which may lead to the need to create a team (Design Ops, Tools/Foundation, Product Ops, etc.)

New dates for the Workshop to Create the Vision and Strategy of your Product

Without the clarity of your product vision and strategy, it is very difficult, if not impossible, to manage your product. How do you decide where to put your focus and energy? What to leave for later? How to show stakeholders what you intend to do with the product? How to have arguments to say no to requests for new features in your product?

That’s why I’m opening new dates for my Wotrkshop to Create Your Product’s Vision and Strategy. Spaces are very limited, so reserve yours now!

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.