The two paths to building AI-first product teams

Here's what nobody tells you about AI adoption: there's no single playbook.

I recently sat down with Christine Itwaru (VP of Product at Userflow) and Lauren Schuman (VP of Product Growth at Close) to talk about how they're transforming their teams for the AI era. What surprised me? They took completely opposite approaches—and both are crushing it.

One embedded AI expertise into existing teams. The other built a dedicated AI squad first, then scaled company-wide. Both strategies worked because they understood something most product leaders miss: AI adoption isn't about the tool stack, it's about how your team learns.

‍

The two strategies that actually work

Christine's approach: Embed AI into existing teams

Christine didn't create a separate AI pod. She embedded AI expertise directly into her existing product teams, focusing on intentional integration rather than disruptive reorganization.

Why this works: Teams learn AI in context, solving real customer problems instead of theoretical ones. As Christine put it: "My approach is really being intentional about embedding expertise and growing it within existing teams versus spinning up a completely separate pod."

The key insight? She treats upskilling as part of the work itself, not a side project. "Treat the upskilling that we're doing in learning as part of how we're doing the work, versus a side project."

‍

Lauren's approach: Start small, then scale

Close took a different path. They assembled a small, dedicated team around a specific AI feature to move fast and learn ahead of everyone else. Once that team proved the concept and learned the hard lessons, they scaled those insights company-wide.

Why this works: The dedicated team becomes your internal experts who can then educate the broader organization. "We started with a small dedicated team around a specific AI feature so they could move fast and learn ahead of the broader team. Because this team was ahead, they were able to educate the broader team, and then we brought everybody else in."

Lauren's philosophy? "You can't hire your way into being an AI-native org...you need to cultivate a learning culture and hands-on experience."

‍

The three principles both strategies share

Despite their different approaches, both Christine and Lauren follow the same three core principles:

1. Start with the customer, not the technology

Christine is relentless about this: "What are we going to do to keep them around? And then I work backwards from there."

Before rolling out any AI feature, she assesses customer receptiveness and willingness to change. AI for AI's sake doesn't work—your customers need to want it, understand it, and see value in it.

The trap most teams fall into? They build AI features because competitors are doing it, not because customers are asking for it.

2. Prove outcomes before you scale

Both leaders emphasized the importance of showing measurable results before pushing AI adoption wider. Christine shared how launching SmartFlow Creator (Userflow's AI-powered flow builder) helped her team see tangible benefits, which drove broader acceptance.

The psychology: People resist change until they see concrete proof it works. Your job as a leader isn't to convince people AI is the future—it's to show them it solves real problems today.

3. Make learning hands-on, not theoretical

Here's where most companies fail: they send their teams to courses, conferences, and workshops, then wonder why nothing changes.

Christine's take: "Unless I have something to apply [the learning] to, it may sit idle."

Lauren's solution at Close? Build something. Right now, her team is building a voice agent using ElevenLabs. "The most valuable part is just to build something."

The pattern is clear: teams learn AI by doing, not by studying.

‍

How technical should your team actually be?

This was the question everyone wanted answered. Do PMs need to code? Do designers need to understand LLMs?

Christine's answer: "Know enough to speak confidently and move things along when your engineer isn't there."

You don't need to be an engineer, but you need enough technical depth to have informed conversations with customers, engineers, and stakeholders. You need to understand what's possible, what's a limitation, and what's just hype.

Lauren put it more bluntly: "Everybody in product really has to be more technical than they probably are used to being."

The bar has shifted. What used to be "nice to have" technical knowledge is now table stakes.

The companies getting this right aren't waiting for the perfect moment or the perfect tool. They're experimenting now, learning fast, and building AI capabilities while others are still debating strategy.

Your customers aren't waiting. Your competitors aren't waiting. Why should you?

‍