Brought to you in partnership with
The AI platform to turn customer feedback into value.
CustomerIQ is the AI platform to automatically discover and quantify themes across customer feedback channels like meeting notes, surveys, tickets, and transcripts. Align every team, prioritize work with conviction, and build a customer-obsessed culture with one tool.
Learn more here
Tripadvisor is renowned for revolutionizing the way we explore and experience travel. Founded in 2000 by Stephen Kaufer, Langley Steinert, Nick Shanny, and Thomas Palka, spans across 40 countries and is available in 20 languages.
Tripadvisor.com boasts an impressive repository of approximately 1 billion reviews covering around 8 million establishments, embodying the essence of user-generated content in the travel sector.
Acquired by IAC/InterActiveCorp in 2004 and spun off from Expedia, Inc. in 2011, Tripadvisor underwent a transformative rebranding and has expanded into many verticals, including hotels, things to do, vacation rentals, and restaurant booking.
Today we’re sitting down with the former CPO of Tripadvisor’s European restaurant unit, Fabrice des Mazery, to learn more about how he manages and shapes Product.
More of what we learn in this article:
- Fabrice’ dual-track roadmap planning
- Setting product destinations vs OKRs
- Realizing the effectiveness of KPI trees
- How sales/CS teams pitch improvements to product
- What’s in Tripadvisor’s tool stack
- What to look for in product hires
- Are frameworks overrated?
- Fabrice’ favorite restaurant
To learn more about Tripadvisor, visit their website here. You can follow Fabrice from his Linkedin here.
•
How far out do you plan?
When we first started, there was no clear planning cycle. Our product and engineering seemed like a black box. There were no clear outcomes for our teams to pursue. They focused on various KPIs but there was no link to the consumer experience or a clear strategy.
Over time, we've managed to turn that around. Now, we consider a timeframe of 12 to 18 months with qualitative and quantifiable strategic goals we call destinations.
We follow a dual track roadmap: we plan what we're going to deliver in the next 6-week cycle with a clear ROI ambition, as well as what we're planning to discover. Anything beyond that line we view as options.
Our stakeholders understand and appreciate this format because they co-invest with us. They recognise the future can't be predicted, so they follow a now/next/consider structure due to the inherent uncertainty of the product system.
What percentage of ideas come from top down and what percentage come bottom-up?
We embrace a more transversal logic. Our teams and stakeholders carry continuous dialogs, collaborating to identify opportunities designed to bring us one step closer to our business goals.
Now, you might ask, where does leadership fit into this? Well, our primary role at the leadership level is to provide the teams with sufficient clarity and competence. We're here to ensure they're well-positioned to hold the reins of their own roadmaps and ROI. In essence, it's about instilling autonomy, not dictating ideas. So the high-level strategic destinations come from the top, but what it means on the field and how we get there come from our product trios.
Do you use OKRs?
Yes, we do utilize OKRs, but not in the traditional quarterly sense as it tends not to make sense for product teams. We observed that the internal competition that quarterly OKRs foster doesn't work everywhere.
For me, it's like trying to mix the universally cooperative Swedish way of doing things (think Spotify “model”) with the competition-based OKR model. It's a scrambled blend of two entirely different flavors, and, frankly, didn’t work for us. We found that mixing such cultural approaches caused more chaos than cohesion.
I believe that OKRs should be based on a core strategy of reaching a common destination. That strategy should say, "we have destinations, and we need to find a way to support each other in reaching them.”
However, I've seen too many companies, including ours at some point, transitioning their OKRs into fragmented goals. Marketing has their OKRs, and individual countries have their OKRs, but the concept of working together to achieve something gets lost. This leads people to claim, "it's not on my OKRs, so I won’t do that."
So we shifted our approach. We now follow yearly OKRs that are product-led and strategically linked. Our product teams and tribes decline these OKRs with the help of stakeholders and take responsibility for reaching the outcomes.
I'd like to stress that it's not the OKRs themselves that are the issue, but rather how they're implemented and understood. OKRs can be effective if used considerately, fostering cooperation, focusing on qualitative customer outcomes and quantitative product & business outcomes. It requires an understanding that everyone who can contribute should be warmly welcomed.
OKRs are not meant to create borders or division within the company. That is why l feel they should not be universally applied. For an organization to thrive and for OKRs to not “stupidly” function, they should just be objectives strategically linked to specific desired outcomes. It's about maintaining focus on what truly matters.
How is your product org structured?
Our product organization used to be structured into three primary domains: supply, demand, and payment, with additional teams handling platform, business operations and salesforce tasks. However, we shifted this arrangement to form three tribes focused on the Diner Experience, Restaurant Experience, and Internal User Experience.
Now, to clarify what I mean, when I refer to "teams," I'm talking about how we rethought our approach to the earlier problem, where teams became overly focused on individual components. For instance, the "Search" team was only about search, missing out on the broader understanding of what people were really trying to find.
We realized that this led to a lack of holistic thinking. The teams were operating in silos, focusing only on their specific tasks and not really considering the larger journey. So, we decided to remodel the team structure around the actual user journey.
The first step in this process was a role-play situation. We wanted our teams to understand and internalize the user experience. Essentially, we challenged them to imagine guiding a friend visiting Paris for the first time through the process of finding a restaurant.
From these exercises, we renamed teams based on the behavior we'd like to model. This approach made it much easier for teams to understand and empathize with the user's journey.
So, under our new structure - take the Diner Experience tribe as an example - teams are organized around each step of the journey. They no longer "own" parts of the product but are "guardians" who work together to improve the overall user experience.
Those teams contribute to metrics related to the strategy. They act as a “team of teams”, focusing on improving use cases linked to the strategy, and our strategies guide our organizational structure and not the other way round.
So, when I say structure, think of it less as a rigid framework and more as a fluid, adaptable journey everyone's participating in.
What’s the ratio of PM to engineer to design?
The structure of our teams is based on a trio concept, which to me is non-negotiable. It's an approach based on the military, specifically the concept of trippers, who are always in groups of three for surveillance and such. The idea is that with three individuals if there are disagreements, a majority can always be found.
Applying this to our product operations, we operate in trios with product managers, engineers, and designers. While the ratio within these trios is essentially 1:1:1, we also extend the count of engineers, usually ranging from four to six. In the past, we used to associate more engineers, which, upon retrospection, seems to have been a mistake due to legacy organizational constraints.
Further, we have supporting roles in the organization including specialists, marketers, researchers, writers, and content designers. Additionally, management considers itself to be in a support role as well, ensuring that everything is running smoothly. Rather than positioning any hierarchy as a vertical line with me at the top, I view the organization as a whole, working in a supportive, triadic model for the best possible outcomes.
What would you say is unique or central to your approach, organizationally or professionally?
How we've operationalized the autonomy and responsibility of our product teams. This particularly applies to our product trios. It's this initiative that enables stakeholders to reach a clear return on investment or ROI. It brings a sense of responsibility while promoting creativity and strategic thinking within our teams.
How has behavioral/product tracking evolved?
Well, initially, to be frank, there was not a lot of tracking. Most teams complained about their lack of autonomy in the matter, but I have to be honest, it was sometimes just an excuse not to track.
Then we introduced product metric trees, a real game-changer, that capture the success equations of our teams, tribes and strategy. This was done with a clear ambition so all evolutions were centered around customer outcomes, product outcomes, and business outcomes. Without this focus, it was pretty much impossible to even consider the potential ROI of the work it takes to implement tracking. Now it’s clear.
How do you capture qualitative feedback?
On the B2C side, we collaborate with marketing teams to comprehend their objectives and attempt to merge them with our operations on the consumer side of the application. Yet, it's tricky as their Marketing OKRs, such as Click Through Rate for example, don't always align with product goals, like improving the overall user experience. Hence, one has to be cautious and strategic about what's put into effect.
Capturing qualitative feedback in our B2B context involves a multifaceted approach. We usually start by working closely with people who have direct contact with the clients, our proxies. This includes sales representatives, trainers, and customer care. We estimate that they have about 80% of the information that we need at an 80% quality mark. To fill in the remaining gaps, we supplement our data with analysis and interviews. Our job is essentially to cross-reference and organize the information gathered from the field, a task typically managed by team leaders.
This feedback collection process is ongoing and can take place at any time, and not just within specific deadlines. The ability to efficiently adapt to new challenges is an essential part of our operations, as it allows findings to be collated and acted on in real-time.
In an effort to cut through the "product gibberish" (I call it produxplaining), I encourage my team to focus on the benefits we aim to offer our customers rather than focusing solely on problems or needs. Thus, they can pitch at any time. The pitches, usually a concise document, get shared on Slack for collaborative input. Then, they delve deeper to capture additional insights, sometimes collaborating with our counterparts in other areas such as France and Spain.
Marriage between the feedback from customer care and trainers and our own initiatives completes our approach. We can direct these teams to focus on certain problem areas if needed or even have them propose a call with us to provide more detailed insights. The beauty here is that they are eager to help. Trainers, despite handling only a small fraction of our customers, still manage to provide us with insightful feedback. And, to ensure that there's no backlog, everybody has a part to play.
In terms of success rate, let's just say we've been pretty lucky. The system works well for everyone and the reciprocal benefits are undeniably a big reward. So, capturing qualitative feedback involves a copious blend of strategies, all aimed at delivering benefits to the customers and ultimately, the company.
How does qualitative feedback impact your prioritization? What’s the journey from feedback to delivery?
Our journey from feedback to delivery doesn't actually start with feedback but with strategy and strategic destinations. What we typically do is look for investment opportunities that align with our focus, in terms of business and usage segments as well as use cases and outcomes. Feedback, in this context, is instrumental in helping us identify patterns, thereby uncovering new opportunities.
Once we've singled out an opportunity, we earmark a cycle of about 6 weeks to progress from a place of mid or low confidence, to finalizing the design for a first solution iteration that can be implemented in the succeeding cycle. This phase involves digging deeper to understand user needs better, grasp the market and its competition better, and analyze what our current solution might be missing.
From this, we refine a problem for further solution discovery in acceptance of anything that brings an increment of confidence, even if this involves pushing code in front of a user. By the end of this discovery cycle, we not only have a refined problem but also a refined design to kickstart the solution, all of this neatly tied together with a clear ambition set by our appetite.
The actual delivery cycle is dedicated entirely towards iterating on the developed solution and ensuring that both Go-to-market and Go-to-customer aspects are dealt with appropriately.
What’s in your product team’s tool stack?
Notion, Figma, ContentSquare, Tableau… but also a lot of Slack, Google Meet (beyond pure remote, my teams are spread in 6 offices in Europe) and a bit of Reforge!
How do you manage feature/project rollouts with other departments?
It involves various departments which includes those involved in the investments and in the go to market, as their input is absolutely crucial. Our product managers, with the aid of product marketers, play a significant role in making sure the go to market and go to customer strategies are refined and well-understood internally.
What do you look for in product hires and what does your interview process look like?
I look for people who understand the law of the double impact. To be more specific, I want someone who understands that product organizations are not aimed at ensuring ROI for the business AND for the users. Candidates who only focus on user-centricity or who obsess over metrics and growth without taking into consideration the real-life experiences of our users don't fit in with us.
My interview process is really about exploring the candidate's experience. I'm eager to hear how candidates talk about success and failure.
One question I love to ask is, “What was the worst product decision that you made in your life?”
Those who can't think of one probably were either not responsible or they haven’t reflected on the failure. That's not what I'm looking for.
To understand what they consider 'success' is crucial too. Did they deliver a great user experience? Do they mention the financial aspect even with design? For example, I'm not just looking for UX designers but for product designers. These are individuals who appreciate design in a way that they understand the constraints of the product.
The same goes for product managers. If they only talk about profit and usage, but overlook the importance of user experience, we're going to have a problem.
My end goal is to find people who understand that their responsibility includes both aspects – the ROI for businesses and end-users. I'm more interested in their approach to problem-solving, their perception of success and what they consider a success personally, rather than their theoretical knowledge. Because honestly, theory can be learned, but the way you look at problems and success is inherent. And for someone with the right inherent abilities, I'm willing to compensate for what's needed to keep them here.
What did you believe 10 years ago that you no longer believe today?
Oh yes, a decade ago, I hung my hat pretty heavily on the frameworks. I threw my weight behind the biggest defenders, you know? I used to be adamant that there should always be 80% unitary test coverage when testers checked product integrity, and cling to the traditional two-week sprint cycles.
Now? I consider the way each team organizes between functions is not my concern. What interests me is the investment process; I want to understand the decisions you're making, and why. It's all about accountability. I want to know why you're investing here, or why you chose this point for delivery. That's it. That's what it boils down to for me - because I'm going to give you a top line projection and from there, it's your responsibility to manage it.
So now, I approach things based on necessity, the maturity of the team, and the circumstances of the company. In the end, what really matters to me is that the teams are genuinely autonomous and responsible for the outcomes. Not just in word, but in deed. That's what I've come to learn over these ten years.
What are fun or unique traditions or rituals on your product team?
We love our food! We're spread out across three countries with strong regional food specialties, with a mix of nationalities: chinese, ukrainian, argentinian… It brings together many different food cultures. But, no matter what the cultural differences might be, we find common ground in going to restaurants. We embrace the "Eat your own food" philosophy, and I mean it quite literally! I find that the expression has never been so true and hilarious at the same time. This tradition certainly adds a fun flavor to our product operations team!
Alright, I have to ask: What’s your favorite restaurant?
My favorite restaurant has to be Le Clarence in Paris. It's a two-star restaurant that I initially visited with my product director.It's on the expensive end, really, really expensive. On my visit, I went all in, including wine-food pairing & truffle option, and that ended up costing 600 euros per person. I know it sounds exorbitant, but it was absolutely amazing. Truly a once in a lifetime type of culinary delight.
A huge thank you to Fabrice des Mazery for sitting down and speaking with us. You can find him on Linkedin here.
•
Again, we hope you enjoyed this article and got value from it. Please consider sharing this Product Collective email with your colleagues, or head directly to our blog to view this post on the web.