Why Webflow is betting on AI-native product teams

In this episode of Product Talk, Denise Hemke sits down with Webflow CPO Ben Haefele to explore why Webflow is betting on AI-native product teams and what happens when AI makes building software faster, cheaper, and more accessible. Ben shares why traditional upfront planning can actually create more risk, how Webflow is using “building backwards” to put working software in front of customers sooner, and why human judgment and customer empathy matter more than ever.

From agentic development and rapid experimentation to the rise of the product “editor,” Ben offers a practical look at how leaders can redesign their teams around a faster learning loop, without losing sight of the strategic vision that keeps everyone moving in the same direction.

If you’re leading a product organization in the age of AI, this conversation will help you rethink how you build, learn, and decide what deserves to ship.

Join us for new conversations with leading product executives every week. Roll through the highlights of this week’s podcast below, then head on over to our Events page to see which product leaders will be joining us next week.

Show Notes:

1. Ben’s central argument is that the logic of traditional software planning has flipped. For decades, teams spent months reducing the risk of building the wrong thing because engineering time was expensive and slow. Now that coding is fast and increasingly accessible, the biggest risk is no longer building the wrong thing. It is spending so much time planning that the market changes before you ship. The new playbook is to build something real, put it in front of customers, learn, and iterate.
2. That does not mean no planning at all. What changes is the artifact that drives alignment. In the old model, teams would write a doc, then design in Figma, then code, with each step requiring stakeholders to use their imagination to understand what the finished product would feel like. Now, the initial working implementation becomes the artifact. Teams build something real first, then use that as the thing they refine with each other, with functions, and with customers, because real software generates real feedback in a way that documents never could.
3. Ben makes this distinction explicit when he talks about layers of abstraction. When you start with a document and then a design file, you have built something that describes the thing, not the thing itself. Every stakeholder who reviews it has to imagine a different version, and people vary enormously in their ability to picture how a design comes to life in software. Executives and customers whose job is not building software have not developed that skill. Put a working version in front of them and they can tell you immediately what works and what does not, without the imagining.
4. The twelve-month roadmap probably does not make sense anymore, and part of the reason is that the intuition product managers have built about what is technically feasible keeps being invalidated. Experienced PMs have learned to find solutions in the overlap between customer value and engineering feasibility, but that intuition about what is feasible breaks down constantly now. Ben sees real value in teams naively attempting implementations just to reestablish a sense of what is actually possible today, even if many of those experiments do not make it to production.
5. The new bottleneck is not time to code. Right now there is a short-term bottleneck around time to review code, but Ben believes that gets solved with AI and better systems over time. What remains is learning velocity: how quickly are you incorporating feedback from real experiments in market back into the next iteration? Do you have the instrumentation to understand usage patterns? Do you have the rituals to get live feedback from customers? Those are the constraints that matter now.
6. Customer empathy has not been automated away, and Ben is direct about this. The one thing that cannot yet be offloaded to agents is the deep understanding of the person on the other side of the screen, what their business needs, and what about the existing product experience frustrates them. That spark of empathy is still what gives a team the right ideas to go build, and it is still what helps the team converge on solutions rather than fragmenting in all directions.
7. Webflow ends the software development lifecycle with documentation, not at the beginning. Agents look at the commits and pull requests that formed a new feature and generate documentation at the very end, once the implementation is final. This solves two problems: documentation is dramatically faster to produce, and it is accurate to what was actually built rather than to the original design that was often modified after user feedback in alpha or beta. The old way of writing documentation first and updating it later was always a painful, lossy process.
8. The skill Ben believes matters most in the AI era is being a great editor. People who have become people managers, whether they managed technical writers, designers, or product managers, have spent years giving feedback on artifacts that someone else generated and working to make them better. That is exactly the skill that translates to working with agents. Individual contributors who have always been on the receiving end of feedback are the ones who need the most support developing this capability, and Webflow is investing in creating deliberate opportunities for ICs to practice giving feedback in reviews.
9. When Webflow started running agentic development experiments, the outcomes across team members were wildly uneven. Some people built things that no one thought were possible. Others built things that looked promising but that engineering partners said were not scalable and would take significant work to get production-ready. When they dug into why, the answer was that the most successful people were prompting agents to build with engineering best practices baked in. They would spend time on the agent’s plan, ensure requirements were clear, and instruct the agent to use test-driven development. Human best practices turned out to matter just as much when directing agents as when writing code yourself.
10. Webflow responded to that insight by building a custom in-house coding harness that embeds those best practices into the system prompt by default, so no individual has to remember them in the moment. The harness also integrates all organizational context: the roadmap, business objectives, quarterly key results, which accounts are at risk, and what the company’s brand is. Before the agent writes a line of code, it has all of that context loaded. Ben describes this as the organizational second brain that teams have been working toward.
11. The CPO’s job has changed in two specific ways. First, staying on the frontier: what is possible has shifted fundamentally and keeps shifting, and Ben believes it is the product leader’s responsibility to live at that limit, understand the rough edges, and then systematize what they find so the whole team can raise its ambition. Second, vision clarity: when the cost of building any individual idea is near zero, the only thing that keeps a team from going in fifty directions at once is a clear and ambitious vision about where the biggest opportunity lies.
12. Webflow’s journey to agentic development took twelve months and followed a deliberate sequence. It started with the product design org, which moved from static Figma files to interactive prototypes built on code. The best practices from that cohort were then extended to the full design org, then to product management, and then to the entire product organization contributing directly to the actual code repository. Ben describes this as progressive enablement: find the pioneers, learn from them, and extend those learnings to wider and wider circles within the organization.
13. To make agentic development a real practice and not just something that happened during a sprint or two, Webflow did three things. They created dedicated weekly time for people to work this way, because without calendar protection it would not happen. They baked the competency into their career ladder. And they set an explicit OKR requiring everyone in the product org to ship something to production every quarter. Ben is clear that the last one would never have happened without the explicit goal. Clear expectations create the incentive structure for teams to actually meet them.
14. At WebflowCon, their annual customer conference, Webflow ran a live version of this process. They set up a side room where customers could walk in and describe pain points, and product, engineering, and design team members would immediately kick off agent sessions to address them. By the time the session was done, they had improved over fifty things in the product in a single day. Ben sees this as a preview of what product development could eventually look like: a more continuous flow from customer feedback to agent response to human judgment to shipped improvement.
15. The human judgment piece is not optional and is not going away. Ben’s model is that when an agent produces a naive implementation in response to customer feedback, the product manager’s first interaction with that feedback is not just seeing the feedback, it is seeing a possible response to it. That makes the judgment call dramatically easier and faster. But someone still has to decide: is this fix actually applicable to everyone, or just to this one customer? Is it a net benefit to the product? That is the job that stays human.
16. One of the immediate practical benefits of agentic development is that the P3s and P4s, the quality-of-life improvements and small friction points that have been sitting in the icebox for years, can now actually be addressed. The business case for a human spending a sprint on a small improvement was often hard to make. When an agent can address it in an afternoon with light human oversight, the calculus changes. Customers feel the difference, and the cumulative effect on brand and retention is real even if it is hard to quantify.
17. Webflow’s mission since the company’s founding has been to let people with creative ideas realize them without needing to know how to code. Ben sees AI as doing exactly that, and it creates a direct line between how the team builds internally and the product experiences they need to deliver to customers. Customers need to learn how to work with agents to build and evolve their websites. There is no way Webflow could help customers do that if they had not understood it themselves first. The internal practice is not separate from the product strategy. It is the same thing.
18. Ben’s view of what software is becoming is distinct from what it has been. In the past, software was a set of dials and knobs that you turned to get something done. With agents, software is starting to become more like a thought partner or a team member. It can look at what you have built, understand how your audience is responding, and come to you with suggestions about what to make better, drawing on your business goals, your brand, and what is resonating in market. The user’s job is then to edit and improve that suggestion, not to generate the idea from scratch.
19. The four-minute mile analogy Ben uses to explain why ambition has to rise alongside capability: for decades, running a four-minute mile was considered physically impossible. Now it is commonplace. The analogy for product in 2026 is companies going from zero to $100M in ARR in under twelve months, something that until recently was also considered impossible. That is the new ambition product leaders need to set for themselves and their teams, but you can only see it as achievable if you are living at the frontier of what is now possible.
20. Ben’s three recommendations for any CPO who wants to redesign their product development lifecycle: start with progressive enablement by finding the people already working this way and using their learnings to bring wider circles of the org along; create dedicated time for people to practice the new way of working, because it will not happen organically alongside existing responsibilities; and set clear, explicit expectations like an OKR, because without a stated goal teams will not prioritize developing the competency. Enablement, time, and expectations. All three are required.