43:21
product operating model
According to Anoir, chief product and technology officer at Palace Hotels (an 18-property, ~15,000-employee Mexican hospitality company), the company ran a roughly two-year product-model transformation — without an army of consultants or a 'born-into-it' product leader — that replaced a waterfall 'software factory' disguised as agile ('transformation theater') with empowered, outcome-driven product teams, and this shift is credited with concrete business results such as booking-engine conversion rising from under 1% to over 5%.
Palace Hotels' business was performing well (record post-COVID years), but Anoir argues the good results were not caused by the technology being built — the motivation to transform was that technology work wasn't delivering value, not that the business was failing.
Before transformation, the ~150-person tech org functioned as a 'software factory': 'translators' turned business requests into prioritized lists, funded as projects that flowed through prototype → story points → development → Jira 'done' → deployment by a separate infra team → team dispersal.
This delivery model looked agile (ceremonies, titles) but was structurally waterfall — Anoir calls this 'transformation theater.'
Anoir had no prior tech/product background; the shift began after he attended Marty Cagan's 'Transformed' workshop in New York, where he moved from doubting the product model could apply to a traditional Latin American family business to believing it was necessary.
Coach Gabby (Bufrem/Buffram) was introduced by Marty; her first question to Anoir was 'what's your plan B?' — his answer, 'there's no plan B,' becomes a recurring frame for his commitment.
Before any formal diagnosis, Gabby spent in-person time in Mérida building trust with the team and with Anoir's co-leader brothers.
A three-part assessment (how you build software, how you solve problems, how you decide which problems to solve) concluded the company hadn't earned the trust to change *what* problems it solves, so the starting point was changing *how* problems get solved.
A single pilot team (a future PM, designer, engineers) was formed around a customer-facing but non-critical area and coached by Gabby at least 1.5 hours weekly, with the explicit bar that leadership be amazed and floor staff want to join.
The pilot team initially assumed the solution was a mobile booking app (based on an old survey where 40% said they'd like to book via app) but, after direct customer research, decided not to build it, instead improving an existing, unmaintained booking web page — tripling conversion.
The booking engine's conversion rate rose from below 1% to above 5% over about 1.5 years of focused work on the guest booking experience.
Core mindset shift: teams moved from being handed feature lists ('futures to build') to being handed problems/outcomes, with success redefined as the intersection of customer happiness and business viability rather than shipped output.
The pilot's success 'couldn't scale' on its own, so the company hired product leaders, a head of data/analytics, and engineering leaders, and shifted project funding from speculative, sales-skewed ROI cases to outcome-oriented metrics.
Data/analytics became both a decision tool for teams and a political trust-builder, used to disprove internal 'myths' (e.g., 'we need an app') and to counter 'the more stubborn person in the room wins' funding dynamics.
Team topology was redesigned into durable teams by business vertical (sales operations, vacation club, HR, hotel operations, etc.) that permanently own their software's maintainability, security, and quality, roughly 1 PM : 1 tech lead : 1 designer (or 1 designer per 2 teams).
A cross-functional example: converting abandoned online bookings into call-center leads drove $600,000 in bookings in about two months and surfaced insight (e.g., payment-security concerns) that improved the self-serve flow.
Non-digital operational problems (restaurant reservation scarcity at the resorts) were reframed as product/discovery problems — helping guests find under-used restaurants — as an alternative to capital solutions like doubling restaurant size.
Anoir's brothers were the hardest, last people convinced; after about a year, a trust crisis over what counts as 'done' (stakeholder sign-off vs. outcome-based) was resolved via a full-day sit-down among the three brothers, grounded in a family principle to 'protect the company from ourselves.'
A leadership overhaul was necessary because the broader team could adapt to the new way of working but the original leadership largely could not; only one original leader survived and became the company's first product manager.
Closing advice from Anoir: trust an established methodology/mentor (Marty's teachings) over personal instinct, and get a coach who acts as a 'guiding light' keeping you oriented through distractions.
Three-part transformation assessment — Gabby's diagnostic framework evaluating a technology function on three separate axes — how you build software, how you solve problems, and how you decide which problems to solve — before deciding where to intervene. Apply: Before starting a transformation, assess build quality, problem-solving process, and problem-selection trust separately, and start with whichever axis you already have the credibility to change.
Pilot-team methodology ('start small, then start big') — Standing up one small, high-caliber cross-functional team (PM, designer, engineers) in a customer-facing but non-critical area to prove the new model before scaling it. Apply: Pick a visible-but-safe-to-fail domain, staff it with your best people, aim for an obvious 'wow' result, and use that proof to justify expanding to more teams.
Transformation theater — A pattern where a team adopts agile ceremonies, titles, and terminology while the underlying delivery flow is still linear/waterfall — 'done' defined by matching an original spec rather than by achieving a customer outcome. Apply: Audit whether 'done' is defined by shipping a pre-agreed spec (a waterfall tell) versus by a measured outcome, regardless of how agile the surrounding ceremonies look.
Outcome-based definition of product success — Redefining success as solving a problem in a way that satisfies customers and works for the business, rather than as shipping a feature. Apply: Give teams a problem or outcome (e.g., 'increase online bookings') instead of a feature spec, and measure them against the resulting metric rather than delivery of output.
Product discovery as 'detective work' — The idea that neither customers nor internal stakeholders can directly state what should be built, so the product team must synthesize clues from both to find the solution. Apply: Treat customer interviews, field visits, and business signals as evidence to interpret rather than requirements to transcribe, before deciding what to build.
OKR-style key results for product teams — Using a single measurable key result (e.g., share of bookings made online vs. via call center) to define what a team is accountable for. Apply: Attach every team or project to one outcome metric tied to a business result, and fund and evaluate the work against movement on that metric.
Discovery-led build-vs-improve decision-making — Using direct customer and field research to decide whether to build a new solution (e.g., a mobile app) or invest in improving an existing but neglected asset (e.g., a booking web page). Apply: Validate the assumed solution with real user research before committing budget to a new build, and redirect effort into fixing what already exists if research contradicts the original plan.
Head of Data/analytics as decision infrastructure — A dedicated data/analytics function that supplies teams and business stakeholders with a shared, trusted data source for decisions. Apply: Stand up a data function early so it can power team-level experiments and also serve as a neutral, credible reference that overrides opinion-driven or politically-loudest decision-making.
Team topology with durable ownership — Organizing product/design/engineering into standing teams aligned to business verticals (sales operations, vacation club, hotel operations, etc.) that permanently own their software's maintainability, security, and quality instead of dispersing after each project. Apply: Design team boundaries around business domains and keep the same team attached to a product area long-term so accountability for quality isn't lost at handoff.
Continuous discovery via operational instrumentation — Turning an operational event (an abandoned online booking) into both a business action (a call-center follow-up lead) and a research signal (why guests didn't complete checkout). Apply: Instrument drop-off points in a workflow to simultaneously recover near-term revenue and generate ongoing qualitative insight that feeds product improvements, such as adding trust-building messaging at the point of friction.
Structured stakeholder retrospective/alignment session — A full-day, agenda-driven sit-down (what happened, why, the plan, what went wrong, prevention, mutual changes needed) used to resolve a trust breakdown between the tech function and business co-leaders. Apply: When trust between functions or leaders erodes, convene a dedicated full-day session structured around a fixed retrospective agenda rather than letting the conflict resolve informally.
External coaching as sustained orientation ('guiding light') — Using an outside coach not primarily to train skills but to provide continuous course-correction so temporary distractions don't derail the transformation. Apply: Engage a coach for the duration of the transformation, not just an initial workshop, and use them to re-orient the effort whenever it drifts.
'Software factory' delivery pattern — A named anti-pattern in which a 'translator' role prioritizes business-dictated feature lists into projects that flow through prototype → story points → development → Jira 'done' → separate deployment team → team dispersal. Apply: Recognize this handoff-heavy, project-based flow as a diagnostic sign that a technology org is output- rather than outcome-driven, and treat eliminating it as a transformation goal.
The transformation deliberately started with 'how problems are solved' rather than 'which problems to solve,' because the org explicitly judged it hadn't yet earned the credibility to touch problem selection — a sequencing choice, not a default.
The most consequential product decision in the case is a 'do-nothing' decision — not building the planned app — reframing discovery as risk-avoidance (dodging a multi-million-dollar sunk-cost mistake) rather than only opportunity-finding.
Data's first payoff wasn't optimization but internal politics: it functioned as a neutral arbiter that could override 'loudest/most persistent person wins' funding dynamics and unfounded internal beliefs like 'we need an app.'
Family-business governance shaped the methodology as much as product theory did: a full-day brother-to-brother retrospective and an explicit 'protect the company from ourselves' norm were used to resolve a trust breakdown, showing the transformation ran through family dynamics as much as org process.
Physical/operational capacity problems (restaurant overcrowding) were treated as solvable via a software 'discovery' feature as an alternative to capital expenditure (doubling restaurant size), reframing product work as a lever against construction costs.
The coaching relationship was unusually intensive and personal (weekly 1.5-hour sessions, night-to-7am article exchanges), functioning less as skills training and more as a sustained accountability/orientation mechanism ('guiding light').
Buy-in was engineered bottom-up through demonstrated proof at small scale (the pilot team's visible win) rather than by top-down mandate — the pilot's success is explicitly framed as what gave 'permission' to expand further.
«Just spending every day of every every hour of every day coming to the office and making a lot of effort for us to deliver something that doesn't have any value is just nonsense from my point of view.»
— 01:19
«I asked him what what if this doesn't work like what's plan B here and he just looked me straight in the eye and he's like there's no plan B this is it.»
— 08:17
«We don't have trust at all to be telling people that we're going to change the problems that we solve. We have not earned that right yet.»
— 10:27
«The funny thing is that we didn't build anything because thanks to this research we ended up realizing that this multi-million dollar effort was going to waste.»
— 12:56
«It looked like agile, but behind there was a big waterfall... all the agile ceremonies, all the titles, all the things... kind of like transformation theater.»
— 14:14
«We need everyone in leadership to be like wow that is amazing. And we need everyone on the floor being like I want to be on that team.»
— 15:02
«Customers are not going to tell you what to build. Your teams are not going to tell you what to build because they don't know. This is your job and this is what's fun about doing product.»
— 17:37
«the conversion rate from that booking engine was below 1% and it's now above 5%»
— 20:39
«We gave people futures to build rather than gave them problems to solve.»
— 21:02
«the more stubborn person in the room wins»
— 30:48
«let's protect the company from ourselves if we're if we are ever in a disagreement»
— 34:30
«stop having thoughts of my own and start trusting Mart's thoughts on everything that has to be done»
— 39:30
«they're the guiding light... show you where you should go. Then you're not going to get lost. You may get distracted... then you know how to correct course and get back to it.»
— 40:08
«This has to work. There's no plan B.»
— 41:34
«I hired a team that allows me to be bold.»
— 41:56
Reception
Comments are overwhelmingly short, generic praise ("nice video", hearts, thanks) with no substantive criticism, though the uniformity suggests low-effort or possibly engagement-farmed positivity.
The episode is a promotional but substantive case study from SVPG (Marty Cagan's organization) featuring its own client and its own coach, so it functions partly as testimony for SVPG's coaching/workshop offering; within that framing it offers unusually concrete specifics — metrics, pilot-team mechanics, and family-governance dynamics — not typical of generic transformation content.
43:21