This article is an in-depth summary (I know, ironic) of an interview with Dimitra Retsina, Interim Chief Product Officer at Sana Commerce. You can watch the full interview ​on YouTube​.

Enjoy, and as always: Reach out with your thoughts, questions, comments.

—

I'll be honest I struggled with the headline. What ​Dimitra Retsina​ shared blew my mind.

We have 2 major stories in this conversation:

1. The 5 stages of AI adoption that every company goes through.

2. An example, inspiration of how even a 20-year-old company with big legacy can adopt AI meaningfully even though the end state is not the LinkedIn type AI-Native-Company-Story.

So, read this article with both lenses.

I met Dimitra at the Product Mastery conference in Amsterdam. She mentioned her company was going through an AI transformation and casually started describing amazing results.

“Tell me more!” - I said.

Thankfully, she said: “Absolutely yes.”

She hadn’t just led an AI rollout at Sana. She joined the company in December 2024, was given the CPO title in January 2025, and from that point forward she was simultaneously repositioning the product toward a new ICP, redesigning the platform architecture, inheriting a 150-person product and engineering organisation across multiple cultures, carrying the CTO responsibilities alongside her CPO role, taking over the data team, and introducing an AI transformation company-wide.

All in under a year.

Sana Commerce is a B2B e-commerce platform, 20-plus years old, 450 people. A well-established company with two decades of product decisions, technical choices, and deeply embedded ways of working, all of which she had to move. Her mandate was to turn product and technology into a measurable value creation engine. And to do it fast.

Here is the story of how she achieved it.

The Five Stages of AI Adoption: Fear, Push, Pull, Run, Hold

Dimitra described the journey of her organisation over the past year as having gone through five stages: fear, push, pull, run, and hold.

Phase 1: Fear

Dimitra landed in a company culture where engineers had been told, repeatedly, that AI was dangerous territory. The Infosec officer was, in her words, "very passionate about his job" and had spread enough fear that nobody in engineering wanted to touch these tools at all.

So her first move wasn't technical. It was political.

She needed legal, infosec, IT, and the management team on board before she could get the engineers to join. She made the case in business terms: here is what it will cost us if we don't move. The CEO and management team cleared the way, essential to unblock everything. Then, she worked with the security officer to update Sana's ISO 27001 protocol, addressing his concerns directly rather than overriding them.

She also took over the data team, which had been a global shared function, because she knew that without data infrastructure, none of the AI ambitions would hold. Ultimately, they were not only aiming to improve efficiency, but also to create customer value through AI that was aligned with their product strategy. She redesigned data architecture and governance from scratch.

With that foundation in place, she turned to the engineering team.

She found the same fear, now rooted in distrust rather than security rules. Her approach was similar to what I’ve heard from other companies: find the one person who isn’t afraid.

She had a genuinely curious data analyst on the team who was interested in data engineering as well. She gave him access to Cursor, Windsurf, and Devin, and he eventually picked the latter. Within days, he was using it to rebuild data pipelines, delegating the generation work while doing the higher-value thinking himself. She used these results to show the rest of the engineering team what was possible.

Phase 2: Push

Then she ran a three-day internal hackathon. The company got enterprise licences for a range of pre-vetted tools, such as Cursor, Windsurf, Devin, and others. They organised small teams, each with a specific goal and a general brief: go build something.

Some teams succeeded, others didn’t, but the goal was to show what was possible.

One of the more telling moments came from a documentation project. A team used Cursor to try to auto-generate missing documentation. There were hallucinations, but the engineers (who always hate writing documentation) discovered that they didn't have to create it from scratch. Instead, they could edit it. That was enough for them to start seeing the potential.

At this point, the team could accept that AI was useful, but they weren't yet pulling toward it on their own. To accelerate that, Dimitra used two tactics:

The first was personal stakes. She started talking to engineers not about the company's need to move faster, but about their own careers. She used an analogy that compared tools to excavators and shovels. She told them that if they kept picking the shovel, they'd eventually fall behind, not just the company, but them personally.

The second was timeline pressure. She gave the team tight deadlines to deliver differentiation value fast, in support of the new ICP positioning. "If you go with a shovel you will go slow. If you go with the excavator you can go faster. So you choose the timeline."

It was a risky move but she stayed close to the work and was explicit that AI tools did not remove the need for architectural design, code review, and deep engineering thinking. They could expedite what could be generated, but they couldn't replace what had to be designed.

The results from this phase arrived fast:

• 40% reduction in QA automation execution time, achieved by migrating their automated test suite to a newer technology that had long been postponed

• 50% reduction in their manual testing suite

These results were the turning point from push to pull.

Phase 3: Pull

The pull phase arrived when Dimitra gave everyone (not just engineers) access to AI as a thinking partner. Every person in the product-design-engineering organisation got a ChatGPT account. A sparring partner, as she described it: something to discuss plans with, challenge missing elements, and break down problems. Once people could use these tools on their own terms, in control, at their own pace, they started choosing to. They built trust through use, not mandate.

Engineers moved toward more nuanced tool preferences, with the majority settling on Cursor, and some recent signals showing people gravitating toward Claude. The company's job, Dimitra said, is to "accommodate the evolution" of what its people actually need, not lock them into a single toolchain.

For designers and UX, the assessment was more rigorous. She tested a range of tools - v0, Lovable, Replit, Builder.io, Framer - against specific criteria: integration with Figma, adherence to a 20-year-old design system, and the ability to evolve an existing application's experience rather than generate from zero.

She made an observation I hadn't heard from anyone else in these interviews: none of the current AI design tools offer recommendations based on actual usage data. They're trained on what's been publicly created, not on what actually performs better. They ended up choosing Builder.io, which is now used by all UX designers, product managers, engineers, and professional services.

Phase 4: Run

By the run phase, more than 60% of committed code consistently matched AI-generated suggestions. Not used as-is, but taken as the basis, reviewed, and adapted through proper engineering process.

Dimitra views that number as a measure of adoption, not a justification for headcount changes: the architectural work, the reviews, the senior judgement… those don't disappear. If anything, review load increased as output volume went up. "AI made what was already fast, faster," she said. "The hard work has always been the design and the review."

Phase 5: Hold

The hold phase is where they are now: governing what they've built.

Moving from verbose prompt documents to spec-driven development, and managing the fact that other functions outside product and engineering now want to build internal AI tools of their own. That appetite is real and growing, and it brings GDPR compliance questions, data access controls, and accuracy measurement requirements with it. "It spreads like a virus," she said. "So you have to introduce governance.”

How the Team Works Now

Here's what the end-to-end process looks like now:

The process starts with teams pulling data from Dovetail, win/loss data, closed-lost reasons, RFP insights, customer interviews, survey data… and using AI to surface themes and synthesise across sources.

That data then feeds Impact Mapping sessions, cross-functional conversations with stakeholders from the whole organisation. Having the analysis ready makes those sessions less opinionated and more grounded.

From there, the team identifies what to validate and moves to co-creation. Last summer, Dimitra set up what she calls the Inside Circle programme, a pool of customers who co-create the next versions of Sana's functionality. She uses a "bullseye customer" selection, matching participants closely to the persona and problem they're trying to solve, rather than inviting anyone who's willing to join.

The team builds prototypes in Builder.io and takes them to multiple bullseye customers in a single day. They don’t make changes on the spot, but reiterate with the same customer if needed a couple of days later. It now takes under a week to go from idea to validated design. The same process used to take several weeks.

Those same prototypes have a second use: sales and pre-sales enablement. Rather than describing upcoming product value, Dimitra shows it to them interactively, in Builder.io. For enterprise B2B customers, the prototypes become a vehicle for early conversations about where the product is going.

Product Strategy: Choosing the Problem, Not the Tool

All of this internal transformation is in service of something Dimitra was clear about from the beginning: delivering AI value to customers in a way that makes sense for them.

Sana's ICP is manufacturing enterprises, B2B buyers making high-stakes purchasing decisions. These are not the same as B2C consumers browsing for trainers. The idea of handing a purchasing decision to an AI agent, Dimitra said, "keeps you up at night" in this context. The financial stakes are different, and so are the trust requirements.

So rather than rushing toward AI-powered automation, Sana is building toward guidance and findability first, keeping buyers in control, building habits, creating the foundations of trust before asking customers to let go of anything.

She was also direct about economics. "AI features are expensive. Every call costs something. It's not like any other SaaS platform that you can scale to infinity and costs are still minimal." That shapes every investment decision: you have to be disciplined about where the value actually is.

Her logic for it comes from her engineering days: "You don’t choose the tool first. You choose the problem."

Dimitra’s Advice

I always end these conversations by asking my guests what they would tell a peer starting this journey today. Dimitra had four pieces of advice.

The first: understand what drives the need, but also what drives the resistance. Why isn't adoption happening? What's preventing it? And what does success actually look like if it does? Knowing the answers before you start is what separates a transformation from a rollout.

The second: do the product work you always did. "If you just slap AI everywhere, it doesn't mean you're going to build a differentiating product." The rigour that goes into any other product decision has to go into every AI feature too.

The third: don't skip governance. Otherwise, you may have to revoke things you've just introduced, and that has a cost. She called it “AI debt”.

Finally, she ended with a very powerful idea. She had a coach who used to ask her not what she wanted to do in her next role, but what she wanted to do in the role after that. She applies the same three-horizon thinking to AI strategy because in a market moving this fast, if you're only planning for now and next, you're already behind.

What I'm Taking Away

One of the most interesting aspects of this conversation was seeing how a 20-year-old company with legacy code, legacy culture, B2B relationships built on trust, and a brand to protect can still make AI adoption work. And work well.

On LinkedIn, we tend to celebrate the extreme cases: super small teams, merged roles, everyone becoming a builder overnight. Sure, those cases are real. But they've become the default image of what AI adoption is supposed to look like and that's a problem, because it makes every other path feel like a failure. But AI Adoption doesn't have only one end state.

Dimitra's story is a great reminder that the end state can look completely different and still be entirely valid. You don't have to become an AI-native organisation to take real advantage of AI. You just have to find what works in your context.

The second thing I'm taking away is a pattern I keep seeing across every conversation in this series: the product creation process (the principles, practices, and fundamentals) stays the same. What changes is how teams execute it. Faster, more collaborative, with shorter cycles.

The third takeaway is the blueprint itself. Fear, push, pull, run, hold. Every company I've spoken to has moved through these stages in some form: bottom-up enthusiasm, top-down pressure, gradual trust, then the sprint, then the work of holding it together. It's almost like a hero's journey. The good news: that makes it something you can actually prepare for. Take Dimitra's story as an example of how to go through these stages explicitly. Get inspiration from it and adapt these stages to your own situation and context.

—

This article was edited by Diana Bernardo.

The video was edited by Connor Clayton's team at Precision Edits.​