The how-to behind transformation
From order takers to problem solvers
Last month, I shared the first part of The Palace Company's transformation journey. We looked at how they broke free from the project-based cycle that was holding them back. We explored their false start with "fake agile," the leadership catalyst that changed their trajectory, and how they used a pilot team to prove what was possible.
This week, I'm diving into how transformation really happens, using The Palace Company’s real-life success story to bring the theory to life. If you missed Part 1, no worries — you can find it here, though each piece stands on its own.
From Projects to Products: The Product Operating Model
One of the biggest shifts in any transformation is moving from a project-based mindset to a true product mindset.
A project approach is finite and assumes the team will be “done” by a set date. Projects are typically large, slow-moving efforts and are considered “complete” when the team finishes the specified features or delivers the output agreed upon by the management team. There’s little sense of accountability or ownership since the team often disbands once the project ends.
A product approach is very different. Long-standing, cross-functional teams are given problems to solve, typically framed as business outcomes. These teams are accountable for results and focused on building what delivers the most value to users while also meeting business needs. They’re never “done” with the product since there’s always more business and user value to drive.
3 core elements must change for teams to operate within the Product Operating Model and make the shift from project teams to real product teams:
1. How They Build
One of the most critical shifts is moving from big, infrequent releases to small, frequent, reliable ones. But this goes beyond implementing CI/CD pipelines — it requires changing how teams break down work, how they collaborate, and how they measure success. It requires teams to get really good at understanding the smallest possible thing they can deliver to achieve the goal.
Palace made this shift in how they build. For example, their restaurant reservation team moved away from a waterfall approach — design everything, then build everything — and began testing solutions iteratively. They started by manually testing a waitlist and notification system to validate the concept before building the tech solution. This allowed them to learn, adjust, and, most importantly, deliver value for users before committing significant resources.
2. How They Solve Problems
A major mindset shift is moving away from giving teams features to build, and instead giving them problems to solve, outcomes to achieve, and the coaching to do discovery effectively. That shift in framing made all the difference. Here’s an example from The Palace Company:
Before: "Build these 15 features in the restaurant reservation system."
After: "Guests can't get reservations at their preferred restaurants. How might we increase the percentage of guests who can dine at specialty restaurants by 30%?"
This change empowered the team to explore multiple solutions, including adjustments to booking policies, improvements to the reservation flow, and a smart waitlist system that prioritized guests who hadn’t yet dined at the restaurant and whose checkout dates were approaching. The result: a 30% increase in guests who were able to access specialty restaurants, and none of the original 15 features were built.
An important disclaimer is needed here: accomplishing this requires work both inside and outside the technology organization. The work mentioned above is what happens inside tech — reframing what success looks like and empowering teams to achieve it. However, just as important is the work outside tech: shifting the relationship with stakeholders. They move from requesting features to becoming true partners to the product team, representing their business area.
To make this possible, we had to meet stakeholders where they were. There’s no benefit in forcing a new model on reluctant stakeholders. What worked was clearly and consistently showing that this approach solved the problems they cared most about.
Don’t start with abstract culture initiatives—culture change follows structure change. Change how teams are organized, how work flows, and how decisions are made. The culture will shift as a result of those concrete changes.
3. How They Decide Which Problems to Solve
Deciding which problems to solve and when is the final piece of the transformation process, and usually the hardest one to tackle. That’s because getting this kind of buy-in from the organization takes proven success. Without that proof, there’s no way they’ll hand over that responsibility, and honestly, if I were in their position, I wouldn’t have either.
Palace’s transformation extended to how they decided which problems deserved attention. They moved away from the “loudest voice in the room” or “highest paid person in the room” approach and adopted a structured process. Product, technology, and design leaders came together to identify problems based on a customer-centric product vision and an insight-driven product strategy.
The product vision and product strategy were the two key artifacts that made this shift possible.
Getting buy-in for the technology team to help define strategy and what problems to solve required more than early success. We also needed trust when it came time to prioritize and commit. In both cases, data was our best friend. It enabled us to move past opinions and speak from a place of genuine understanding of both the user and the business.
The Head of Data at The Palace Company played a crucial role in this shift, helping teams anchor decisions in actual behavioral data rather than assumptions or anecdotes. This was especially powerful for skeptical stakeholders — data became the clearest source of truth.
The essential changes needed come from Marty Cagan’s book Transformed. It is, to me, the comprehensive guide to the principles and best practices behind successful transformations.
There’s no such thing as a transformation project: It’s Never "Done"
Transformation isn’t a one-time exercise with a clear endpoint. I don’t advocate for teams to build products as projects; they tend to become long, slow, overly planned efforts that deliver low to no value. The same is true for transformation.
You should treat transformation as a product, not a project. It’s an ongoing journey of organizational evolution.
The goal isn’t to perfect your processes because those don’t make customers happier or companies more money. The real goal is to build an organization that can continuously adapt to solve customer problems and deliver business value.
Here’s how to think about transformation the same way you think about your product:
This post feels especially timely since last week was something special. I had the chance to look back at some of the key moments in The Palace Company's transformation journey so far. Alongside the SVPG partners — Marty, Lea, Jon, Christian, and Chris — we visited Anuar and his incredible team at The Palace Company.
Anuar and I reminisced about the journey so far and shared with the group some of the pivotal stories behind this change. We reflected on how every time I visit, I say, “This looks like a different company,” and the truth is that it is because to truly transform, you need to break the molds of what it once was, change behaviors and beliefs, and, more importantly, change the mindset.
Transformation is only possible when the people involved are insanely committed and willing to change. This transformation would not have been possible without the people in the picture below, and it brings me such joy to see what is possible when a company decides this is the way it truly wants to work.
This is so cool, Gabi!