Luisja Alvarez, Telefonica CX, on how their product teams work with multiple countries and brands
Telefonica CX is the department which builds the main consumer app for the different commercial brands of Telefonica in multiple countries. Luisja is their Head of Global Product since 2018. This article reviews how they structure their product teams to work better with the countries, how they prepare their quarterly roadmaps and their challenges implementing OKRs.
I was interested in talking to Luisja because he leads several teams in a global corporation whose products affect many countries and millions of users. He is implementing methodologies similar to mine, mentoring a dozen Product Managers, and he works on challenges I still need to discover.
Meeting Luisja
Luisja Álvarez joined Tuenti as Associate PM in 2013. He has done there the whole PM career path becoming Head of Global Product at Telefonica CX in 2018. Since then, he leads a product area which develops consumer apps for Movistar, Tuenti, Vivo and O2 for many countries in Europe and Latin America.
He studied Telecommunication Engineering at the UPM, where we briefly coincide in time. He started HivePlay, a music service for venues. They got investment from Wayra (Telefonica startup program). As Hiveplay didn't succeed, he joined Tuenti to start his career in Product Management.
Meeting Telefonica CX
Telefonica CX is the department which builds the main consumer apps for the different commercial brands of Telefonica in multiple countries around the world. They could and will start impacting other channels, too, such as private websites or retail digitalization.
They are around 250 people, with different profiles like PMs (20), Designers (25), Digital Analytics (7), PMOs, CPMs and Engineering (hundreds).
From Tuenti social network to Telefonica CX
Tuenti was the leading social network in Spain from 2006 to 2010. They had the most excellent Product and Engineering team in Spain at the time. Telefonica bought it in 2010, and they launched Tuenti's virtual mobile operator (OMV) privately at the end of that year. It wasn't until the beginning of 2012 when they began it publicly.
Tuenti mobile operator grew during the following years in multiple countries as the low cost and young brand from Telefonica, but it wasn't the success they were hoping. Telefonica decided to leverage their primary active, the Product and Engineering team, to revamp the consumer apps from the different brands of Telefonica. Tuenti product team became Telefonica CX team. Tuenti became just one of their commercial brands.
Countries and brands
Tuenti had developed one mobile app for all the countries they were operating in (Spain, and four other countries in Latin America). However, each of the other commercial brands had one app per country. Between Movistar, Vivo and O2, they could have dozens of apps which were doing the same thing.
Telefonica decided in 2017 to migrate all countries and brands into just one app, leveraging the great work done by the Tuenti team. The base app would be the same, but its style and content would adapt to each brand and country. During the last three years, Telefonica CX integrated each country and brand into the base app. On November 2019, eight countries and two-three brands on each country were using it.
How they structure the product teams
They have two areas:
- Global Product which leads the development of the universal products
- Operating Business Product which adapts them to the countries, and deals with the most proposition-related side of the product
Apart, they also have Design Core which makes sure the rest of teams apply the design guidelines, components and brand styles; and Apps Core which improves the technical quality and performance of the apps.
It's important to mention that each country has its technical platforms with its local Product teams. Operating Business Product teams work directly with them.
Global Product teams
Luisja leads this area with eleven Product Managers. Each of the seven product teams is responsible for a different product component, and has one designer and between 9 and 12 engineers:
- Explore – Showcase of products offered to customers (films, plans, devices)
- Consumption – Management of how much the user is spending
- Checkout – They are in charge of payments. They do it in a standardized way, cross Telefonica
- Support – They take care of the contact channels like FAQ, chat, ticketing and new integrations like Aura
- Digital acquisition – They sign up new clients with only the app, and they take care of the on-boarding
- Outline – Every other common thing: profile, settings, login, unified notifications
- Product Core – They work with specialized teams like Design Core and Apps Core. They also lead the definition of projects that affect several teams
Operating Business product teams
Another Global Head of Product leads this area. They have five teams which work directly with each country and brand to adapt the product to the local needs. Each team has:
- Product Manager
- PMO (Project management office) which makes sure the cross-team projects are well executed between Telefonica CX and local teams. Those local teams can be business or technical (e.g. API of local service).
- CPM (Commercial Product Manager) which find the right person in the countries to make decisions, and collect feedback
- Plus, as other multidisciplinary teams, engineers and a designer
How they prepare quarterly roadmaps
The trigger for this interview came when Luisja read my post about how we align Product OKRs with C-level. The context of Ontruck and Telefonica CX is very different, but some ways of solving the challenges are similar, which made the conversation quite interesting.
Luisja quickly admitted that the complexity comes from dealing with each country and global departments with different interests. They have made lots of efforts, so countries and global departments raise needs instead of solutions or projects. They are working more Agile now than two years ago, but they still have some challenges to solve. He spends a lot improving their processes "We apply the product development process to how we work, we constantly iterate".
Many teams have needs
The product teams listen to the needs of country business departments (Sales, Marketing, Operations), global departments (Marketing, Operations, Contact centre, Movistar play, Aura) and core Product teams (product, design, apps).
To react fast to the learnings and priorities of the business, they prioritize projects quarterly. They have set up a process with different phases which allow different product teams to collect the needs, combine them, and align the proposal.
The process to decide the roadmap
The process involves several phases:
| Phase | Responsible | When |
|---|---|---|
| Collect country needs | OB Product | Six weeks before |
| Needs & Opportunities | OB Product | Four weeks before |
| Roadmaps drafts | Global Product | Two weeks before |
| Roadmaps alignment | Global Product | One week before |
| C-level review | VP Product | Days before |
Collect country needs
Six weeks before
"The Product Managers of Operating Business Product teams talk to the online departments of each country and brand to collect their needs". Luisja reinforces that "they try to turn solutions into needs, backed by quality and quantitative data" to escape the build trap (great book!).
Needs & Opportunities
Four weeks before
They do an event on which product-related people present the needs and opportunities of the whole organization.
"We do an event on which those OB Product Managers digests all countries' needs, and presents to Global Product their findings, data, and the reason for the need or opportunity". They started doing this event when they were working with six countries; it became an effective way of sharing context.
"Growth-Marketing brings us their needs as a team and the needs of the local marketing teams. Global Product also presents its needs and the needs from global departments. We also review the features which we launched in some countries and we want to release in other countries."
Roadmaps drafts
Two weeks before
With all that information, each product team starts drafting their roadmap. "PM, Tech lead and designer are the ones who spend most of the time doing it. The best teams also include some engineers. Teams talk to researchers or Data Analytics to contrast information."
Each team does a three months roadmap, clearly identifying what's going to be released each month. They also show what they expect to happen in six months to sell the vision of where they want to take the product.
Roadmaps alignment
One week before
Luisja wrote recently an article which explains well how they align roadmaps. The summary is that they do a day event on which each team presents their roadmap to key stakeholders and other product teams, and they gather feedback. The objective is to detect conflicts, synergies and misalignments with the priorities.
We discussed that a good tip is that when PMs present their drafts of roadmaps/OKRs, they explicit also what they leave out of scope. That way, they bring forward discussions with stakeholders.
C-level review
Days before
Currently, the VP of Product presents the highlight of the quarterly roadmaps to C-level. He gathers feedback to make the last changes and get them approved.
In my opinion, it's a good practice that Heads and Senior PMs present their roadmaps/OKRs to C-level. When we do those sessions at Ontruck, I act as C-level, not as CPO. I'm not there to protect or defend anyone's plan. I'm there to get the best plan for the company.
Challenges to applying OKRs
They have two main challenges: transform old habits of business requesting roadmaps with features, and aligning projects with interdependencies with other global or local teams.
Roadmaps with features vs OKRs
Luisja hits the right question to business: "Do you want us to launch a new product or that we reduce 20% the number of calls?". If product teams are measured by the number of features they deliver, they will optimize for that; which can be a different outcome and output than what business expects from the feature they agreed three months before.
They are doing some experiments to transform the organization quarter by quarter. The main one is to define the Objectives of each team which are related to their yearly company OKRs and define verifiable milestones as a KR (achieved or not achieved). The second is that they do a data review session where they "do a deep dive on the metrics of a project with the entire product team". They are trying to change the external and internal mindset.
My recommendation in this situation would be to work with C-level to start framing some projects as a KR with the expected business outcome. You can agree with both the high-level feature and the expected outcome with the stakeholders. This would help to bring alignment with business and force the product team to focus on the outcome. Once you have been successful, you can expand it to more projects the following quarter.
Interdependencies
OKRs work well when the product team is independent; it's more complicated when they have dependencies. Regularly having them can be a signal that the product teams are not well split.
In the case of Telefonica CX, Luisja told me that as they work with local product teams they "have to give them visibility because they have to do work on their local APIs". In this case, they follow more traditional project management with dedicated roles as they need to involve local business people.
We discussed three ideas that have worked well for us, and may help:
- Flash squad. You mix people from different teams during the duration of the project. That way, you remove managers and engineers can decide faster.
- Erasmus. If you need the help of just one or two engineers in another team for several weeks or a quarter, you move them temporarily. We informally call that "doing an Erasmus".
- Both teams have the OKR. If it's an intense project, you may need the focus of both teams. This works well if they follow similar methodologies (that's why product teams mustn't diverge too much on how they work).
In any case, when there are interdependencies, the key thing is to make one PM accountable and remove as many managers as you can. Let the designers and engineer solve the problem. The rest of us are there to unblock them, not to add noise. Having a simple RACI will help (we call it lean RACI at Ontruck).
I admire Luisja for the way he has improved the team and processes, while managing a complex stakeholder organization. It isn't the same working with one business area than working with multiple countries and brands, each of them with its expectations.
If you want to learn more about his experience: