This article is an in-depth summary (I know, ironic) of an interview with Guannan Li, Director of Product Growth & Design at Ablefy. You can watch the full interview ​on YouTube​ and read the web version of this article here.

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

--

A friend sent me​ Guannan Li​’s presentation about AI transformation at​ Ablefy​ with one sentence:

“You must speak with her.”

Five minutes into the slides, I understood why.

Guannan is Director of Product Growth & Design at Ablefy, a platform that helps creators run and monetise their knowledge businesses. The company is ten years old, which means real customers, legacy systems, and operational constraints.

Yet, a 4-person team had built and monetised a new product in 30 days.

I immediately reached out and asked if she'd be willing to have a conversation with me. I'm so glad she said yes, because what she shared blew my mind.

The Extraordinary Results of an AI Experiment

To experiment with AI, Ablefy followed Guannan’s suggestion of creating an “AI Speedboat” team. The goal was to create a new product from scratch, and avoid potentially disrupting what was already working.

They decided to build a community platform for creators where their students or followers could connect, post, reply, and engage, as an add-on to the courses and events they were already hosting on Ablefy’s platform.

The AI Speedboat team was composed of only 4 people: two engineers, a designer at 50% capacity, and Guannan covering product and design.

Such a small team, yet such incredible results:

Five days into development, they were already using their own product internally for weekly planning. By day 30, they had a live product and their first real paying customer: a community of 200 members running their program on the platform.

Releases? Multiple times per week.

Productivity, measured in pull requests? Increased 5-6 times.

And customers felt it: “I feel like my feedback is always heard”. That’s the kind of feedback they started receiving.

Finally, when Ablefy ran an internal competition asking people to vote for their favourite feature, guess who won? The community product built by the AI team, of course.

So how did such a small team pull all of this off?

The New Way of Working

Before AI, Ablefy’s product development process looked exactly like what most of us are used to: Competitor research > customer interviews > story mapping > concept design in Figma > user testing > multiple rounds of refinement > scope definition. One to two months of work before a single engineer was involved. Add development time on top, and you'd be looking at three to six months to reach an MVP.

The Speedboat team threw that playbook out.

The team was small by design, and every decision had to reflect that.

1. The tech stack

The tech stack was chosen specifically to let the team move without bottlenecks. They used Cursor and Claude Code as their primary coding tools, with a serverless infrastructure and Vercel for deployment, meaning anyone on the team could deploy without waiting for a dedicated DevOps process.

The two engineers both operated as full-stack, handling frontend, backend, and QA themselves. One of them already had experience across all areas but the other had previously been a frontend engineer and became full-stack within three months of working in this setup.

2. The process

In the old world, product teams tried to fully define the problem before building: requirements first, implementation second. The Speedboat team largely abandoned that model.

Instead of sprints, the team works on a Kanban board with a backlog sorted by priority and reviewed every day. Engineers pick up the highest-priority ticket and move straight to the next one. They don’t wait for a detailed specification before starting. Guannan gives them a rough concept, explains the value they are trying to deliver, and they start working on it.

The spec emerges through the work instead of ahead of it.

And when the direction needs to change? That's fine too. As Guannan said, "AI made it possible to change your mind more often. We are more agile than ever." It sounds dangerous at first, but it’s not. Before, changing direction mid-build meant wasting expensive engineering time. Now the cost of being wrong is low enough that pivoting becomes just a part of how teams work.

3. The product / design merge

They basically moved from spec-first to build-first.

Instead of a PM writing requirements and a designer producing a solution, now the process starts with someone directly vibe coding a rough version of the feature.

They discover the edge cases by hitting them and understand the requirements by trying to build them. It's faster, but it also requires a different kind of person: someone who can hold the product thinking and the building at the same time.

4. The design / engineering merge

Designers spot things engineers miss: a button that's slightly the wrong size, an image in the wrong format, misaligned elements.

In the old world, a designer would write a ticket describing the problem, hand it to an engineer, and hope the explanation was clear enough. Now, they just go in and fix it themselves. It's faster, and it removes a whole layer of unnecessary back-and-forth.

5. The emergence of the product builder

"Once product managers and designers have access to the production codebase, it's really a life changer. It gives you all the context, it knows what your product is about, what has been implemented, what's possible.”

Guannan spoke of the Product Builder, a new role that holds product thinking, design, and frontend together. When building is the act of discovering what to build, you can't separate the person who thinks from the person who builds. They have to be the same person, or at least work so closely together that the distinction collapses.

At the time of our conversation, Guannan had just published the first official job opening for that role.

The New Bottlenecks

Guannan was very specific about what didn't work in this whole process. Some issues were resolved eventually, while others are still open problems. Here are the main challenges they encountered:

1. Stakeholder alignment didn’t get faster

Engineering speed increased 5-6 times. But everything that requires human interaction, like briefing the marketing team, aligning stakeholders, reporting to investors, getting beta testers on board, or demoing the product, still takes exactly as long as it always did.

AI can auto-generate a briefing from the codebase, summarising what changed and what the main features are. But the team discovered that sending an AI-generated communication to the marketing department wouldn’t cut it. They still had to sit with them, demo the product, and answer questions in person.

The reality: Engineering is no longer the bottleneck. The team can ship faster than the rest of the organisation can absorb. In Guannan’s view, the PM role still depends on human presence, trust, and conversation, and no amount of AI acceleration can change that.

2. People have a hard time accepting AI capabilities

Guannan’s experience is that people find it easier to accept that AI can take over boring, repetitive tasks than to accept it can do their core job better than they can. That resistance was present across several roles: engineers were skeptical of vibe coding's code quality, and designers felt their creativity couldn't be replaced.

But it’s the new reality: "It's just a truth you have to embrace. No one is really comfortable with it. But the truth doesn't change, no matter if you accept it or not."

The fix: Guannan’s approach was to find the people who were curious enough to try adopting AI, support them, protect them from being dragged back to the old way of working, and let the results speak for themselves. Eventually, people came around.

3. Engineers don’t like designers contributing to production code

The engineers' reaction was blunt: "It takes me longer to review their code than to just do it myself." That frustration was visible throughout the whole team.

The fix: The resolution, still ongoing, was to find one engineer willing to actually train the design team. They’re now running biweekly sessions to work through pull requests together, explain naming conventions, teach them how to run tests on staging - everything they need to contribute to the codebase without breaking things. Every second week, they push a few small changes together, and the PR quality is improving.

4. Specification management can’t be AI-generated

The team experimented with writing AI-generated specs and storing them in GitHub. But nobody wanted to read them because the writing style felt generic, the documents got outdated quickly as tickets evolved in Jira, and maintaining two sources of truth was too much overhead.

The fix: This one is still unsolved. Their current approach is to store specs directly in the codebase, so they stay tied to the code and inform release notes automatically. That experiment hadn't started yet when we spoke, so there were no results to share yet.

5. Design collaboration has changed in a world where the output is code

In the old world, two designers could share a Figma board and work together in real time. Now, when the work product is a branch on GitHub, the process looks more like an engineering workflow: one person deploys to a branch, the other has to check it out, and collaboration is less fluid.

The fix: There isn’t really a fix for this one. It’s a small thing in isolation, but it's an example of how adopting a new way of working creates friction in places you didn't expect.

6. Sharing prototypes with stakeholders got trickier

Previously, sharing a prototype meant sending a Figma link: instant, frictionless, no setup required. Now, when the prototype is code, you have to deploy it to staging first before anyone outside the team can see it.

The fix: Again, no solution here. It's a longer, more cumbersome process, and it creates a small but real bottleneck every time you need external feedback or sign-off.

Guannan’s Advice

Guannan's main advice to anyone starting this journey today was simple: just get started. Things look terrifying until you begin, but eventually become less so. She used GitHub as her own example: she didn’t want to touch it at first, but eventually figured it out and now uses it every day.

Secondly, she advised not to try to convince everyone to adopt AI. Instead, find the people who are genuinely curious, who want to challenge the status quo, and work with them. Bring the company along, make people feel they won't be left behind, but don't waste energy trying to drag people who aren't ready. The empowerment grows over time, and with it, your ability to make bigger changes.

Finally, one of the ideas that stood out the most to me was something Guannan said almost in passing: "The new era doesn't mean we are leaving people behind. It's about willingness, the willingness to step in. And if you do, the technology will empower you.”

We spend a lot of time talking about AI as something that replaces. This conversation was a reminder that it can also be something that expands: what people are capable of, how fast they grow, what a small team can build. The question isn't whether your people can keep up. It's whether you give them the environment to find out.

What I’m Taking Away

The results Guannan described are real and remarkable. But they were only possible because the Speedboat started fresh: a new product, a new tech stack, and no legacy to navigate. The harder, “how do you do this inside a system that already exists?” is what I’ve been exploring in other conversations in this series. That's where most companies actually live, and this story doesn't solve that yet.

What this story does solve, or at least reframe, is the vibe coding panic. There's a narrative in our industry right now that says AI coding leads to broken products, that speed without thinking is dangerous, that we're shipping our way into a mess. And maybe some teams are. But Guannan's team didn't skip the thinking. They still did the discovery work. They still validated with customers. They still cared about architecture and code quality, arguably more than before. I remember my own time as a PM, fighting for engineering time to focus on code quality and sustainable architecture, always losing to the next feature that needed to ship. AI gave teams both the speed and the permission to finally get that right.

The most useful frame I'm taking from this conversation is this: what we do stays the same. How we do it is completely different. The sequence of discovery > design > build > test still exists. It just runs in dramatically shorter cycles, more collaboratively, and closer to the customer than ever before. That's not a revolution in what product work is. It's a revolution in the speed at which good product work can happen.

Do you have an AI Adoption story to share and record?

Get in touch - send me an email at busra@busra.co or reach out on LinkedIn.