I’ve been running Productlab for two years, talking to senior product people every week across Leaders Circles, the community, and the conference circuit. And something I keep seeing doesn’t have a clean name yet. The people in the room are all called product managers. But they’re not doing the same job anymore. They don’t want the same things from their career. They don’t need the same skills. And the gap between them is growing.

Let me try to put a frame on it.

How we got here

Two years ago, the dominant question was “what is AI and should I care.” That wave produced credentials, explainers, bootcamps. Most of it was behind where the actual work was already happening.

Last year the question changed. Teams started shipping real AI features and hit the same production walls across every industry. How do you evaluate a system whose outputs are never identical twice? How do you design an agent that isn’t just an expensive autocomplete? How do you build something users trust enough to act on? The teams that moved fastest weren’t the ones with the best tools. They were small, cross-functional, and led by people with specific domain knowledge that the model couldn’t replicate on its own.

Now we’re in a third shift, and it’s the hardest one. The question is no longer technical. It’s organizational. When everyone can build, what is actually yours? When building speed is no longer the differentiator, what is?

That question is reshaping what product management actually means. And it’s producing three distinct profiles.

The three product managers

The first is what I’d call the Operator. They use AI to do the existing PM job faster and better. PRDs in twenty minutes. Research synthesis in two hours instead of two days. Meeting prep automated. Customer interviews summarized before the call ends. This is genuinely valuable. The work is real and the efficiency gains are measurable. But the playbook is visible to everyone, and so is the tool being used to run it. The efficiency is not a moat.

The second is the Product Builder. This person has shipped something real with AI. They know what evaluation systems are because they’ve needed them, not because they read about them. They’ve hit the production wall where a feature that works perfectly in a demo produces garbage in the wild. They’ve had to redesign a workflow from scratch because the architecture they chose was impossible to debug when it failed. They think about prompt engineering at the production level, not the conversational level. They’re T-shaped: enough technical fluency to make real architectural decisions, enough product craft to stay focused on the user problem. This is the direction individual product contribution is heading. It’s smaller than it looks. A lot of people believe they’re here when they’re still in the first group.

The third is the Specialist. This person has gone narrow and deep, combining AI capability with domain expertise that’s genuinely hard to replicate. A former teacher who writes her own evaluation code specifically because she knows what good pedagogy looks like and a generic model doesn’t. A product leader who spent years working with local government who knows that “this is a really big problem” is positive sentiment in civic technology, not a complaint, and that no off-the-shelf model will catch that distinction. Their competitive advantage isn’t the tools they’re using. It’s what they already know that the tools can’t. This is the rarest profile, and the gap between them and everyone else is widening, not closing.

How skills are actually changing

The skills that are losing value are, uncomfortably, some of the skills that got people promoted in the last decade. Writing detailed requirements that get handed to an engineering team. Being the translator between business and technology. Managing a backlog as the central organizing activity of the job. These aren’t gone. But they’re no longer the differentiator.

What’s becoming more important, not less: taste and judgment, because when anyone can build anything quickly, the decision about what’s worth building becomes the job. Domain expertise, because AI amplifies what you already know and can’t substitute for it. Commercial thinking, because the best product people now think about positioning, pricing, and go-to-market as product decisions, not someone else’s problem. And communication, which sounds obvious until you realize that as AI handles more of the execution layer, the human ability to facilitate alignment, challenge assumptions in a room, and build trust under pressure becomes the actual leverage.

The genuinely new skills are real but learnable: designing AI systems that degrade gracefully rather than confidently wrong, building evaluation infrastructure that isn’t just a spreadsheet of thumbs-up ratings, understanding how context windows fill and degrade so you design workflows that account for it. The most honest thing I’ve read about this is that you can’t predict how long it will take to get to good. Getting to good takes a lot of iteration. The knowledge lives in the failures already made, not in the frameworks describing them.

Why we designed three days

The conference structure is a direct response to these three profiles and the organizational layer that sits above all of them.

Day one is for the leaders trying to navigate from the top. The question is: given that the rules are changing faster than any planning cycle can accommodate, how do I make directional decisions without waiting for clarity that won’t come? We called the best person we know to lead that conversation: Ravi Mehta, who has spent the last two years building the most widely used framework for executive AI strategy and building AI-first teams. Not a lecture. A working session with people who have the same problem.

Day two is a full operating system for the Builders and Specialists. Six workshops, maximum twenty people each, at The Social Hub. Not lectures, practice. The new execution layer: agentic system design, building a personal Product AI OS, discovery and validation at AI speed. The judgment layer that hasn’t changed: stakeholder communication, strategy-to-execution, go-to-market thinking.

The people running the rooms: Zsuzsanna Tamas (Amazon Music) on agentic AI architecture. Tamer El-Hawari (Productbench) on building your Product AI OS. Birte Loecked on discovery and validation under pressure. Rich Mironov on ROI and managing business demands. Tim Herbig on connecting strategy to measurable execution. Rory Woodbridge on product marketing and go-to-market. Six practitioners, six rooms, maximum twenty people in each. One day to upgrade both sides of the equation.

Day three is the room where all three profiles are in conversation. Morning: companies and practitioners showing what the new terrain actually looks like when you’re operating inside it. Afternoon: the practitioners who went first, with the real stories. What the AI-native playbook doesn’t tell you. What it takes to build 0-to-1 agentic products inside a large organization. What happens when complexity is your moat and your end user isn’t your buyer. Then we close with something that isn’t a talk at all, a live robotic music performance exploring what happens when human intent meets algorithmic agency and neither is fully in control. It’s the honest description of where we all are right now.

Not three days of content. Three days designed for the three conversations that actually move people.

Which profile are you building toward?

Check Lineup

With love from Berlin,
Daniele

Then Rivety handed him full P&L ownership.

“I told the company hey I’ve never handled a P&L are you sure you want me,”

Bandan said at ProductLab Conference 2025 in Berlin. They wanted him anyway. Either he’d learn something new or he wouldn’t last long at the company. He survived 3 years—and discovered that product management had been missing half the equation.

At ProductLab, Bandan shared the hard-won lessons from managing profitability while everyone around him was still obsessing over growth metrics. This wasn’t theory. This was a product leader who learned to kill products, redesign pricing, and make layoff decisions—all while keeping the product organization healthy.

“Product management has just been too much about customer delight. Sustainable businesses are also about building a business at the end of the day.” — Bandan Singh

The Trap Most Product Managers Fall Into

Bandan’s career mirrors what’s happening across the industry right now.

At Gojek (Southeast Asia’s competitor to Uber and Grab), he was the “cool growth guy.” Small tweaks in the customer journey brought more users. The company was preparing for an IPO. Topline was everything—valuation was key.

Everything was about expansion, not efficiency.

At Booking.com, he learned experimentation at scale. How a small button change could move conversion numbers. But he never connected his work to the bottom line. He had no idea what his actual contribution was to Booking.com’s profitability.

“I would not know what led to true value for the company like what was my contribution in terms of the bottom line.”

Then came Rivety, a B2B mobility payments company in Berlin. Full P&L ownership meant looking at parts of the organization where he had no direct authority—but was responsible for outcomes anyway.

The learning curve was brutal. Pricing. Killing unprofitable products. Managing costs below revenue. Client-level profitability.

And yes, layoffs.

“The honest truth about a lot of hard decisions in companies—layoffs being one of them—they all come from a P&L decision.”

Action item: Stop measuring your impact solely by user metrics. Start asking: “What’s the actual revenue impact of what I’m building?”

Why Everything Changed (And Why It Matters for You)

Between 2018 and 2025, Bandan watched the entire product management playbook flip.

Money is no longer cheap. Companies that went public with “we’ll be profitable one day” promises are now scrambling to actually deliver profitability. Gojek, Grab, and dozens of others—they all said scale would solve everything.

It didn’t.

“Today if you look at Gojek and it’s true for a lot of companies that did IPOs recently now they’re all looking for profitability.”

The macroeconomics are tough. AI is accelerating this shift—it’s about value creation but also about cost-saving. Retention becomes more important because it brings you closer to profitability. Customer lifetime value matters more than vanity metrics.

Looking back, Bandan realized what he’d do differently at Gojek: track the cost of acquiring users.

“We don’t know at what cost we are acquiring users. I mean you have given me this team, you have given me these engineering resources and UX. I work with them and I deliver it and I get some monthly active users. But I would rather say that can we look at the cost of acquiring those users so that at least at a user level I know the unit economics.”

The shift for product managers: If you want to be successful—especially in senior product roles—you need to focus on business viability as much as customer delight. Maybe even overindex on business viability for a while.

Action item: Calculate your user acquisition cost. If you’re in a product-led company and it’s “spread across the full product base,” work with your finance counterpart to estimate it.

The Framework: 4 Levels of Looking at Profitability

Bandan broke down the P&L into a simple framework that any product manager can use—even if you don’t have full P&L access.

He showed a mock-up of what he was responsible for at Rivety. The key insight: different profitability metrics serve different purposes.

1. Revenue ÷ Time (Throughput)

This ignores the cost of rails entirely. It’s pure throughput.

Most product managers stop here. They celebrate when revenue goes up. But this metric is incomplete—it doesn’t tell you if you’re actually creating value for the business.

2. Operating Profit ÷ Time

This gets blurred by corporate growth bets and cost allocations.

It’s useful for CFOs, less useful for product teams making day-to-day decisions about what to build.

3. Net Profit ÷ Time

Distorted by financing and tax considerations.

Again, not the right metric for product decisions.

4. Gross Profit ÷ Time (The One That Matters)

“The true speed at which the product engine creates value.”

This is where product managers should focus. Gross profit strips away the noise and shows you: is this feature, product, or initiative actually creating value for the business?

Bandan’s rule: Take revenue, subtract direct costs (COGS), and you get gross profit. That’s your North Star.

“At a given point in time it’s important to know what is more important for the organization—is it gross margin or is it net? Depending on what the company is striving for, that is the more important metric.”

Action item: Find your product’s gross profit metric. Work with finance to understand your direct costs. Start tracking gross profit ÷ time as your primary business health metric.

The Numbers That Actually Matter

When asked about how to start thinking about profitability, Bandan shared two calculations that changed how he prioritized work.

Profit Velocity: Gross profit per week or per sprint.

This tells you how fast your product is generating value. It’s not about the absolute number—it’s about the trend. Is profit velocity increasing or decreasing with each release?

Payback Period: Build cost ÷ profit velocity.

Let’s say you spend €100,000 over 3 months building a feature. Your product generates €50,000 in gross profit per month. Your payback period is 4 months.

“This is a conversation starter on no two features are the same. Even though something might have low effort high impact after they launched, some features might take more time to pay back and some others will take less time.”

The insight: not all “low effort, high impact” features are equal. Some have fast payback periods, others don’t. This changes how you prioritize.

Action item: Calculate the payback period for your last 3 major features. Share this analysis with your leadership. Start using it in roadmap discussions.

The Honest Truth About Getting P&L Access

Bandan was brutally honest: getting profitability data in your company is hard. You’re not alone if you’re struggling with this.

But here’s what he recommended for senior product managers and product leaders:

During discovery: Ask not just “Is this valuable for users?” but also “Is this profitable for the business?”

In prioritization: Rank initiatives by profit potential per sprint or per week—not just by user impact.

Set the culture: Ask your leaders, your peers, for a view into profitability. Read company statements and reports if your company is public.

Bandan used to read Booking.com’s income statements even though nobody asked him to.

“I used to read Booking.com’s income statements to see how much it cost to build this accommodations business. I also started looking at how much of direct costs are going in, how much of what is driving Booking.com’s profitability, what is not. These are all amazing things that help me today.”

At the time, nobody cared that he was doing this. He wasn’t responsible for it. But today, that self-education became his competitive advantage.

In leadership conversations: Always connect your roadmap back to P&L levers. Show how your backlog choices affect costs and revenues.

When Bandan encounters shared costs (like infrastructure spread across multiple products), he partners with finance and accounting to get answers.

“You need good partners in the organization. For me it was not my product leader, they were my finance and accounting counterparts that would help me out with my questions.”

One surprising thing: in his direct costs, he had to account for other product teams’ contributions. His product was part of a value chain. To deliver revenue, the full chain mattered—not just his piece. So 10% of another product group’s cost became part of his direct costs.

Action item: Schedule time with your finance counterpart this week. Ask: “How is my product viewed in the full product portfolio?” Request a view into your product’s profitability, even if it’s just directional.

What This Means for Your Career

Profitability isn’t a dirty word. It’s resilience.

When downturns happen—COVID, AI disruption, whatever’s next—profitable companies survive. They don’t have to cut half the team when VC funding dries up or interest rates rise.

“Profitability ensures resilience. When there’s a downturn, when things are bad, you’re able to fight a lot of these downturns as a company.”

Product managers used to be able to ignore all of this. Growth solved everything—or seemed to. But the playbook requires a new chapter now.

Business viability and customer delight have to go hand in hand. And Bandan suggests overindexing on business viability for a while—especially if you’re moving into senior product roles where you’re closer to stakeholders making P&L decisions.

The message isn’t to abandon customer delight. It’s to add the other half of the equation that’s been missing.

“Creating sustainable businesses is not always about customer delight. It’s also about building a business at the end of the day.”

Start with one thing: know your unit economics. Work backward from there.

The product managers who thrive in the next decade won’t just be the ones who can optimize conversion and drive MAUs. They’ll be the ones who can build products that are profitable, resilient, and sustainable.

Connect with Bandan Singh:

• Substack:

• LinkedIn: Bandan Singh

Sustainable Growth By Bandan

1.75MB ∙ PDF file

Download

Download

At ProductLab Conference 2025 in Berlin, Vivek shared 12 years of hard-won lessons from building outcome-driven teams at three major retailers. This wasn’t theory from a consultant. This was tactical gold from someone who’s been in the trenches, building teams that ship.

“Building these teams is hard,” Vivek told the 250+ product managers in the room. “But keeping them? That’s harder.”

Here’s what actually works.

The Three Pillars: Why Your Teams Need to Care About More Than Just Shipping Features

Most product leaders say they want empowered teams. They want people who care about customers and outcomes, not just shipping features.

But here’s the reality: saying you want it and actually building it are completely different things.

Vivek distilled 12 years of experience into one framework that cuts through all the noise. He calls it the three pillars of care:

→ Care for your customers — not just features, but the people using them
→ Care for the problem space — not the fancy new tool or API, but the actual problem you’re solving
→ Care for product economics — how your work affects revenue, retention, and costs

“If you don’t get anything from today,” Vivek said, “this slide is enough.”

The framework is simple. The execution? That’s where most teams fail.

Here’s how to actually build teams that demonstrate this level of care.

Everyone Should Be Selling (Yes, Even Your Engineers)

Here’s a story that Vivek keeps going back to, even years later.

During his first month at On, an engineer did something remarkable. Without anyone asking, this engineer set up a lab at home. He bought every On shoe model he could get his hands on using company vouchers. Then he started measuring them—literally taking measurements and creating spreadsheets comparing products.

Why? The engineer noticed something. On was labeling certain shoes as “wide fit,” but when he measured them, the data didn’t match up. So he posted his findings in Slack with detailed analysis and datasets.

“Who is this person?” Vivek wondered. “Is he part of the physical product development team?”

No. He was a web infrastructure engineer. Someone who could have easily said, “Not my job.”

But here’s what made it powerful: this engineer cared enough about what customers were buying to flag a problem that the physical product team had missed. When the company was small enough to move fast, they took his feedback, went back to the factory, and fixed the wide-fit issue.

Vivek has used this screenshot (with the engineer’s face hidden) in every talk he’s given since. It’s the perfect example of someone who gives a damn.

Action item: Rotate your team members through sales for a day. Not to make them better at selling—but to see the customer’s eyes light up when they actually get value from your product. It changes everything.

The Radical Ownership Toolkit: How to Build DRIs That Actually Own Outcomes

Everyone talks about ownership. CEOs say, “I want my teams to own everything.”

But what does that actually mean? And more importantly, how do you build it?

Vivek introduced a concept from Apple’s playbook: the DRI (Directly Responsible Individual). Ken Kocienda, the designer who built the Apple keyboard, embodied this perfectly. He was the IC (individual contributor) who scheduled meetings with the VP of legal to go over details himself. No middleman. Just pure ownership.

But here’s where most companies fail: they talk about ownership while operating in one of three modes:

1. Consensus-driven: Everyone needs to say yes before anything moves

2. Confrontational: Lock people in a room, let them argue, hope they come out aligned

3. Hierarchical: Can’t decide? Push it to the boss

“None of these is better than the other,” Vivek clarified. “Just know where you are. Know your operating environment.”

Once you know where you are, you can build real ownership using guardrails instead of rules.

The Guardrail Framework:

→ Constraints of time: Give people a deadline. Theory of constraints always works.
→ Constraints of budget: Here’s your budget. Play within it.
→ Constraints of scope: Here’s your playground. Build whatever you want within these boundaries.
→ Philosophy and principles: Document your design principles so teams aren’t fighting about whether a button should be red or blue.
→ Sacrificial vs. non-sacrificial beliefs: What can teams sacrifice? What’s sacred?

“We care about customers—that’s a sacrificial belief,” Vivek explained. “You can negotiate on execution, but the core principle is non-negotiable.”

Action item: Write down your team’s 3 non-sacrificial beliefs this week. What’s sacred? What absolutely cannot be compromised? Share it with your entire organization.

What Doesn’t Work: The Firefighting Trap That Kills Ownership

Here’s where Vivek got brutally honest about what keeps teams from staying outcome-driven.

Years ago, a manager told him: “Vivek, you’re too quick at firefighting. Let the spark and the fire be there for some time. Let it burn. We’re all adults. You don’t have to just jump in and throw water at it.”

Vivek’s instinct was to fix every problem immediately. No fires on his watch.

But his manager was right. By solving every conflict, every decision, every debate, he was preventing his team from developing the muscles they needed to own outcomes.

“Avoid the tendency as leaders to resolve conflicts—even decision conflicts about your product,” Vivek advised. “Let it not be resolved quite quickly, especially not through you. Just let it simmer. Let people debate, fight a bit, demonstrate the care, prove you wrong or right.”

One team Vivek worked with created a rotating “conflict resolver” role. It was like a hat that moved around the team. If you weren’t the conflict resolver that week, you could fight as hard as you wanted in discussions without worrying about facilitating.

The result? People actually started caring about decisions because they had to own them.

Action item: For the next 2 weeks, resist the urge to step in and resolve team debates. Let your teams argue (productively) and come to their own conclusions. Watch what happens.

The Question That Reveals Everything About Your Organization

Near the end of the talk, someone asked Vivek the question every product leader struggles with: How do you create an appetite for ownership in a team that’s gotten comfortable?

“It’s a good question,” Vivek said. “And I want to approach the answer by saying how I operate—and you would operate completely different, and that’s okay.”

Then he broke down two approaches:

Approach 1: The Incremental Shift

If a team has been comfortable for years, any idea about radical ownership is like a virus to that system. They’ll fight it.

So you find a medium-to-low-risk feature or capability—not a quick win, but something that gives people feedback on what ownership actually looks like. You celebrate it. You talk about it. You show people, “This is what ownership looks like.”

Approach 2: The Band-Aid Rip

Some leaders just say: “From tomorrow, you’re all going to be owning certain things. It’s absolutely okay if you don’t know that yet, but this is how we operate. We’re giving ourselves 4 months to settle in. From now on, everything we build has a single owner. No decisions by committee. If you want advisory, get advisors and move.”

“Both work,” Vivek concluded. “It depends on where you are and how much influence power you have within the organization.”

Keeping Teams: Why Sales Rotations Matter More Than You Think

Building outcome-driven teams is one thing. Keeping them as you scale? That’s where most companies fail.

Vivek’s advice: Sell, sell, sell.

Have periodic rotations where your teams spend time in sales. Let them experience what it’s like to convince a hard customer. Let them see the customer’s jaw drop when they realize your product solves their problem.

“One of my managers told me to just spend a day with sales,” Vivek recalled. “The excitement when you’re meeting a customer, when you convince them—it’s a whole different game when they actually get onboarded and start using your product.”

And here’s the controversial part: don’t fix all problems. Let some fires burn. Let adults figure it out.

Final action item: This quarter, have every product manager, designer, and engineer on your team spend 1 day shadowing sales or customer success. Not observing—actively participating. Watch how it transforms their perspective on what you’re building.

The Bottom Line

Building outcome-driven teams isn’t about copying Google’s playbook or reading another framework doc. It’s about building teams that demonstrate care—for customers, for the problem space, and for product economics.

It’s about giving people guardrails, not rules. It’s about letting fires burn so people learn to own their decisions. It’s about rotating engineers through sales so they understand what they’re actually building for.

As Vivek put it in his closing: “In the world of agentic systems and AI products, what will not change is building teams that can move fast and build towards outcomes.”

The tools change. The fundamentals don’t.

Connect with Vivek

Vivek Juneja has led product and engineering teams at Zalando, On, and GS, building outcome-driven organizations from the ground up. He’s also passionate about education and teaching, creating content to help product leaders build better teams.

→ LinkedIn: Vivek Juneja
→ Substack:

Outcome Driven Teams Vivek Juneja

3.82MB ∙ PDF file

Download

Download

The Bet? Build a year-round community of local events across 18 European cities. Running clubs. Dinner with strangers. After-work drinks. In just one coordinated evening across Europe, they got 1,200 people to show up.

At ProductLab Conference 2025 in Berlin, Simone shared the brutal truth about building community products—the missteps, the data, and the principles that turned WeRoad Events from “a bit of a shit show” into a referral-generating growth engine.

“Speed of execution is much more important than perfection. We made a lot of errors on the way. It doesn’t really matter as long as you correct them super fast.”
— Simone Basso, CTPO at WeRoad

Understanding the Flywheel

WeRoad isn’t just a travel company where you book and go. It’s built on a community flywheel that most PMs miss.

Here’s how it works: Travelers join through social channels, do a weekend group trip with 15 strangers aged 25-49, then some become coordinators (paid guides who travel for free). These coordinators organize more events and trips, attracting more travelers.

In the center? A community of people passionate about solo travel and real-life connections.

The insight: 60% of people who book a trip join the Facebook group (Solo Travelers United) just before or after booking. They’re not just buying a trip—they’re buying into a community.

“Fundamentally, it is an evolution of dating apps. Tinder and the likes are all going down, but people do want in real life connections. Doing it in a group setting is much easier than in a dating setting.”
— Simone Basso

5 Principles for Building Community Products That Actually Scale

Simone distilled WeRoad’s journey into 5 hard-won principles. This isn’t theory—it’s what actually worked when they had to fix their “shit show.”

1. Ship Fast, Fix Faster—Perfection Is the Enemy

WeRoad launched their events app in 6 weeks. No monetization. No payment system. Just search, details, map, and RSVP.

They cut scope aggressively. Reused the design system from WeRoad. Focused only on what users absolutely needed to find and attend an event.

The result? They launched on time—but engagement dropped after the initial spike. Daily active users weren’t growing. Monthly active users weren’t growing.

“We made a lot of errors on the way. It does not really matter as long as you correct them super fast. It will be much worse to try and get everything perfect—the supply perfect, the message perfect. We would still be building.”
— Simone Basso

Action item: If you’re building a community product, launch your MVP in under 8 weeks. One core feature that works is better than three half-built features.

2. Clear Messaging Beats Clever Complexity

Their original landing page was a mess. QR codes on desktop. Unclear value prop. Too many event types across 30 cities in 5 countries.

Compare that to a competitor (Timeleft): “Stranger dinner Wednesday. Boom. Done.”

WeRoad’s fix? They narrowed to 3 event types: Running clubs, Dinners with new friends, We Work After Work. Same message across all 18 cities. One coordinated night across Europe.

The clarity unlocked growth. Last coordinated event: 1,200 attendees in one night.

Action item: If your product needs more than 10 words to explain, you’re confusing users. Cut your event types, your messaging, your supply—until a stranger gets it in 5 seconds.

3. Community Products Need Identity, Not Just Supply

WeRoad initially tried to be everything: bottom-up events, top-down organized dinners, 30 different cities, diverse event types from London to Bari.

It became “a completely unscalable problem.”

The mistake: treating WeRoad Events like WeRoad. But events aren’t trips—they’re a different market, different people, different identity.

“Having a clear identity and a clear supply is absolutely necessary to make it work and to grow our community. You cannot just pretend you’re good at WeRoad Events—it’s a completely different thing.”
— Simone Basso

Action item: Define your community’s identity in one sentence. If you can’t, your users definitely can’t.

4. Build for Repeat, Not Just Acquisition

The real metric that matters? Cohort retention by month.

21% of people who attend an event come back the next month. 8% come back two months later. About 20% become regular community members.

More revealing: 6-7% of event attendees had already done a WeRoad trip. 2% convert to become WeRoad customers after attending events.

The network effect is working. Events drive trips. Trips drive more events. Community drives both.

But here’s the gap: WeRoad doesn’t yet nudge people enough. Someone does a trip, makes friends—then those friends do a running club in Berlin next week. WeRoad should connect those dots.

Action item: Map your retention by cohort month-over-month. If 20%+ aren’t coming back, you don’t have community—you have transactions.

5. Own the Full Community Lifecycle

WeRoad replaced Meetup with their own platform. Next target? The Facebook group.

Why? They can’t control who people talk to, what they ask, or who responds. The pre-trip research phase—where fear and uncertainty kill conversions—happens entirely outside WeRoad’s control.

One clever solution they built: post-booking, travelers can share which flights they’ve booked. Other group members see it and coordinate to fly together. Small feature, massive reduction in “fear of traveling alone.”

“Getting ownership of the full cycle of the digital community is as important as making sure they have a great community experience. We’re never going to replace WhatsApp or Instagram for how people talk—but the upper funnel of community is crucial for growth.”
— Simone Basso

Action item: Audit where your community lives. If critical conversations happen off-platform, you’re blind to what drives or blocks conversions.

The Numbers That Matter

When asked about growth mechanics, Simone shared specific data:

900 referral friends in 4-5 months—almost €1 million in referred revenue.

The incentive structure: 5% discount immediately to the referred friend, 5% discount on your next trip (up to 50% off after 10 referrals).

But here’s the opportunity cost: they only talk about referrals to existing WeRoaders. They don’t nudge new customers pre-trip or post-trip enough.

“We don’t do enough nudging of new customers who could have other friends and bring them into the community even before they go on a trip.”
— Simone Basso

The user activity spike after refocusing the platform? It “fundamentally picked up”—exact numbers still climbing weeks after the messaging fix.

What WeRoad Got Wrong

Simone was brutally honest about their mistakes:

Mistake 1: They tried to stop paying coordinators to organize events, thinking community loyalty would sustain it. Coordinators refused. Supply collapsed.

Mistake 2: They spent weeks debating monetization—membership model vs. pay-per-use—before shipping the MVP. Premature strategy discussion that delayed value.

Mistake 3: They lost sight of the community during the platform migration. Changing the supply model and the platform simultaneously confused everyone.

“We had to rush to organize all these different types of events in 5 countries, 30 cities. From London to Berlin to Milan to Bari—very complicated. It became completely unscalable. We fundamentally screwed up.”
— Simone Basso

The fix came fast: focus on 3 event types, 18 cities, consistent messaging, and rebuilt relationships with coordinators.

The Conviction: Community Is the Moat

Simone’s bet is simple: community compounds.

Travelers who attend events repeat more. They book more trips. They stay engaged year-round instead of 1-2 weekends annually.

The next phase? Replace Facebook groups with their own platform. Control the pre-trip conversations where fear and uncertainty live.

Long-term vision: WeRoad becomes the platform where solo travelers discover trips, meet locals, attend events, and build friendships—all in one ecosystem.

“Running clubs are the new dating. People want in-real-life connections in group settings—it’s much easier than one-on-one dating.”
— Simone Basso

The timeline: by end of 2025, own the full digital community experience.

Your Move

Building community products isn’t magic. It’s discipline.

Simone and the WeRoad team proved that with the right framework—ship fast, clarify your identity, design for repeat, own the lifecycle—you can turn one-time travelers into year-round community members.

Start with one thing tomorrow: Cut your event types to 3 or fewer. Make them crystal clear. Then add coordinated launch days across all your locations.

The community product that wins isn’t the one with the most features. It’s the one people understand in 5 seconds and come back to every month.

Connect with Simone:

• LinkedIn: Simone Basso

• Medium: Simone Basso

• X: @simone_basso

The Community Bet Turning Travelers Into A Year Round Movement

5.15MB ∙ PDF file

Download

Download

“Am I the only one who’s been asked to do AI without a clear product strategy?”

Nearly 70% of hands went up.

As Chief Product Officer at Spryker (a B2B digital commerce platform serving large enterprises) and coach to 100+ product managers, Elena has spent years watching companies struggle with the same problem: everyone’s being told to “do something with AI,” but nobody knows what that something should be.

The result? Teams running around like headless chickens, shipping AI features that get 20% adoption rates, and wondering why their revolutionary technology feels more like expensive window dressing.

Elena’s talk wasn’t about prompts, tokens, or the latest model releases. It was about the strategic frameworks that determine whether your AI product becomes essential or gets killed in the next budget review.

The Real Problem: We’re Not Just Lacking Strategy—We’re Asking the Wrong Questions

Here’s what Elena has observed across dozens of companies: product teams are so focused on “Should we do AI?” that they never ask the question that actually matters.

The wrong question: “Should we add AI to our product?”

The right question: “What game are we playing, and what context demands our next move?”

Elena shared four brutal truths that most product leaders don’t want to admit. These aren’t theories—they’re patterns she’s seen repeatedly in established companies trying to evolve in the AI era.

BRUTAL TRUTH #1: Hype ≠ Strategy

The symptom: Your leadership team comes back from a conference buzzing about AI. Within a week, you’ve got a mandate to “AI-ify” everything. No clear outcomes. No defined value. Just AI for AI’s sake.

The reality: AI adoption hinges on clear strategic intent, not just excitement.

Elena breaks down what real strategic clarity looks like:

→ Point A: Where are you now? (Current state with hard numbers) → Point B: Where are you going? (Target state with measurable outcomes)
→ 3-5 bold bets: Specific hypotheses with customer proof

“You need to still have a clear strategy about what kind of change you are trying to create and why,” Elena emphasized. “You need to understand what kind of value you’re trying to create and make sure your customers want that value before you start thinking about AI features.”

Most companies skip Point A entirely. They can’t articulate their current baseline, which means they have no way to measure if AI actually improved anything.

Action item: Before your next AI roadmap discussion, force your team to complete this sentence: “We will know our AI investment succeeded when [specific metric] moves from [current number] to [target number] because our customers can now [specific outcome].”

BRUTAL TRUTH #2: AI Labels ≠ Value

The symptom: You slap “AI-powered” on existing features and wonder why adoption doesn’t change.

The reality: Simply adding “AI” to existing capabilities won’t inherently create value without a defined purpose.

Elena introduced a framework that cuts through the noise: The Four Innovation Levers.

Every successful product innovation moves the needle on at least one of these:

1. Make it Cheaper (Cost ↓ / Margin ↑)

→ Lower costs for customers or reduce your cost to serve
→ Example: AI-powered translation replacing human translators—still involves people for quality checks, but costs drop 60%

2. Make it Faster (Cycle Time ↓ / SLA ↑)

→ Compress time-to-outcome for customers
→ Example: Website builder that uses AI for layouts only wins if it actually gets customers to launch faster—not just make prettier pages

3. Make it Easier (Friction ↓ / Conversion ↑)

→ Remove steps, simplify workflows, reduce cognitive load
→ Example: Auto-filling forms based on previous context instead of making users type again

4. Make it Smarter (Relevance ↑ / AOV ↑)

→ Personalize experiences, anticipate needs, deliver context
→ Example: Recommendations that actually increase average order value, not just look clever

Elena ran a live poll asking which levers attendees were targeting with their AI features. The responses were scattered—compliance, adoption, data quality, strategy.

That’s the problem. When you don’t know which lever you’re pulling, you can’t measure if it’s working.

“When you implement an AI feature, you’re not just throwing an AI label on top of the feature,” Elena explained. “The value itself needs to be absolutely clear to the customer. You’re actually trying to move the needle on one of those four levers.”

Action item: Audit every AI feature on your roadmap. Force each one to declare which lever it’s pulling and what the measurable outcome is. If a feature can’t clearly articulate its lever, kill it or redesign it.

BRUTAL TRUTH #3: Innovation ≠ Always the Right Answer

The symptom: Everyone wants to “innovate” with AI, build the revolutionary product, change the game. Meanwhile, your core business is bleeding customers because basic workflows are slow.

The reality: Understanding if your goal is evolution (efficiency) or revolution (reinvention) is critical. “We need to innovate” isn’t a strategy.

This is where Elena’s framework gets surgical. She introduced a critical distinction most teams never make:

What Game Are You Playing With AI?

EVOLUTION: Optimize the Current Game

• Outcome focus: Cheaper, Faster, Easier

• Who: Existing customers, current segments

• Proof to seek: Repeatable efficiency lift, quality holds

• Good when: Low readiness, short runway, high compliance risk

• Risks: Incrementalism, competitors leapfrog you

REVOLUTION: Change the Game

• Outcome focus: New mechanism, “smarter” behavior

• Who: Early adopters, new segments

• Proof to seek: 10x task completion, new usage loops

• Good when: High readiness, long runway, exec sponsor appetite

• Risks: Adoption risk, longer time-to-value, higher costs

“Most of the time companies are lacking a successful strategy for how to actually make bets,” Elena said. “With AI, you need to start making even bolder bets, but at the same time you need to have a strategy behind it.”

Elena emphasized that established businesses—companies that have been around for decades or centuries—are in a fundamentally different position than AI-native startups. They have existing products, existing customers, and existing revenue streams.

“We’re not talking about the new startup that is starting from scratch. They have existing products with existing customers and that’s where the majority of their money is coming from. So you have to continue to optimize it.”

But here’s where it gets interesting. You can’t just pick one game and ignore the other.

BRUTAL TRUTH #4: Focused Bets > Spray-and-Pray

The symptom: Your team is running 15 AI experiments with no clear success criteria, no kill dates, and no portfolio strategy.

The reality: Random experimentation without clarity, alignment, and a disciplined portfolio leads to poor outcomes and resource drain.

Elena introduced a betting framework adapted from portfolio management theory: The 70-20-10 Model.

But here’s the twist—you can’t apply the same percentages to every company.

Place Your AI Bets Based on Your Context:

CORE (Optimize Existing): → Double down on high-performing products
→ Systemize marketing campaigns
→ Automate repetitive tasks
→ Invest in customer retention

ADJACENT (Expand Category): → Find adjacent customer needs
→ Pilot new versions of your offer
→ Enter nearby markets
→ Form strategic partnerships

TRANSFORMATIVE (Bold Moves): → Ask “If we were to completely change how XYZ is done, what would we do?”
→ Ask “What would make us obsolete?”
→ Set long horizons (don’t expect immediate adoption)

But the allocation changes based on your context:

Venture-Backed (Chasing a round)? → Bias Revolution for narrative and optionality while managing runway
→ 20/30/50 (Core/Adjacent/Transform)

Public Company (Margin pressure)? → Bias Evolution—operational efficiency is oxygen for stock performance
→ 80/15/5 (Core/Adjacent/Transform)

Profitable & Private (Sustainable growth)? → Run a barbell strategy—protect core, fund bold bets
→ 60/20/20 (Core/Adjacent/Transform)

“The thing is that you cannot apply this model to any company,” Elena warned. “It depends. Context decides.”

When asked about the biggest challenges teams face with AI strategy, the ProductLab audience responses were telling: compliance, adoption, data quality, capacity, resources, strategy itself.

Elena’s point:

“There’s no consistent answer that people have. Pretty much across the board, people talk about that yes, everybody has a mandate to go and do AI, but at the same time there’s like hundreds of reasons why—on the surface it seems like other companies are really successful, but most of the time they are not. They’re also struggling to understand what they actually do.”

The critical rule: Every bet must have: → Success KPI
→ Guardrail KPI
→ Kill/Scale date
→ Quarterly rebalancing

“Don’t ask ‘Should we do AI?’ Ask: What’s the right balance for our context—now? Then start making your decision.”

From Theory to Action: What to Do Monday Morning

Elena closed with a challenge to the audience: change the conversation entirely.

Stop asking:

• Should we do AI?

• Are our customers ready for AI?

• What AI features should we build?

Start asking:

1. What is the right context for my company? (Venture-backed? Public? Private?)

2. What game are we playing? (Evolution or Revolution?)

3. Which value lever are we pulling? (Cheaper? Faster? Easier? Smarter?)

4. What’s our betting portfolio? (70-20-10? Something else?)

“Go with that to your leadership team, which will make you more strategic than anybody else,” Elena said. “And I can guarantee you that if you do that, you’re going to be definitely seen as more strategic, but also you’re going to be speaking the language that business understands more than just if you were talking about a specific product feature.”

The E-Commerce Reality Check

During Q&A, Elena was asked about the biggest AI use case in e-commerce given her Spryker background.

Her answer was refreshingly honest: “To be honest, I don’t know what’s going to be the next thing because the world is changing quite a lot.”

She explained that large B2B manufacturers (like Siemens Healthcare, which makes medical devices) aren’t easily adopting AI tools due to compliance concerns. But smaller e-commerce companies face a different threat: discovery moving entirely to LLMs.

“It’s easy to go to ChatGPT and say, ‘I have these pants, I have these shoes, find me a t-shirt or a top that is going to go with this.’ I don’t need to go and search even on Amazon for that because maybe that product is not there.”

The takeaway? The channel itself might change, but the strategic frameworks remain constant. You still need to know:

• Who your customer is

• What value you’re creating for them

• Whether they’re willing to pay for that solution

• Whether you can execute it

“You should not be thinking from the types of product. You need to be thinking about who your customer is. What kind of value do you want to give them? Actually test for their willingness to pay for that solution and then are you actually able to execute for it.”

Your Move

Elena’s frameworks aren’t theoretical constructs—they’re battle-tested approaches from someone who’s been in the trenches building products for established enterprises that can’t afford to chase every shiny AI object.

The difference between companies that succeed with AI and those that burn cash on unused features comes down to one thing: strategic clarity.

You can have the best models, the smartest engineers, and the biggest budget. But if you don’t know what game you’re playing, which lever you’re pulling, and what context you’re operating in, you’re just another team running around with your hair on fire wondering why “AI” isn’t working.

Start with one thing this week: Get brutal clarity on whether you’re playing evolution or revolution. That single decision will cascade into better bets, clearer priorities, and AI products people actually want to use.

The brutal truth? Most companies won’t do this work. They’ll keep spray-and-praying, keep slapping “AI” labels on features, and keep wondering why adoption stays stuck at 20%.

Don’t be most companies.

This article is based on Elena Leonova’s talk “The Brutal Truth About AI Product Success” delivered at ProductLab Conference 2025 in Berlin. The conference brings together 250+ senior product managers and leaders to tackle the hardest challenges in product management.

Connect with Elena Leonova: LinkedIn - Instagram

The Brutal Truth About Ai Product Success Elena Leonova

2.33MB ∙ PDF file

Download

Download

That’s the wrong question.

AI is getting cheaper, better, and faster every single day. Inference costs have dropped 95% in 18 months. Open-source models like Qwen and DeepSeek rival proprietary ones. The question isn’t whether AI matters—it’s what you’re going to do about it.

Hayder, Head of Product at Aleph Alpha (a B2B enterprise GenAI company that raised $500M in 2023), spent years building AI products for industrial-scale customers. His talk cut through the hype with a brutally simple framework: two questions that determine whether your business model survives the agentic era.

This isn’t theory. It’s what’s already happening.

The Gen AI Paradox (And Why 80-95% of AI Projects Fail)

Here’s the uncomfortable truth: between 80% and 95% of companies report no measurable impact from their GenAI initiatives.

Why? The Gen AI Paradox.

Companies face two bad options:

Horizontal use cases (ChatGPT, Copilot, Gemini): Scale broadly but generate shallow, unmeasurable value. Nobody can actually quantify how much value Gemini added to their organization.

Vertical use cases: High value, function-specific, industry-specific—but they’re stuck in pilot hell. Getting them to production is brutally hard.

Agentic AI might be the way out.

But first, you need to understand what agents actually are.

What AI Agents Actually Are (And What They’re Not)

Agents are NOT: → A set of prompts → Tool calling or MCP protocols → Just reasoning models → Programmatic loops → Simple process automation

An AI agent is a system that uses reasoning and planning to solve complex, multi-step problems by using tools and memory to act and interact with its environment.

The foundation? An augmented LLM with three critical capabilities:

1. Retrieval — Access to information

2. Tool calling — Ability to use external systems

3. Memory — Retention across interactions

Think of it as upgrading from a calculator to a research assistant who remembers your last conversation, can Google things for you, and makes decisions about what to do next.

Now here’s where it gets interesting for business models.

The Agentic 4 Moves Matrix: Your Strategic Map

Hayder’s framework is deceptively simple. Just two questions:

1. WHAT kind of work are you doing? → Optimize (improve existing processes) → Innovate (create new capabilities)

2. WHERE are you doing this work? → Internally (inside your company) → Externally (customer-facing, market-facing)

Plot them on a 2x2 matrix, and you get four strategic moves.

Move 1: Optimize Internally — From AI Pilot to P&L Impact

The trap: 90% of GenAI pilots never reach production.

Why they fail: The six predictable traps:

→ 10%-not-10X Trap: Marginal improvements don’t justify the complexity
→ Unit Economics Trap: Token costs kill profitability at scale
→ Prototype-to-Production Trap: What works in a demo breaks with real users
→ Solution-without-a-Problem Trap: Building AI for AI’s sake
→ Users-don’t-accept-mediocrity Trap: 85% accuracy isn’t good enough when humans expect 99%
→ Maintenance-and-ongoing-cost Trap: Nobody budgeted for the care and feeding

The fix: Don’t optimize for today’s costs. Optimize for where costs will be in 12-18 months. Inference costs are dropping 50%+ annually. Build your business model assuming AI will be nearly free.

Hayder’s team at Aleph Alpha already uses open-source models for specific tasks where cost is essentially zero. They’re betting on a world where smart AI costs nothing—and building accordingly.

Move 2: Innovate Internally — Out-Strategize the Competition

This is where things get sneaky.

Case study: Anthropic’s multi-agent research system fully automates market research, competitor analysis, investment trends, technology trends, and report generation.

What used to take a team of analysts 2 weeks now runs overnight. Continuously.

The opportunity: Most companies think of AI as customer-facing. The biggest gains right now are internal—using agents to do work that never had software solutions before.

Examples: → Competitive intelligence that updates daily → Automated compliance monitoring across regulations → Supply chain optimization that responds to real-time disruptions

The companies winning here are those that treat agents as autonomous team members, not just fancy autocomplete.

Move 3: Optimize Externally — Separating Signal from Noise in Sales and Marketing

The market is shifting from human-first to AI-first customer experience.

AI agents are starting to handle end-to-end customer journeys:
→ Voice and chat interactions
→ Human-like, personalized experiences
→ Proactive service (reaching out before problems escalate)

The business model shift: If an agent can handle 95% of customer interactions, what happens to your per-seat SaaS pricing?

Companies that priced on seats, users, or usage are scrambling. The winners are shifting to outcome-based pricing—but that only works if you can attribute outcomes to actions. If you can’t measure the value your product creates, you can’t price for outcomes.

Hayder’s warning: Start experimenting with outcome-based pricing now, even if it’s messy. The companies that figure this out first will have a massive advantage.

Move 4: Innovate Externally — Building Your Agentic Advantage

Here’s where Hayder got provocative: AI agents will disrupt SaaS.

Think about his Berlin trip example:

Current reality: → Hotel: Open travel site, compare prices manually, book → Train: Switch to DB app, re-enter dates, check schedules, book → Weather: Open weather app → Clothes: Decide outfit, check forecast again → Food: Research restaurants in separate apps → Family: Set reminder to call kids → Wellness: Make sure everything’s ready for tomorrow

Agentic future: → “I’m going to Berlin September 18-19 for a conference” → Agent books hotel, train, checks weather, suggests restaurants, sets reminders, handles everything end-to-end

You went from 7 apps to 1 conversation.

Why this matters for SaaS: The era of selling “engagement” is ending. The era of selling “outcomes” is beginning.

Hayder’s framework for the transition:

Old model: App/Solution → Engagement New model: Orchestration → Outcome

The question every SaaS company must answer: Will you OWN the orchestration layer, or will you become a commodity API that someone else’s agent calls?

Google, Microsoft, and Amazon are all racing to own this layer. So are hundreds of startups. The winners will capture the transaction layer—where all the revenue flows.

The Nuance: Which SaaS Survives?

When pressed on his “AI agents will kill SaaS” claim, Hayder got more specific.

High risk:
→ Marketing tools (easy to automate)
→ Basic customer support platforms
→ Horizontal productivity tools
→ Anything where adoption is already high today

Lower risk:
→ Industrial/manufacturing software (physical operations)
→ Deep vertical software with complex workflows
→ Systems that integrate with messy, legacy infrastructure
→ Enterprise tools where compliance and security dominate

But even in “safe” categories, the question remains: Are you building for engagement or outcomes?

5 Steps to Future-Proof Your Business Model

Hayder’s closing advice was tactical:

1. Face reality → Name both the risks and the upside. Don’t pretend agents aren’t coming for your market.

2. Obsess over outcomes → Customers will expect end-to-end results. “We helped you do the thing” beats “We gave you a tool to do the thing.”

3. Build the bench → You need world-class AI engineering + AI-fluent leadership. This isn’t optional anymore. Hayder estimates there are maybe 50-100 people in Germany who can properly run an inference service at scale. Hire them now.

4. Nail economics → Understand token economics and outcome-based pricing. Run experiments today with hybrid pricing models.

5. Think laterally → What OTHER problems do your customers have? If you own a travel app, maybe you should own the weather, restaurant, and reminder layer too.

The companies that survive won’t be the ones with the best AI. They’ll be the ones with the best business model for an AI-first world.

The Hard Questions on Pricing

One audience member asked about the challenges of outcome-based pricing for agents that run through dozens of steps.

Hayder’s answer was sobering: “I wouldn’t recommend anyone just going for outcome-based pricing because it’s probably the hardest pricing you can nail.”

Why? Two reasons:

1. Attribution problem: You need to prove this outcome came from this action. That’s hard when agents are making 50 decisions in a chain.

2. Value quantification problem: Even if you can attribute the outcome, what’s it worth? Not always straightforward.

The bigger issue? Agent safety and control. Agents can go rogue—there are documented cases of agents with root access deleting databases. You can’t price by outcome if your agent might accidentally nuke production.

The solution isn’t avoiding agents. It’s building the risk management, security, and monitoring infrastructure BEFORE scaling.

The Dependency Question (And Why Open Source Matters)

Another critical question: What about dependency on LLM providers like OpenAI?

Hayder’s take: The risk is real.

Political risk: An administration could cut off API access to certain countries. You’re done.

Economic risk: You have no control over pricing. API costs could 10x overnight.

Data risk: You’re sending potentially sensitive data to third parties with unclear processing practices.

His recommendation: Own as much of the stack as possible—but recognize this comes at massive cost.

Aleph Alpha runs their own models. The infrastructure cost is substantial. The talent cost is even higher. But for enterprise customers in regulated industries (banks, automotive, industrial), it’s the only acceptable path.

For everyone else? Build model-agnostic architectures. Be able to swap providers in minutes, not months. Test every new model release from OpenAI, Anthropic, Google, and Meta. Stay flexible.

Within 12-18 months, Hayder predicts most companies will run most tasks on open-source models where cost essentially disappears. Build for that world.

Your Move

The agentic AI era isn’t coming—it’s here. The question isn’t whether agents will reshape business models. The question is whether you’ll be ready.

Start with the framework: → Map your current business onto the 4 moves matrix → Identify which quadrant represents your biggest opportunity → Identify which quadrant represents your biggest threat → Start experimenting NOW

The companies that figure out outcome-based pricing, agent orchestration, and model-agnostic architectures in the next 18 months will have a 5-year head start on everyone else.

The era of engagement is ending.

The era of outcomes is beginning.

Which side of that transition will you be on?

Connect with Hayder

Dr. Hayder Schneider is Head of Product Management at Aleph Alpha, where he’s building enterprise GenAI products at scale. He specializes in deep tech and AI/ML platform products.

Connect with him on LinkedIn to follow his insights on agentic AI and business model innovation.

2025 09 18 Productlab Talk Hayder Schneider

1.07MB ∙ PDF file

Download

Download

When Asya Kuznetsova was first tasked with “grow through word of mouth,” she was puzzled. How do you control what someone somewhere tells someone about your product? How do you measure dark matter?

Today, as Sr Group Product Lead at Kraken, Asya has cracked the code. Her teams have consistently achieved 70-95% organic growth by treating word-of-mouth not as luck, but as a buildable system.

At ProductLab Conference Berlin 2025, she shared the exact playbook that helped fintech companies scale from millions to hundreds of millions of users—without burning through ad budgets.

Why Word-of-Mouth Matters More Than Ever

In a world drowning in paid ads and AI-generated noise, people still trust people.

Consider these cases:

→ Notion grew from 4M to 20M users in one year. 95% came through shared templates—essentially free word-of-mouth built into the product.

→ Spotify hit 650M users largely through social features. When you click “create” in Spotify, 3 out of 4 options involve friends.

→ Multiple fintech companies achieved 70%+ organic acquisition by building sharing directly into their core user journeys.

The companies you still use today? They’re probably the ones you discovered through word-of-mouth—because they were designed for it.

The Three Pillars of Word-of-Mouth Growth

Most companies hope for word-of-mouth. Smart companies design for it.

Asya’s framework has three components:

1. Organic Recommendations

These happen when customers notify others about your product simply by using it.

Examples: → When Spotify users share songs on Instagram, non-users see that their friends prefer Spotify → When fintech users send money, recipients get branded notifications showing benefits and savings → When Notion users share templates, they’re distributing free marketing

Think about your product: What features would automatically notify others when customers use them?

2. Network Effect Features

Build features that make your product more useful when others join.

Real examples from fintech: → Revolut’s “split the bill” feature—pay at restaurants, split in-app, friends pay you back instantly → Monzo’s group expense management—roommates pool expenses, easily settle up → Payment request features—one click to sync contacts, one click to request money

Customers invite friends not for rewards, but because the product becomes more valuable with them on it.

3. Incentivized Referrals

This is where most companies fail—they just throw money at customers hoping they’ll invite friends.

The key? Connect referrals to customer journeys.

Asya’s research revealed customers in fintech primarily recommended products for travel. So the entire referral program pivoted: “Invite friends to travel, give them a free travel card, earn cash rewards for travel.”

Result: Referral conversion improved several times over generic “invite a friend” programs.

The Referral Multiplication Effect

Here’s why referrals are the fastest path to impact:

John loves your product. You incentivize him to invite friends. He invites 5 people and gets rewarded.

John feels appreciated and becomes more likely to recommend again.

His friends receive incentives to try. They love the product because it came from someone trusted. They become loyal customers.

John’s friends are now more likely to recommend because they came through recommendation themselves.

John’s 5 friends bring 25 more. Those 25 bring 125. Exponential growth.

Dropbox proved this works at scale: they grew 40x in 15 months (100K to 4M customers) through a simple referral program.

The Recipe for Successful Referrals

Most referral programs fail because they’re disconnected from customer journeys. Here’s Asya’s tested recipe:

Step 1: Match customers in their first weeks

Send referral prompts when customers are in their “aha moment”—when they’ve just experienced core value and want to share.

Step 2: Give clear direction

Instead of generic “invite friends,” be specific: → “Invite friends to [specific use case]” → “Give them [specific benefit they’ll understand]” → “Earn [clear reward]”

Context removes the main blocker and improves conversions several times.

Step 3: Connect referrals to other social features

When you share a payment link, attach a referral link. When you split a bill, attach a referral link. When you connect all word-of-mouth features, they multiply each other’s growth.

Referrals are never standalone—they’re part of your entire social ecosystem.

Step 4: Maintain healthy economics

Manage referrals by payback period: how fast do you earn revenue from invited customers compared to reward costs?

Two levers to pull: → Decrease reward cost (variable rewards: “up to €50” where only small percentage gets top amount) → Increase invited customer revenue (require actions that correlate with retention to claim rewards)

For example, one fintech company found customers who spent €200 had healthy retention. To claim referral rewards, invited customers must spend €200—aligning incentives with business health.

The Cultural Challenge

One audience member raised an important point: cultural differences matter.

In Brazil, people share referral links freely across any channel. In Germany, people feel uncomfortable referring others for personal benefit.

Asya’s insight: When you talk to customers who don’t share referral links, they’re often motivated by helping others—but the money component feels uncomfortable.

The solution? Build referral mechanics that feel like genuine favors, not ads. Frame benefits around helping friends discover value, not earning bounties.

The Retention Advantage

A critical question from the audience: Do referred customers actually stick around, or is it just bounty hunting?

Asya’s data across multiple companies: Retention for invited customers is consistently higher than for customers from other channels.

Why? They came through trusted recommendations. They had better onboarding experiences. They joined with context about the product’s value.

B2B Referral Strategy

Growing B2B through referrals is harder—businesses have more barriers, they fear reputation damage.

Asya’s workaround: Target third parties who work closely with your customers but aren’t direct clients.

Examples: → Accounting firms that work with your business customers → Real estate agents who interact with your user base → Industry consultants who make regular recommendations

These intermediaries will recommend your product for incentives with much lower risk than asking your customers to become evangelists.

The New Growth Playbook

Every great company Asya knows didn’t rise to the top by outspending competitors on ads.

They succeeded because customers spread the word. The smartest ones didn’t wait for it to happen—they designed for it.

If you want exponential growth:

1. Build something customers want to talk about

2. Give them the tools to do it

3. Connect those tools to natural user journeys

4. Make sharing feel like helping, not selling

This approach cuts acquisition costs 10-fold while building defensible growth.

In rising competition, marketing costs skyrocket. Companies burn through money just keeping up with competitors.

But in a world full of noise and paid ads, people still trust people. And now with AI shifting standards, authentic word-of-mouth becomes more vital than ever.

Connect with Asya: Follow her on LinkedIn where she regularly shares growth insights. She’s currently hiring a Senior PM at Kraken to work on exactly these topics.

Escaping The Paid Growth Trap Asya Kuznetsova

5.56MB ∙ PDF file

Download

Download

The problem: Bugs everywhere, progress nowhere

Three years ago, Liza’s product team at SumUp was stuck in firefighting mode. Developers were interrupted by customer support agents at least once a day. Bug tickets got lost in JIRA. Urgent issues slipped through the cracks. And worst of all? Many of the reported “bugs” weren’t bugs at all—they were misunderstandings or feature requests dressed up as technical issues.

The team wanted to move faster and deliver more value, but they couldn’t focus. As one PM put it: “Yes, I agree we need to go faster, but my team is constantly distracted by bugs coming our way—and many aren’t even bugs. It’s wasted time.”

Classic catch-22: Product wanted engineering to ship faster. Engineering wanted Product to shield them from noise.

The unconventional solution: Hire from within

Instead of adding headcount to Product or Engineering, Liza looked inward—to Customer Support.

She recruited Alex, a senior CS agent with three critical qualities:

• Deep product knowledge (could distinguish bugs from correct behavior instantly)

• Attention to detail (tech-savvy, interested in engineering tools)

• Trust from the support team (crucial for adoption)

The role started part-time. No budget battles. No lengthy hiring process. Just an experiment: What if Alex became a “Product Specialist” who triaged all bug reports before they reached the engineering team?

What Alex actually did (and why it worked)

Alex’s initial scope was simple but powerful:

Bug Triage:

• Troubleshoot incoming issues

• Enrich tickets with context (error logs, impact assessment via Grafana)

• Filter out non-bugs and duplicates

• Pass only validated, detailed bugs to engineering

The impact was immediate. Because Alex came from customer support, he could:

• Train CS agents to troubleshoot basic issues themselves (reducing deflected bugs)

• Communicate changes back to the support team organically

• Distinguish real bugs from user confusion with expertise only a CS veteran could have

The numbers speak: Over three years, SumUp saw fewer bugs (both real and deflected) and saved an estimated 1,700 engineering hours—nearly one full year of an engineer’s time.

The evolution: From shield to enabler

After three months of success, Liza realized something important: This role could do more than just shield the team. It could enable them.

Alex’s scope expanded to include:

1. Merchant Feedback Insights

Alex became the team’s voice-of-customer engine, synthesizing feedback from:

• Support tickets

• Cancellation surveys

• Trustpilot and app store reviews

Every month, Alex presents categorized insights to Product, Design, and Marketing. They discuss what’s worth pursuing immediately vs. later. (And yes, AI helps automate parts of this now, but Alex still adds the human layer of context and follow-up.)

2. Contacting Merchants

When the team gets intriguing feedback but doesn’t have time to investigate, Alex reaches out to merchants directly. He’s also supported proof-of-concept testing where part of the flow required phone calls—something PMs rarely have bandwidth for.

As Liza notes: “These won’t be as qualified as user interviews. Choose which ones you’d rather do yourself and which you don’t.”

3. Regulatory Research

SumUp operates in heavily regulated markets (invoicing, accounting). Alex monitors regulatory changes—like new VAT rates or electronic invoicing requirements—and explores potential market expansions. He does the preliminary legwork so Product can make informed decisions faster.

The AI question: Could it replace Alex?

Liza addresses the elephant in the room head-on: Could AI do all this?

Her answer: “AI definitely supports this role, but couldn’t yet automate it completely.”

Here’s why:

• AI can help analyze feedback at scale, but Alex adds context, asks follow-up questions, and knows the CS team intimately

• Bug triage requires judgment calls that tools can’t always make

• Human relationships matter—both with the CS team (who trust Alex) and with merchants (who need a familiar voice)

That said, AI has made Alex more efficient. What used to take manual effort now happens faster, meaning one Alex can support more teams. SumUp started with a 3:1 team-to-Alex ratio and believes it can scale further.

Key lessons from Liza’s experiment

1. Start small, prove value, then expand The part-time approach avoided budget battles and allowed the team to test without commitment. Once the ROI was clear, the role became permanent.

2. Hire from Customer Support—seriously CS agents have an “untapped potential” that most companies ignore. They know the product deeply, understand user pain points, and can bridge Product and Support in ways external hires can’t.

3. Evolution over perfection The role changed dramatically over three years. What started as bug triage expanded to feedback synthesis, user research, and regulatory monitoring. Don’t be afraid to iterate.

4. Include them in rituals Alex attends design reviews and sprint planning. Why? Because he knows users better than anyone. His insights prevent blind spots before they ship.

5. AI is a multiplier, not a replacement Tools help scale the work, but the human expertise—especially from someone who’s been in the trenches—remains irreplaceable.

Is this scalable? Is it sustainable?

A great question from the audience: “Won’t you just need more roles as problems grow?”

Liza’s take: Yes, this is a permanent role. But it’s not a linear scaling problem. Better processes, automated testing, and AI tools mean Alex can handle more over time. The key insight? This role prevents problems from ballooning in the first place.

As one attendee reframed it: Alex isn’t a luxury hire. He’s Product Operations—the connective tissue that lets Product and Engineering focus on what they do best.

The bottom line

If your team is drowning in noise—bug reports, user feedback, regulatory changes—before you hire another PM or engineer, look inward. Your Customer Support team might have the answer sitting right there.

Liza’s story proves that sometimes the best hire isn’t a hire at all. It’s a promotion. And the best solution isn’t adding more resources—it’s leveraging the expertise you already have in smarter ways.

What SumUp got:

• 1,700 engineering hours saved

• Faster feedback loops

• Stronger Product-Support collaboration

• A scalable model that AI enhances (but doesn’t replace)

What it cost:

• One part-time role (initially)

• The courage to try something unconventional

Not a bad trade-off.

Liza Mello is a Product Lead at SumUp with 14 years in product management. She leads teams across invoicing, accounting, and point-of-sale products. Before moving to Denmark, she built her career in Brazil, bringing a uniquely resourceful approach to product operations. Connect with her on LinkedIn.

Scaling Your Team's Impact Liza Mello

3MB ∙ PDF file

Download

Download

“I don’t know.”

Not once, but repeatedly. In front of 300 product managers who came looking for answers about surviving the AI revolution.

And it was exactly what we needed to hear.

The panic we’re all feeling

When Daniele Ronca (Conference’s founder) asked Francesca to close the conference with a talk about AI, she had 30 seconds of panic. Then clarity: she didn’t want to talk about the tech. She wanted to talk about how we should relate to the tech.

Because here’s what we’re all dealing with: emotions ranging from excitement about AI’s possibilities to anxiety about mass layoffs. The tech is here to stay. We can’t control that. But we can control how we respond to it.

Francesca dove deep into research, expecting to emerge with all the answers. Instead, she found something more valuable: a framework for navigating uncertainty when nobody actually knows what’s coming.

The skill that lasts 18 months (not 5 years)

Remember when the lifetime of a professional skill was 5 years? That felt manageable. You could invest time, build expertise, and reasonably expect it to pay off.

Now? 18 months.

Don’t believe it? Remember prompt engineers? Those $200K+ jobs that were supposed to be the golden ticket? They disappeared almost as fast as they appeared. Not because the skill became less important, but because AI companies optimized for mass adoption and made prompting dramatically easier.

This leads to Francesca’s first major insight: The real skill is learning and unlearning. Not what you know today, but how quickly you can learn tomorrow.

The framework: Curious intentionality

Instead of running frantically trying to learn everything (the image of overwhelmed people running resonated with everyone), Francesca advocates for strategic curiosity. She calls it “curious intentionality” and breaks it down into five questions:

1. How does this actually work? LLMs are pre-trained on existing data. They can’t “think” – they give us the illusion of thinking. They can’t think outside the box because they only use the data they have. Understanding these limitations is power.

2. What are they optimizing for? Big AI companies are optimizing for mass consumption, not perfection. This is why hallucinations aren’t going away. They don’t care about fixing them – they care about usage.

3. How is it evolving? Watch the trajectory, not just the current state. Remember AI-generated videos six months ago versus now? The improvement curve tells you where to place your bets.

4. Where are the gaps? This is where your opportunity lives. What can’t AI do? What won’t it be able to do?

5. What should I focus on? Francesca’s advice mirrors product strategy: don’t spread yourself thin. Pick your eggs, choose your baskets intentionally. Skip an innovation wave? You’ll be fine if you’re paying attention. Don’t let FOMO drive you – let intentional curiosity guide you.

What is “un-LLM-able”?

This question became Francesca’s north star. In product strategy, you look for things that are hard to copy – sustainable competitive advantages. The same principle applies to your career.

Her answer centers on one word: Trust.

And here’s why it matters: AI hallucinations aren’t getting fixed. The big companies aren’t even trying. They want adoption, not accuracy. As fake images multiply and skepticism grows, the human who can be trusted becomes invaluable.

Francesca breaks trust into three components:

1. Credibility

Deliver what you say you’ll deliver. Simple, but foundational.

2. Value consistency

This is where Francesca showed the Jason Knight meme that hit hard: teams rushing to build AI features while basic customer needs go unmet. The customers waiting? They won’t wait forever. Either they’ll build it themselves, or someone else will build it for them.

The question isn’t “Can we add AI to this?” It’s “Are we creating actual value for our customers?”

3. Collaboration

Here’s where Francesca shared a hard-won lesson. Six or seven years ago, when stakeholders wanted to build the wrong AI feature, she’d try to prove them wrong. It never worked. Too much ego, too much reputation on the line.

Her new approach: “This is my thinking. What am I missing?”

Instead of collecting data to convince people, she collects data, presents it transparently, and invites collaboration. She involves stakeholders in the thinking process rather than trying to change their minds.

The process that works

Francesca shared her framework for navigating uncertainty (which, let’s be honest, is all of product management):

Study → Frame the question → Explore possibilities → Test → Converge

And critically: Involve and learn at every stage.

Then repeat with AI: Study AI → Frame choices around AI → Explore AI possibilities → Test with AI → Converge

Communication and execution happen throughout, but the key is continuous learning and stakeholder involvement.

Just to let you know, this is taking time.

Why “I don’t know” is the answer

Standing on stage, admitting uncertainty could have felt like weakness. Instead, it was the most powerful moment of the conference.

Because Francesca normalized what we’re all feeling: We’re ALL learning. We’re ALL on a learning curve.

Her presentation wasn’t a set of answers. It was a process she’d gone through – and is still going through. When she realized she didn’t know and still had to speak about it, her “product brain” kicked in.

What do you do when you don’t know? You dig into the question.

The takeaway

As AI rapidly evolves and skills become obsolete every 18 months, your competitive advantage isn’t what you know. It’s:

• How quickly you can learn and unlearn

• How intentionally curious you are (not just reactive)

• How much you can be trusted (credibility, value focus, collaboration)

• How well you involve others instead of trying to convince them

The tech is moving fast. Faster than any of us can keep up with completely. But if you’re curious, intentional, focused on creating real value, and building trust through collaboration, you’ll pick up the signals you need.

You’ll get there.

And if you skip an innovation wave? Remember the prompt engineers. You’ll be fine.

One more thing

At the end of her talk, Francesca said: “I hope I gave you some food for thought.”

She did more than that. She gave us permission to not have all the answers while showing us exactly how to move forward anyway.

In an age where AI is changing everything, the most human skill – admitting “I don’t know” and genuinely seeking to learn – might be the most valuable one of all.

Francesca Cortesi delivered this closing keynote at ProductLab Conference 2025. You can learn more about her on francescacortesi.com or connect on LinkedIn.

Ai Is Here – Now What Francesca Cortesi

3.31MB ∙ PDF file

Download

Download

This post summarizes Mirza’s talk. Quotes are from the session, but the wording and commentary are mine.

Mirza stood on stage and asked a simple question:

“Raise your hand if you’ve built an AI agent in the past six months.”

About half the room raised their hands.

“Keep it up if it actually worked the way you wanted it to work.”

Half the hands went down.

“Keep it up if you’re still using it six months later.”

Only about 10% remained.

The room got quiet. That uncomfortable kind of quiet when someone just said the thing everyone was thinking but nobody wanted to admit.

Mirza leads Zendesk’s AI agents platform. They process millions of customer service interactions, dealing with handoffs that fail, latency that kills trust, agents that break.

But they’re figuring it out at scale. What Mirza shared wasn’t theory. It was battle scars.

“You’re not alone. We’re all still learning and experimenting. Most of us are still figuring out how this is working.”

That honesty? That’s what made the room lean in.

The Job Has Already Changed (We Just Don’t Know It Yet)

“Most PMs don’t realize that the product management job has already changed drastically and fundamentally. We’re all still kind of catching up with it.”

That’s what Mirza opened with. And I felt it land in the room.

We’re still writing PRDs for probabilistic systems. We’re still running sprints for research that takes either 6 days or 6 months. We’re still planning features when we should be orchestrating capabilities.

The tools broke. The methods broke. And we’re all pretending they still work.

Three Tensions Breaking Everything We Know

Mirza identified three fundamental tensions emerging that are breaking traditional product management:

1. The Control Paradox

Users tell you they want control. They want to “train the bot.” They want to influence how the system behaves.

But they absolutely don’t want any complexity. They don’t actually want to know how it works.

Real example from Zendesk: A customer writes an instruction: “When a customer says X, always escalate to a human agent.”

The very next instruction they write? “But resolve everything autonomously.”

This isn’t stupidity. This is humans being human.

“Most users want the illusion of control, not actual system effectiveness.”

We want the illusion of control, not actual system effectiveness.

The solution isn’t more control panels or more settings. It’s designing touch points that preserve user agency without breaking the underlying system.

What this looks like in practice:

• Binary signals where human judgment actually matters (thumbs up/down, but contextualized)

• Evaluation layers that aggregate feedback before modifying behavior

• Three-layered architecture: big picture analytics, drill-down capability, and qualitative feedback with conflict detection

Here’s the insight that stuck with me: Users don’t want control—they want transparency. They want to understand how the system is performing and why it’s doing something. It’s a trust-building exercise, not a configuration challenge.

2. The Orchestration Trap

Specialized agents perform better. A focused agent that handles order cancellations will outperform a general chatbot every time.

But here’s the trap: More specialization = more agents = more handoffs = more latency = more failure points.

When Zendesk handles a simple customer query like “cancel my order,” it’s not one agent. It’s a choreographed dance:

1. Agent detects intent

2. Agent checks knowledge base

3. Agent makes API call to retrieve data

4. Agents validate context handoff

5. Agent generates response

6. Agent evaluates response quality

7. LLM judges overall conversation success

Seven agents. One query.

And users expect sub-second responses because that’s how humans communicate.

“Humans have very low latency. AI agents don’t. The number one problem we all have is latency, latency, latency.”

That gap? That’s what breaks trust.

This is the shift: You’re not building product interfaces anymore. You’re creating digital workspaces where AI agents collaborate to solve human problems.

“We’re creating digital workspaces for AI agents to collaborate with one another. Think Second Life, but agentic.”

Mirza called it “Second Life, but agentic”—specialized agents with clear roles, capabilities, and purposes, passing context between each other.

We’re designing the space where agents work, not just the output they produce.

3. The Evolution Crisis

Traditional planning methods are failing for AI products.

AI research cycles don’t fit into deterministic PRDs. Things can take 6 days or 6 months—it’s the nature of probabilistic systems.

“You can’t just write an upfront spec. I mean, you never should have been writing an upfront spec anyway, but now you really can’t with an AI system.”

You can’t write an upfront spec. (And honestly, you never should have been doing that anyway.)

This is causing teams to fragment along “AI” vs “traditional” lines.

And it raises an uncomfortable question: Should teams building AI products stop building user-facing features? Should autonomous agents be building the features instead?

Mirza didn’t answer that. He just asked it. And it hung in the air.

Because that’s the future we’re walking into, whether we’re ready or not.

What’s Actually Changing in the PM Toolkit

The evolution from feature builder to orchestrator is happening now:

PRDs → Prototypes (show, don’t tell)
Feature specs → Context architecture (prompts, agent instructions, context engineering)
User stories → Agent instructions (what should the agent do in this system?)
Product planning → Research cycles (hypothesis testing, not roadmap commitments)
Launch planning → Continuous orchestration (how agents interact and evolve)
Experience teams → Capability teams (building what agents can do)

And then there’s the new skill that will define PM interviews in 2026:

Evals.

Frameworks that measure AI system performance—metrics, scorers, evaluation datasets.

“The one skill I promise you everyone will be testing for in job interviews in the next year or so will be about evals. So learn evals.”

Mirza’s prediction: If you’re not learning this now, you’re already behind.

The New PM: Builder + Orchestrator

The PMs who will thrive aren’t just strategists. They’re:

Builders:

• Creating agents for themselves (personal experiments)

• Prototyping relentlessly (not writing specs)

• Designing agent interaction patterns

• Understanding what breaks and why

Orchestrators:

• Architecting how humans and machines collaborate

• Deploying agents to solve business outcomes

• Managing context flow between systems

• Creating transparency and explainability

Does everyone need to become a coder? No. Strategy and market understanding remain critical.

But the ability to prototype, to experiment, to show instead of describe—that’s the new table stakes.

Your Homework This Week

Mirza ended with a challenge:

“The question isn’t whether you’ll become an orchestrator, it’s whether you’ll do it intentionally.”

Here’s what he wants you to do:

1. Build one agent. Use Zapier, ChatGPT, whatever. Map one of your workflows (personal or work) as an agent interaction.

2. Identify one human touchpoint where you could simplify the experience.

3. Prototype instead of writing a PRD. Try running a research cycle instead of a sprint.

4. Share your learnings publicly. Create social proof. Document what breaks and why.

This is how you break into an AI PM role even if you don’t have one yet.

What This Means For Us

I’m sitting here at The Social Hub Berlin on a rainy Monday, and I keep thinking about that 10% stat.

Only 10% of agents are still being used six months later.

That’s not because the technology isn’t ready. It’s because we’re still applying old methods to a new paradigm.

We’re trying to plan the unplannable. Control the uncontrollable. Simplify the irreducibly complex.

And the teams that figure this out first? They’re not writing better PRDs. They’re not running tighter sprints.

They’re prototyping. They’re building evals. They’re designing for orchestration, not features.

They’re becoming the orchestrators Mirza described.

The Uncomfortable Truth

Here’s what Mirza said that I keep coming back to:

“None of us have all this figured out. But community is the competitive advantage that we as product people have.”

This is why ProductLab exists. These conversations—honest ones about what’s breaking and what’s working—are how we collectively figure this out.

Because the PM job has already changed.

The question is whether you’ll lead that change or react to it.

—Daniele

P.S. Mirza runs a newsletter for aspiring product leaders at . If you’re serious about breaking into AI PM, subscribe. He’s documenting the journey in real-time. Connect with him on LinkedIn.

Check the Slides

At ProductLab Conference, Ebrahim Kargar (Staff PM AI/ML at HelloFresh), Silvanus Alt (CEO of UXCam), and Ahmed Wafaey (Sr. Director at Delivery Hero) revealed what actually separates AI adopters from AI transformers. Here’s what they learned the hard way.

The Silent AI Epidemic: Your Team Is Hiding Their Best Work

The most shocking insight? While only 20% of workers admit to using official AI tools, over 40% are secretly using AI and reporting massive performance gains privately.

Why the secrecy? Ebrahim identified the fear-based thinking destroying your AI transformation:

• “If I reveal AI helped me, managers will stop respecting my work”

• “Productivity gains might lead to layoffs for me or my colleagues”

• “If they know I’m more productive, they’ll just expect more work”

This underground AI usage creates a fundamental barrier to systemic thinking. You can’t transform an organization when everyone’s pretending AI doesn’t exist.

The fix: Create psychological safety around AI usage. Leaders must explicitly communicate that AI is a capability enhancer, not a job replacement signal.

The Real Transformation Starts After Productivity

Everyone starts their AI journey the same way: 40% efficiency improvements, faster documentation, time savings. But here’s what separates the winners:

HelloFresh’s evolution: They reduced recipe creation from 18 weeks to 1 week using GenAI. But the transformation wasn’t the time savings—it was that this fundamentally changed their entire product development process and what they could now experiment with.

The pattern: Individual productivity gains → Changed workflows → New organizational capabilities → Different strategic possibilities

As Ebrahim put it: “The biggest piece of cake is focusing on effectiveness. Figuring out what is worth building, testing and validating hypotheses as fast as possible, having insights that none of your competitors has.”

The AI-First Build Process That Actually Works

UXCam’s radical approach: Silvanus shared how they transformed their entire development process:

Their Build Formula:

1. Rapid prototyping with AI (Lovable, etc.) → Ship testable versions fast

2. Gather feedback → Iterate in hours, not weeks

3. Hand off full spec → Engineering hardens and ships

4. “Vibe Coding” with AI IDEs → Keep improving agent usage

The game-changer: They explicitly document which AI model they used and why (reasoning vs. coding vs. speed) in every spec, PR, and demo.

Why this matters: Transparency kills the fear. When everyone sees AI as a tool choice—like picking React vs. Vue—it becomes normal infrastructure, not a secret weapon.

The Cultural Traps That Kill AI Transformation

Trap #1: Over-trusting eloquent LLM answers
Confident AI outputs without context = wrong answers. The fix? Human-in-the-loop on high-impact steps, golden data sets for validation.

Trap #2: Expecting prod-ready code on day one
Developers try agents once, get messy output, give up. The fix? Treat AI agents like junior developers—they need guidance, iteration, and clear constraints.

The real transformation: It’s not about better technology—it’s about building organizational capabilities that compound over time.

The Framework: How to Actually Score AI Initiatives

Stop chasing impressive demos. Silvanus shared UXCam’s evaluation framework:

Value × Feasibility × Trust

Then get razor-specific:

• One job → What exact problem does this solve?

• One metric → How do we measure success?

• Clear tests → What are our kill metrics per stage (Explore → Pilot → Scale)?

Critical insight: Embed AI engineers with product teams. Optimize for customer value, not flashy technology demos.

As Silvanus said: “Start narrow; scale what works. Choose and benchmark models for the job and be ready to swap.” Resist AGI scope creep.

What to Actually Measure (Beyond Time Savings)

Forget efficiency metrics. Here’s what HelloFresh tracks for AI transformation:

Efficiency layer:

• Time savings on specific tasks

Effectiveness layer (where the money is):

• Speed from insight to action

• Number of valid AI-generated hypotheses

• Validated prototypes

• Prototype-to-build ratio

• Outcome metrics: Cost savings, customer engagement, ROI

The insight: AI’s biggest opportunity isn’t automating existing workflows—it’s figuring out what’s worth building in the first place.

The 3-Phase Practical Implementation Roadmap

Phase 1: Foundation

• Identify high-impact workflows for immediate productivity gains

• Build cross-functional AI teams with clear mandates

• Establish ethical AI guidelines and measurement frameworks

Phase 2: Systemic Integration

• Evolve successful AI implementations into decision-making processes

• Train leaders to think systemically about AI capabilities

• Scale proven approaches across different organizational contexts

Phase 3: Transformation

• Embed AI thinking into strategic planning and operations

• Build organizational learning loops that improve AI implementations over time

• Develop AI-native approaches to new challenges

The Leadership Requirements (This Is Non-Negotiable)

Ebrahim’s observation: Transformative leaders go beyond saying “AI is important.”

What actually works:

• Paint a clear, compelling vision of what work will look like in the future

• Revisit expectations for different crafts and seniority levels

• Create incentives and a safe environment for people to learn and upskill

• Mandate adoption with resources, not just directives

The three pillars of AI transformation:

1. Workforce upskilling → Guidelines, resources, training

2. Infrastructure and tooling → Data foundation, tool integration, clear policies

3. Culture → Constant experimentation to find best use-cases for your org

The Bottom Line

Systemic AI transformation isn’t about implementing better technology. It’s about building organizational capabilities that compound over time.

The winners understand three things:

1. Productivity is the appetizer, not the meal → Real transformation changes decision-making and strategic capabilities

2. Culture change is harder than technical implementation → Invest in psychological safety, transparency, and internal champions

3. Measure outcomes, not adoption → Track business impact, not tool usage

The gap between AI adopters and AI transformers isn’t technical sophistication—it’s organizational courage to fundamentally rethink how work gets done.

What’s your organization’s biggest barrier to AI transformation? Reply with your experience—I’m collecting insights for a follow-up piece on the most common implementation failures and how to avoid them.

About the Speakers

This fireside chat brought together three product leaders at the forefront of AI transformation:

Ebrahim Kargar is Staff Product Manager AI/ML at HelloFresh, where he champions and drives GenAI transformation across the organization. He’s leading AI/ML initiatives at scale—from supply chain optimization to personalization—and recently reduced recipe creation time from 18 weeks to 1 week using GenAI. Connect with Ebrahim on LinkedIn →

Silvanus Alt, PhD is Founder and CEO of UXCam, an AI-powered analytics platform serving 37,000+ products worldwide. Under his leadership, UXCam transformed into an AI-first organization, implementing “Vibe Coding” practices and launching Tara, their AI Product Analyst that connects product and engineering data to reveal not just the what, but the why behind user behavior. Connect with Silvanus on LinkedIn →

Ahmed Wafaey (Moderator) is Senior Director of Product Management for Global Quick Commerce at Delivery Hero and writer at Product Voyagers, where he explores the intersection of product strategy, AI transformation, and operational excellence at scale. His insights on moving beyond productivity wins to systemic transformation set the foundation for this discussion. Connect with Ahmed on LinkedIn → | Read Product Voyagers →

Even worse? Only 2% have actually operationalized product operating models at scale.

I just watched Chris Compston (founder and consultant who helps organizations build great product operating models) break down exactly why this shift is so hard—and more importantly, how actually to make it work.

If your organization is stuck shipping features instead of creating outcomes, this is for you.

The shift everyone talks about (but few achieve)

Let’s be honest. We all know the theory:

• Stop saying: “We shipped new features and met our deadline”

• Start saying: “Our customers can now achieve something new”

• Stop saying: “We never have data, so we’re guessing”

• Start saying: “We’re making evidence-based decisions”

• Stop saying: “Sales told us to build this”

• Start saying: “We know what customers value”

Sounds simple, right? So why does almost everyone fail?

The three reasons transformation is brutally hard

1. No actionable guidance Everyone encourages product thinking (books, conferences, podcasts, ChatGPT). But there’s a massive gap between “be more outcome-focused” and actually doing it within your organization’s unique context.

2. The economy is punishing Tech layoffs. Global instability. The AI revolution. You’re being asked to do way more with way less—fewer people, smaller budgets, zero room for “safe to fail” experiments.

3. Organizations are built for certainty Most companies operate on the manufacturing model: “We’ll deliver X things and make Y money.” They’re built for certainty, which makes them reactive rather than responsive to change. In these companies increasing efficiency is often the only lever they can pull to differentiate them from their competitors.

The stat that should scare you

Customer-focused organizations are 60% more profitable.

And here’s the kicker: 50% of organizations say that in 5 years, 80% of their work will use product thinking.

That means your competitors are making this shift right now. The question isn’t whether to change—it’s whether you’ll be in the 2% who actually succeed.

The framework that changes everything

Chris developed his approach after some significant learnings from his time introducing change Farfetch (a luxury fashion platform where a transformation affecting 1,000 people took 3-4x longer than predicted).

Here’s what he learned:

Part 1: Connect strategic intent to tactical change

Don’t just say “let’s make more money” and “let’s be outcome-focused.”

Instead: Identify specific organizational capabilities you need to build—things like:

• Iterative learning

• Evidence-based decision making

• Customer discovery

• Cross-functional collaboration

Connect the high-level vision to concrete behavioral changes.

Part 2: Balance resources and incentives

You need BOTH:

Readiness: Do people have the right skills, tools, time, and space?

Motivation: What’s in it for them?

• Salary increases or role changes

• Learning budgets

• Recognition (internal and external)

• Growth opportunities

Most transformations focus only on readiness and wonder why nothing sticks.

Part 3: Cultivate long-term commitment

Don’t do this:

• Top-down directives (”Go be outcome-focused!”)

• Narrow team focus (”Fix iterative learning in your squad”)

• Vague mandates (”We’re a product company now—figure it out”)

Do this instead:

Create cross-functional working groups that:

• Pull from different roles (product, design, data, engineering, finance, marketing)

• Include different seniority levels

• Work across multiple teams

• Focus on one organizational capability at a time (e.g., “improve iterative learning across the entire org”)

This is how you get broad organizational impact instead of isolated team improvements.

Extra: Show, don’t tell (or ask)

When you’re stuck with external delivery commitments but trying to shift to product thinking:

Don’t: Ask permission to experiment Do: Find capabilities you can shift quietly, prove the value, then show the results

Experiment in safer spaces where you can demonstrate impact without high-stakes visibility.

The real-world challenge (and solution)

Someone in the audience asked the perfect question: “We have external commitments through next year. How do we shift to product thinking when we’re locked into deliverables?”

Chris’s answer was brilliant:

Your CPO (or top product leader) should be putting in the hard work to convince the exec team that outcome-focused work drives MORE business impact. They’re the ones who own the budget and the funding model.

As a PM on a team, it’s not your responsibility to make this happen; however, you can support this shift. By starting small, experimenting with more outcome-focused work, changing how you produce discovery, or ensuring iterative learning is taking place.

You can’t always predict how much revenue is going to be generated in a year’s time. You can, however, be more confident with that estimation if you’re using a funding model that allows you to build products and learn on a more regular basis.

What to do right now

1. Audit your organizational capabilities: Which ones need work? Where are the gaps between your strategic vision and tactical reality?

2. Balance readiness and motivation: Don’t just focus on skills and tools. What’s actually motivating people to change?

3. Start small and cross-functional: Pick ONE capability. Create a working group across teams and functions. Make visible progress.

4. Show value before scaling: Find safe spaces to experiment. Prove the model works. Then expand.

The bottom line

The product shift isn’t optional if you want to lead. Customer-focused organizations are 60% more profitable. Your competitors are already moving.

But transformation isn’t about reading the right books or attending the right conferences. It’s about connecting strategic intent to tactical change, balancing resources with incentives, and cultivating genuine commitment across your organization.

Most importantly: It’s about being in the 2% who actually make it work.

P.S. Chris is writing a book on this framework with co-authors Esra Yetis and Hugo Froes. You can learn more at maketheproductshift.com or connect with Chris on Substack: or LinkedIn.

Check the Slides

At ProductLab Conference 2025 in Berlin, Henrique shared the hard-won lessons from building what they claim is the world’s smartest AI spreadsheet. Unlike most AI product talks filled with theory, this was pure tactical gold from the trenches.

“In maybe 8 or 10 years of building and working in product, this is the first time that I can tell you that there’s a metric that it’s actually helpful to look at every day.”

— Henrique Cruz

The Speed of Now

Tech adoption isn’t just fast anymore—it’s exponential. What once took decades now happens in months. The next breakout app could reach a million users in hours. Henrique’s insight? Timing matters more than perfection.

They launched when the market was ready, even though the product wasn’t perfect. The result? They were “in the right place at the right time”—but that place was earned through consistent execution.

“It was the right(ish) product, at the right time. A $6k influencer campaign turned into 1 Million sign-ups.”

5 Principles for Building AI Products That Improve Daily

Henrique distilled years of experimentation into five core principles. This isn’t theory—it’s what actually works when thousands of users are hitting your AI every day.

1. Pick Problems AI Can Actually Solve

Not every problem needs AI. The sweet spot? Tasks where success is immediately obvious to users.

Henrique’s rule: Look for problems where users can instantly tell if the AI nailed it or completely missed. Avoid fuzzy creative work that needs endless back-and-forth iteration. That’s why spreadsheet formulas work beautifully—you either get the right answer or you don’t.

Action item: Audit your AI use cases. For each one, ask: “Can the user tell within 5 seconds if this worked?” If not, reconsider.

2. Don’t Get “Killed by OpenAI”

This was Henrique’s blunt warning: if you’re not 10x more useful than raw ChatGPT, you’re toast. The app layer has 80%+ margins, but only if you’re genuinely more valuable than the base model.

His team assumes models will be fast, cheap, and smart. They’re building for a world where AI costs approach zero. Your defensibility can’t come from the model—it must come from your product.

Action item: Run this test: Ask ChatGPT your product’s core question. If it gets 70%+ of the way there, you need more defensibility. Add domain expertise, workflows, or data integrations that the base model can’t access.

3. Price Where the Puck Is Going

Henrique introduced a brilliant pricing framework based on two dimensions: frequency of use and token consumption.

The matrix:

• Low frequency + Few tokens = Free (no-brainer)

• High frequency + Many tokens = Cannot afford to offer free trials

• Low frequency + Many tokens = Free to try (onboarding friction is worth it)

• High frequency + Few tokens = Freemium sweet spot

His team watches these metrics daily because token costs are dropping fast. What’s expensive today might be free next quarter.

Action item: Map your features onto this matrix. Adjust your pricing tiers accordingly. Review monthly—the AI cost landscape shifts constantly.

4. Treat Prompts as Code

This might be Henrique’s most important insight: Prompt engineering IS software engineering.

“We noticed that our answer rate had dipped from, you know, let’s say 85 to 73 or something and it had dipped because the day before we had made a change on how to process part of the instructions. We had run a few tests, it had passed, but then once hundreds of people are using it at night in the US or whatever, clearly this wasn’t working. And so we basically had to roll back on Saturday.”

— Henrique Cruz on why prompts need version control

At Rows, prompts go through pull requests, testing environments, and automated evaluations. They version everything. They rollback when things break. One Saturday, they caught their answer rate dropping from 85% to 73% because of a prompt change—and rolled back immediately.

The anatomy of their prompt (26,000 characters for their game analysis feature):

• Context: What the app knows about the user

• Instructions: The system prompt (broken into objectives, optimal solutions, and rules)

• Examples: Concrete demonstrations

• Reflection: When the AI checks its own work

Action item: Stop treating prompts like ad-hoc text. Set up version control, A/B testing infrastructure, and automated evals. If you’re not treating prompts like production code, you’re doing it wrong.

5. Establish KAIzen Routines

Henrique loves the Japanese concept of Kaizen—continuous improvement. He calls it “KAIzen” for AI products (clever, right?).

“This is my favorite thing maybe that I do every week, which is actually reviewing the prompts of what the users are asking the AI... You try to get intuition about what are people using the product for. That’s the whole goal.”

— Henrique Cruz on weekly prompt reviews

Here’s what they review:

Daily:

• Answer rate: Can we parse and execute what the AI returns? (They went from 86% to 95%)

• Prompts per day: Volume tracking (they’re 5x vs. their baseline)

• Cost per prompt: Currently under $0.08, but they know it can drop 90%

• Failed questions: What broke and why?

Weekly:

• User conversations: Read actual prompts to understand use cases (his favorite ritual)

• New models: Test every new release from OpenAI, Anthropic, Google, Meta

• Model switching infrastructure: They keep their architecture model-agnostic so they can swap providers in minutes

Henrique shared actual user prompts they see: people trolling them (”Who is LeBron James?”), asking for impossible features (”Can you see who doesn’t follow me on Instagram?”), wanting everything in German, and exposing bugs (”Where is it done?”—when the AI said “done” but did nothing).

This weekly review gives them intuition about what users actually want versus what they thought they wanted.

Action item: Block calendar time NOW—30 minutes daily for metrics, 2 hours weekly for prompt analysis. This isn’t optional surveillance; it’s how your AI product learns.

The Numbers That Matter

When asked about the impact of these routines, Henrique estimated:

• 80% of improvements came from big architectural changes

• 20% from daily kaizen tweaks

But here’s the key: those daily reviews inform the big architectural decisions. You can’t make smart big bets without ground-level intelligence.

“Maybe 80% of the improvements we’ve had over the last five or six weeks was a big architecture change... But these things are really important to get intuition about what’s working and not working.”

— Henrique Cruz on the balance of daily tweaks vs. major changes

The Honest Truth About User Feedback

Henrique’s team debated adding thumbs up/down buttons. They decided against it. Why? It creates biased samples. Only motivated users click—either very happy or very angry.

“We always said no because it’s going to really be a biased sample. A small percentage of people will click yes or click no and then maybe overindex on the people that said yes.”

— Henrique Cruz on why they don’t use thumbs up/down feedback

Instead, they look at behavior:

• Do users come back?

• Do they keep prompting?

• What does the conversation history show?

Some users hit their AI 70 times in one day and never reply to emails. Clearly it’s working for them. Retention tells the real story.

“Sometimes you have people who don’t reply to any email and use it, you know, had to use it like 70 times in one day prompting. Clearly, it worked for something for him or her.”

— Henrique Cruz

Build with Belief, Not Hope

Perhaps the most striking moment came during Q&A. Henrique was asked how far ahead they bet on pricing dropping. His answer revealed their conviction: “We’re very close. Within 12-18 months, we’ll run most things on open-source models, and cost won’t be a problem.”

“I think we’re very close... we already use an open-source model in the AI analyst for a small task and the open source model is basically free... we think that within the next 12-18 months we’ll be running most things on open source and then the cost is not really a problem.”

— Henrique Cruz on betting on the future of AI costs

They’re not optimizing for today’s costs. They’re building for a world where smart AI is essentially free. That changes everything about product strategy.

Your Move

Building AI products isn’t magic. It’s discipline.

Henrique and the Rows team proved that with the right framework—picking the right problems, treating prompts as code, establishing daily rituals, and pricing for the future—you can build products that genuinely improve every single day.

The AI landscape moves fast, but the fundamentals remain: understand your users, measure obsessively, iterate constantly, and always assume the technology will get better and cheaper.

Start with one thing tomorrow: pick ONE daily metric to review. Answer rate, prompt volume, user retention—just one. Make it a ritual. Then add the weekly prompt reviews.

The AI product that wins isn’t the one with the best model. It’s the one that gets 1% better every day while everyone else ships and forgets.

Want to dive deeper? Henrique is active on X at @henrm_cruz, Substack , and he his the one who taught me the most about Growth and PMM on LinkedIn. You can try Rows at rows.com

Here is his presentation!

Ai Product Lifecycle Henrique Cruz

10.5MB ∙ PDF file

Download

Download

After ProductLab Conf>, we asked you which talks resonated most—and Pranav’s session on scaling AI experimentation came out as one of the absolute favorites. So many of you reached out asking for a deeper recap to share with your teams.

Here it is. For the community.

You know that moment when a speaker starts their talk and you can just feel the energy shift in the room? That happened when Pranav took the stage at ProductLab Conf> on September 18th.

The lights were bright, the ProductLab Stage was packed, and Pranav—who leads Product Development for AI at Booking.com—opened with a confession that made everyone lean in: “I can’t see much because of the lights, but wow, we have a full house!”

What followed was one of the most honest, actionable talks on AI experimentation I’ve seen. No fluff. No AI hype. Just real lessons from someone who’s been doing AI for 10 years (yes, before it was cool) and has the battle scars to prove it.

The Failure That Changed Everything

Let’s start with the uncomfortable truth Pranav shared: his first chatbot was a complete disaster.

Back in 2017, his team spent 12 months. They involved three separate teams. They built a “virtual post-booking customer service agent in training” using basic natural language processing (remember, no GenAI back then).

The result? Customer satisfaction didn’t move. At all.

Here’s what hit me: It’s not just that it failed. It’s that it took a YEAR to fail.

But here’s where the story gets interesting...

The Transformation: Tripling Their AI Success Rate

Fast forward to today. Booking.com’s AI experimentation success rate is now more than triple their standard product launch rate.

Let me repeat that: Their AI experiments succeed at 3x the rate of traditional features.

That’s not luck. That’s a system. And Pranav broke down exactly how they did it.

The Four Principles That Actually Work

1. Spot the Right Opportunity

Pranav shared their prioritization framework—and it’s beautifully simple:

• Pain: How much does this problem hurt?

• Reach: How many users does it affect?

• Data: Do we have what we need?

• Proof: Can we validate this works?

But here’s the nuance he added during Q&A: “It’s not just about the numbers. If something’s going to generate €20 million more for the business, I will take that over everything else.”

They’re doing 200 BILLION predictions per day at Booking. The scale is wild. But they still ask: What moves the metric the most?

2. Track the Right Metrics

This one really resonated with the PMs in the room. Pranav was crystal clear: don’t track vanity metrics.

At Booking, they don’t obsess over weekly active users. They track conversion. Why? Because:

• It overlaps business and user value

• You can isolate what caused it to move

• You can continuously iterate on it

• It’s actionable

“If you make a change to the product, you set up an A/B test, it moves up or it moves down. You’re able to isolate the cause of that movement quite easily.”

3. Democratize AI Across Your Organization

This might be the most underrated insight from the talk.

When Booking first asked teams “What do you want to build with AI?”, they got 1,000 submissions. Only 5 were viable.

Today? They get about 100 submissions per year. 90 of them are viable.

What changed? They trained their org. Not on transformer architectures or how LLMs work under the hood. They taught six practical skills that AI is really good at.

“If the AI skills in the organization are concentrated towards one team, no one else is ideating,” Pranav explained. And without ideas, you can’t scale.

4. Learn the Tools, Experiment, Ship Fast

Remember that first chatbot that took 12 months? Their latest version took 3 months with just two teams.

Same company. Same complexity. Different approach.

They now:

• Centralize the tech that drives experimentation

• Automate the iteration cycle (prompts, user feedback, model responses)

• Make it easier for teams after their first success

“The first time that the team experiments is always much harder,” Pranav admitted. “But then the second and third and fourth iteration pick up quite naturally, because the team now knows where the success comes from.”

The Real-World Examples That Prove It Works

Pranav showed us three live products that exemplify this approach:

1. AI-Assisted Host Replies
Hotel partners can now auto-generate responses to guest messages. It’s been wildly successful—partners love it because it saves time, guests love it because they get faster replies.

2. Personalized Property Descriptions
Instead of showing the same generic hotel description to everyone, Booking now uses AI to tailor descriptions to user profiles. A family sees “five bedrooms, five bathrooms, ample space for families.” A solo traveler sees something completely different. Same property. Different story.

3. The Chatbot That Actually Works
Three months to build. Two teams. Good customer engagement. Good task completion. Good conversion rates.

It’s the redemption arc of that 2017 failure.

The Uncomfortable Questions (and Honest Answers)

The Q&A session was gold. Someone asked about hallucinations and inconsistency—the classic LLM problems.

Pranav’s response? They don’t lower temperature (that kills the magic users expect). Instead:

• They use evaluation models (evals) and train their own

• They demand structured outputs (JSON responses)

• They send a percentage to human evaluators

• They use deterministic models for critical paths (like property recommendations)

“We have very low tolerance for factual accuracy, actually, because big business, lots of risk.”

Another question was about scaling after experiments. How do you shorten cycle time?

The answer: centralize the tech. If five experiments all use question-answering, build it as a shared service. Iterate across all five together.

What We’re Taking Away

Here’s what this talk taught us about scaling AI experimentation:

Start with real problems, not AI solutions. Pranav emphasized: “Our customer problems are not changing. Travel still has the same complications. We just now have a tool that’s really good at taking some of those problems away.”

Embrace failure as data. That 12-month disaster in 2017 taught them more than any success. Now they’ve streamlined legal compliance assessments from 3-4 months down to 3-4 days.

Make AI accessible to everyone. When your whole org can think in AI terms, you get better ideas. It’s that simple.

Ship fast, learn faster. They have 200+ GenAI implementations prioritized and dozens of successful product launches already adding meaningful revenue.

The Energy in the Room

Standing at the back of the ProductLab Stage, watching PMs frantically take notes while Pranav fielded questions, I was reminded why we do ProductLab Conf>.

It’s not just about the content (though Pranav’s was exceptional). It’s about that moment when someone shares the real story—the failures, the breakthroughs, the behind-the-scenes details—and you realize you’re not alone in struggling with these problems.

By the way, Pranav offered a beer to anyone who could guess how many predictions Booking makes daily. Someone shouted “5 billion!” They were off by 195 billion.

Gesundbrunnen—yeah, not exactly the Berlin you see on Instagram. But here’s the thing: while everyone’s fighting for overpriced flats in Kreuzberg, this neighborhood near [Nord]bahnhof is quietly transforming. New bars opening up. Prenzlauer Berg parents discovering they can actually afford space here. Tech people realizing the S-Bahn and FEX connection is unbeatable.

Like AI, sometimes the smartest move is the path no one’s talking about yet.

Which brings me to ProductLab. CIC Berlin (the space previously known as The Factory) was buzzing with energy—250 product managers, leaders from across Europe, all trying to figure out what the hell we’re supposed to do with AI.

Then Stefan Ostwald walked on stage.

And honestly? Everything shifted.

The moment that changed everything

Stefan started with something deeply personal. Since he was a teenager, he had one obsession: Can I build something that works FOR me, not WITH me?

Failed robot bachelor thesis. Failed carpooling startup. Failure after failure.

But here’s what got me: he never stopped trying. Because there’s something magical—his word—about systems that work for you. Systems that help you even when you walk away.

And with Paloa, he finally cracked it. Not through robotics. Not through clever algorithms.

Through large language models that can reason and act.

The question that breaks everything open

Stefan asked us something that’s been haunting me ever since:

“What if, instead of building a better hammer, we built the carpenter?”

Let that sit for a second.

We’re all sitting here in our product teams, building better search tools. Better analytics dashboards. Better checkout flows. Even our “AI features” are just... better tools.

But what if we’re thinking about this completely wrong?

Tools vs. Workers: The test that matters

Here’s the framework Stefan gave us, and it’s so simple it hurts:

Can you walk away and it keeps working?

• If NO → You built a tool

• If YES → You built a worker

That’s it. That’s the difference between the past and the future.

He painted this picture of Jesse, a consultant with a travel agent worker. Her flight gets delayed. But before she even panics, her agent has already:

1. Rebooked her on the next flight > 2. Informed her hotel > 3. Extended her car rental > 4. Got her a voucher for a free meal > 5. Filed €400 compensation paperwork

Jesse barely had anxiety. The worker handled everything.

Six months ago? That day would’ve been hell. Now? Few Seconds.

These experiences are currently only available to CEOs with amazing assistants. In the future, they’ll be available to everybody.

This is happening across EVERY industry

Stefan didn’t just talk theory. He showed the transformation happening everywhere:

CRM: Not dashboards—workers qualifying leads and following up
Analytics: Not dashboards—analysts digging into data and alerting you
Competitive analysis: Someone watching the market for you 24/7
Customer service: Paloa’s client Minia increased satisfaction by 38%

The models are ready. They’re good enough right now.

What’s missing is the applications on top. That’s what WE need to build.

The hard truth about transformation

Here’s where Stefan got real with us. Like, uncomfortably real.

At Parloa, they had a successful rule-based automation product. Tripling revenue every year. Everything was working.

And they made the shift anyway.

He didn’t sugarcoat it: “This was really really intense. The commercial team was shielding pressure from competitors who were advancing faster on the old pattern. Technology was hustling hard to get the new product running.”

But here’s his point: What choice do you have?

Two paths:

Path 1: Keep going with what works
→ Short-term success + low risk
→ Long-term: Someone else will rethink the pattern and disrupt you

Path 2: Transform now while you’re successful
→ Hard now + significant risk now
→ Realistic chance of long-term success

The question isn’t “will industries be disrupted?”

The question is: Will YOU be the one disrupting it?

What to do Monday morning

Stefan gave us homework. Real, practical homework:

Ask yourself: What will be your WhatsApp moment?

(Context: WhatsApp completely rethought communication when SMS was dominant)

Then, when you go back to your team:

1. What problems do your customers always have?

2. What do they always need to look at?

3. What do they always need to drill down into?

Then ask a different question: Not “how can we improve our tool?” but “Can we build something that works FOR them?”

Once you ideate, test it: Can you walk away and it keeps working?

If yes, you’re onto something.

Four principles for building AI workers

Stefan gave us his battle-tested framework from building at Paloa. This isn’t theory—this is what actually works:

1. Recognize the spectrum

It’s not binary (tools vs. workers). There’s everything in between—like co-pilots in coding where AI does work but humans review before deployment. Consciously decide where on the spectrum you should be for each problem.

2. Design for references, not descriptions

Imagine trying to describe “the blue pants in the upper left” to an agent. Exhausting, right? Instead, make things explicitly referenceable. Like Notion’s @ symbol. Make implicit references explicit = faster velocity + better quality.

3. Design for review, not perfection

AI makes errors. It will continue to make errors. The job isn’t to make it perfect—it’s to make working with an imperfect AI easy. Look at Cursor in coding: smooth iteration cycles, easy accept/decline, simple rollback when AI goes off rails. Design for the error state, not the perfect state.

4. Design for behavior validation, not configuration

Traditional systems were deterministic—add a rule, it follows the rule. AI agents? They’re like humans but worse. Just because you tell them something doesn’t mean they’ll do it. The truth is what actually arrives at the user, not what you put into the model.

Stefan’s team simulates hundreds of scenarios, then uses another AI agent to evaluate them automatically. Build the validation loop, and you can even do automatic prompt optimization.

Why this hit different

Look, I’ve been to a lot of conferences. Heard a lot of talks about AI.

But Stefan’s talk hit different because it wasn’t about “AI strategy” or “digital transformation” or any of that consultant-speak bullshit.

It was about a guy who’s been obsessed with building autonomous systems since he was a teenager. Who failed multiple times. Who finally figured it out. And who’s willing to tell us—not from theory, but from the trenches—exactly what it takes.

He stood up there and said: The age of AI is here right now. If you don’t do this, somebody else is out there doing it.

And you know what? He’s right.

My take from Berlin

I’m writing this from Gesundbrunnen—not the coolest neighborhood, I’ll admit. But it’s near Hauptbahnhof, rent is actually affordable, and something interesting is happening here. Cozy bars are popping up. Mummies are migrating from Prenzlauer Berg. Tech people are discovering what locals already knew.

It reminds me of Stefan’s talk, actually. Everyone’s chasing the obvious paths—Kreuzberg, Mitte, Prenzlauer Berg. But sometimes the smartest move is to take the uncovered path. To see what others are missing. To bet on transformation before it’s obvious.

Berlin has always been about reinvention—tearing down walls, building new things from the rubble, embracing change even when it’s uncomfortable.

Stefan’s message feels very Berlin to me: Don’t wait for the perfect moment. Transform while you’re successful. Disrupt yourself before someone else does.

CIC Berlin, where we hosted ProductLab (previously known as The Factory)? Stefan mentioned they started there years ago. Full circle. From startup struggling to make autonomous systems work, to standing on that stage showing 250 product managers exactly how to do it.

That’s the journey we’re all on right now.

The models are ready. The technology is there.

The question is: Are we bold enough to stop building better tools and start building workers?

What’s your WhatsApp moment?

I want to hear from you. Seriously.

What’s the thing in your product where users are constantly drilling down, constantly looking at dashboards, constantly doing repetitive work?

What would it look like if that worked FOR them instead of WITH them?

Reply to this email. Let’s figure this out together.

Because Stefan’s right about one thing: Someone’s going to rethink your industry.

Might as well be us.

—Daniele

P.S. ProductLab 2026 dates coming in December. If this year taught me anything, it’s that we need to keep having these conversations. The revolution is here. Let’s architect it together. DM me on LinkedIn!

About the Speaker

Stefan Ostwald, Chief AI and co-founder of Parloa, is a leader in conversational AI with nearly a decade of experience making customer communications easier and more secure through AI. Connect with him on LinkedIn.

Again, thanks and kudos to Daniele and the ProductLab team for putting together a fantastic day—it’s not an easy feat! Note also that there were three parallel tracks: the sessions I attended and have summarized here don’t represent the whole conference.

High-Level Thoughts

• AI and vibe-coding are allowing more people to build higher-fidelity prototypes. On a high-trust, psychologically safe team this can democratize idea-generation and spark great conversations.

• AI seems to be the catalyst for a lot of teams reevaluating their processes in ways that aren’t specific to AI. Processes have calcified and become overly “waterfall” and pedantic; this hits PMs especially hard because great product-development requires ambiguity and flexibility, which is in conflict with predictable process. For example: I’m still a believer in understanding the customer problem separately from testing solutions, which is a bit of process/framework…but those don’t have to happen in series and sometimes it’s fine for them to bleed into each other.

• We’re starting to get real about AI. I see this in the news and on LinkedIn, too. That’s great: all the “AI will take all our jobs and solve all our problems and destroy the world” talk is exhausting and makes us feel gaslit. Whereas, “Hey, AI can do some cool stuff and we’re figuring it out,” is energizing.

• Vibe-coding is not production coding — I’ve always felt that way and it was good to hear it from multiple speakers.

• Humans are great at stuff that AIs aren’t, and some of that stuff is needed in product management. Find things that are “un-LLM-able” and do them.

Stefan Ostwald: The Intelligence Age

Stefan talked about his vision for AI and agents in particular. He laid out some useful principles when thinking about AI product design:

• Design for reference, not description. I’ve talked about this as “direct manipulation” — basically people will want to manipulate artifacts or parts of artifacts with AI. Not, “Change the blue one second from the right,” but, “Here, change this one.” This is also a critical component of the project I’m doing with.

• Design for review, not perfection. AI makes mistakes, so build products that expect it to.

• Design for behavior validation, not configuration. This is in part about evals and automatic prompt optimization.

Fabian Strunden: AI from Discovery to Delivery

In this roundtable, Fabian laid out the first compelling case I’ve heard for PMs vibe-coding prototypes. His team uses them as a communication tool, acknowledging that they’re not “real” designs and simply serve to communicate an idea — it’s expected that designers and others will push back and it’s really just about the conversation. They use the hashtag #badidea to indicate these moments.

This makes a lot more sense to me than what I see on LinkedIn — “PMs can stop doing everything else and just vibe-code prototypes!” — since it doesn’t imply that such prototype are sufficient…just useful. A couple things occurred to me as a result of this roundtable:

• We see a lot more talk about AI accelerating solution discovery than problem discovery…but in fact it’s useful for both, e.g., automating literature reviews, coding user research transcripts. (I’ve been doing a bit of this in my productivity-app research.)

• For prototypes to work as conversation, you need a high degree of trust and psychological safety within a team.

Pranav Pathak: Scale Experiments with AI

Pranav got into specific frameworks and examples for how to prioritize and evaluate AI product experiments. He explained the PROVE-IT prioritization framework — Pain, Reach, Own data, Verifiable, Execution loop, Integration time, Total cost. He then took us through two real-world examples from Booking explaining how the framework applied, and how each of the projects turned out.

In a world of vague hype it was great to see such concrete examples and analysis.

I also liked what he had to say about metrics: track the right metrics. A good metric is clear, reflects the actual product goal, and is iterable. Business metrics are problematic because they’re also sensitive to outside factors like the global economy; engagement metrics are too easy to game.

Lucie McLean: Navigating Organizational Change

Lucie led this roundtable discussion of organizational change — a topic that’s always on people’s minds and especially these days with layoffs and the spectre of AI. As is so often the case, I was impressed and humbled by people’s willingness to ask for and offer advice with thoughtfulness and vulnerability.

Elena Leonova: The Brutal Truth About AI Product Success

A lot of AI strategy is hype. Key point here: Your moat can’t just be the AI model because everybody has the model. What meaningful differentiator are you delivering beyond a prompt? Potential moats include your data, your behavioral understanding, or your workflow (i.e., does it match what your users need and expect?)

Asya Kuznetsova: Escaping the Paid Growth Trap

Enjoyed this not only because it wasn’t about AI, but because Growth isn’t my core skillset. Asys says beware paid growth: its techniques keep changing, and it can be expensive and unsustainable. She then went into detail about techniques and perspectives that work:

• Word-of-mouth is powerful and is something you can drive.

• Organic recommendations are powerful: encourage customers to notify other people about your product as part of the actual functionality. Ex: splitting the bill in Revolut, requesting money from non-user contacts in Wise. (I recall emails saying, “You’ve got cash!” in the early days of PayPal, too.)

• Ask yourself: How can customers benefit from having others use your product?

• Incentivized recommendations (e.g., referrals) work well, too. Things like rewards or discounts for referring friends & colleagues. The right incentives vary not only by product but also culturally.

• Counterintuitively, you want to nudge customers to refer early in the journey: after the first food order, etc. This is when delight is highest.

• In a noisy world, people still trust people—a sentiment echoed later in Francesca Cortesi’s closing keynote.

Simone Basso: The Community Bet

Simone talked about a new product he and his team built at WeRoad. They started with an idea and, with a team of 5–6, went from zero to MVP in a couple months. Two interesting tidbits here:

• Yes, they vibe-coded a prototype in a couple days…and then redid it from scratch to create the actual MVP.

• What they learned from the MVP? They hadn’t fully understood the customer problem. I asked Simone about this after the talk: if he did it over, would he pause and do a little research? He said no: this was the fastest way to learn. Reminder that discovery and implementation are different activities using some of the same methods.

Francesca Cortesi: AI is here — Now What?!

There’s so much uncertainty, ambiguity, and rapid change around AI. What’s happening? What’s going to happen next? Cortesi doesn’t know. Most of us don’t know. And that’s OK. Instead of reacting with fear, let’s react with curiosity.

AI is machines: when you play the speed game with machines, you lose. But humans are good at things that AI is not — things that are “un-LLM-able.” Find the un-LLM-able and focus on that instead. Curiosity, learning and unlearning. Thinking creatively.

LLMs offer the illusion of thinking but can’t think outside the box. Trust: LLMs hallucinate and that makes trust an un-LLM-able skill. “Trust is your most important currency.”

Don’t react: strategize. That’s un-LLM-able too. You can go fast…or you can go intentionally in the right direction. (I’m reminded of the old saying, “Don’t mistake motion for progress,” which has always been an issue.)

Here are Francesca’s slides, shared with her permission.

is a versatile product leader with 25 years of experience spanning Product, Design, and Engineering. A two-time founder with exits to Google, he’s held leadership roles at Google, Facebook, Heap, and Yahoo. Now based in Berlin, Dave advises the ProductLab community on industry trends and maintains strong connections to the US product scene. You can follow him on LinkedIn.