CPO at Webflow | Building Backwards: The New Rules of AI-Native Product Development

All right. Hello everyone. My name is Ben Hafley. I'm chief product officer here at Webflow. Uh for those of you that don't know, Web Flow is an AI marketing platform. We help teams and the agencies that support them not only build beautiful, expressive, onbrand websites that power their business presence online, but also help those teams manage the entire website life cycle. So, not just the build phase, but also continually adding content to their site so that it's relevant to their audience day after day. And then giving those teams rich insights into how their content is performing with integrated analytics as well as then the ability for them to continually optimize their site with new content, new variations, and continual sort of personalization uh that helps drive real results for their sites. So, I'm excited to talk to you all today about not Web Flow itself, but how the product team at Web Flow has gone under a pretty radical transformation, especially over the last six to nine months as the nature of the work that we do as product managers and product designers has really changed because of AI. So, with that uh we'll dive into the presentation here and we'll talk about this concept that internally we we're referring to as building backwards. And the reason that we we call it that way is because the software development life cycle, you know, it's it's really a process that all of us have followed since really going back to the 1970s and it's being turned on its head in a pretty radical way. Um, this this is a big deal for all of us. It's upending nearly every process that we've had we built around this development life cycle. It's changing how we plan, how we spec, how we design, and ultimately how we ship. So here's the flow that we all grew up with. I think um you know you you start with the idea that requirements with the user experience itself, pressure test those requirements. uh then uh engaging with engineering on actually writing the code and working with product QA design to then test what was actually built and then finally uh deploy it. The agile movement uh tried to to break this waterfall and it was successful to some extent. While our cycles definitely got shorter over the last decade and a half, the you know, especially compared to back in the 80s and 90s when teams were shipping on floppy discs and then later CDs, we all know that like we've essentially been following some version of this same process. And the reason for that is because we really had to this middle part of this process of writing code that really took a long time and as a result was very expensive and so getting to market as quickly as possible meant more upfront planning to reduce the amount of time spent changing the code later. So there was this economic pressure that really sort of locked us into this waterfall. Even if we were able to create many versions of it and ship more iteratively when we weren't stuck on actually shipping onto physical media. But with the rise of agentic development, this is really flipping on its head. Now you can describe what you want in plain language. You can have an agent that will then build your idea in minutes and you have the opportunity to then have the first thing that you react to rather than being a brief or a doc or a mockup. It can actually be a working application. And what this means for us is that we actually have to let go of all the intuition that we built up over our careers about what's going to be hard for our teams to implement, what's going to be really easy, and ultimately how long things take. And those intuitions were really built for the different world. And the tricky part is the the job to be done for us as product team leaders is not to replace that old intuition with the new intuition because the reality is we have to be in this constant state of evolution because the foundational models and the harnesses around them and all the tooling that we're that we use are getting better and better every month. And so what's hard today may actually be just a oneshot prompt next month. And so it's not that we have to develop a new sense of hey this is this is actually really easy now. It's that we have to develop a habit of constantly pushing the limits on what we think might be possible and continually testing that boundary because the boundary is always moving. And so in this new world, this process runs almost completely backwards. You do still start with the idea, but now the next step is usually deployed code. Then you get to test it and see what the agent came up with. You play with it, and then you start to shape it and bring intentional design to the experience. And then when all is said is said and done, that's the moment when you can codify the requirements and create documentation for all of the rest of the team and your support functions and your customers so that they know what it all is possible with the the software that you've created and how it's meant to work. So, look, I know there's probably a part of you that's thinking, hey, this sounds great in theory, but this is a massive and sometimes likely painful journey that we're all sort of embarking on in this moment, and there's a risk that we could turn our products into AI slop. And so, is this is this really worth it for us to to go through this change? But let me tell you, I have really really strong conviction that this is actually going to dramatically increase the quality of the work that we all drive and ultimately the products and the experiences that we're creating for for our customers. So the Standage Group has been publishing something they call the chaos report for decades. And every time they come out with this report, their finding is essentially the same. Projects that don't succeed generally fail because of abstract requirements. And the reason for that is as humans, whether it's you as a product leader, product manager, product designer, or just as often your stakeholders, the reality is it's hard for us to know for sure what we want until we actually interact with something and we realize this isn't this isn't right. It's not working. And if you're like really if you've really built up a strong skill as a product manager, product designer, you know how to interrogate that intuitive sense so that you can get to a more concrete understanding of why you don't like what's not working and you can begin to anticipate that. But often when you're working with stakeholders or with customers, they don't have that skill set developed. They just have that intuitive sense. And so you show them something that you think is what they want and they told you that it's what they want, but once they actually get to interact with it, they realize that it was not. And and that's really at the heart of why projects that don't work out ultimately fail. Uh and so you can think of it like is it's in this old world that we've been operating in, you were asking your teams and your customers and your stakeholders to essentially commit to a floor plan before they'd ever even stood in the house that you're building. But with Agentic development, you can actually walk your stakeholders and your customers through 20 different houses all within the course of a day so that you can get a really good understanding of what they actually do want because they can experience it. And so by the time you actually are writing the requirements down, you're you're writing them as someone who has already lived inside of the product. And so it's not that we're skipping requirements altogether. It's just that they are crystallizing at the very end of the process. And you know, it turns out that this change is actually some of the best practices in software development that we've been grasping at for a long time and they're finally fully realized. In fact, I tend to think that this might actually be the purest expression of agile development. If you go back to the agile manifesto, you can see all of these concepts baked right into it. Uh the the number one tenant of the agile manifesto is working software over documentation. This new inverted software development life cycle actually starts with working software. Their next tenant was customer collaboration. This is what I just described. We're working with customers with real working alphas immediately, not reviewing a word doc or a spec. The next tenant is responding quickly to change. This is so much easier when you can ask an agent to iterate on a PR with real working code. Every iteration is a response to change. The agile manifesto at the time was a vision for a world that we actually didn't have the technology for yet to fully realize its promise. But now here we are almost 25 years later and the technology, the tools that we all have as product leaders have finally caught up to that dream. And as I was saying before, the feedback that we're able to get from our customers and stakeholders is so much better because those customers and stakeholders are able to react to a real working version of software rather than an abstraction in the form of a document or a spec or a mockup. It's real working software. So the feedback that they can give you is at much higher fidelity. So you can go through many more iterations to get to a higher quality product faster. And there's also another engineering best practice that this new software development life cycle mirrors. That's test-driven development. You often hear practitioners of test-driven development or TDD talk about this concept of red green refactor where they start the code in a red state where they've defined a test for how it should work. They see that it is not working because the software hasn't been built yet. They write the software to pass the test. That's when the test goes into a green state. And then after they get it working, then they refactor so that it's nice clean code and it's scalable. And this vision, this philosophy from TDD of uh visiting the destination first even if it's broken exactly parallelizes what we're talking about with with agentic development. But it scales this loop from being iterated on with units of code or particular functions that are defined within the code to actually doing this at the feature level where product teams now can describe and then build and then react and then repeat that process over and over again really really quickly. And so again, it's not that we're creating up a new play creating a new playbook here. We're actually leveraging ones that have existed for a while, but product teams have really struggled to to actually put into practice. And so when we do this, the nature of the value that we all bring to our work uh changes considerably because what we're talking about is AI really absorbing this production layer, things like uh iterating over particular over particular pixels. And so what's left is that the majority of our work moves from uh the actual production and implementation of the idea to curation and taste and judgment. And I think that's actually really exciting. I know that it in for some people there is this sort of existential question of well if AI can do all my work what value can I bring? But I think it actually gives us the opportunity to work on the more creative aspects of the work that we all drive today. And I think for designers in particular, their work shifts from designing a particular feature instead spending more times on the system itself. creating the rules around the design system, the components, the tokens, spacing scales, accessibility standards, the things that actually teach the agents that are implementing the the the code and the features themselves what good looks like before they even attempt to to generate. And so it's really higher order work that we're asking our teams to to put forward. And then on the flip side at the end of the process the designer then becomes more of the uh the critic and actually giving feedback to what the agent produced. So making sure that there is this final quality gate between saying that hey an agent actually built something that works and saying hey this is actually qual high qu high enough quality that our customers will actually use what we've developed here. So I've spent some time here talking about uh how we think about this in theory but I want to shift to talking about this in practice because as I mentioned before product team at web flow has been going on this journey for the past a little over six months now. And so I just wanted to share some real insights of uh how we've approached this and lessons we've learned as we've evolved along the way. Um, so first, um, let me jump over here to, um, uh, to to to this. So, this looks a lot like Web Flow. Um, but this is actually this is actually not Web Flow. This is a code repo that we use as a design mockup. So, mimics a lot of the UI of Web Flow. Uh, this isn't this isn't a Figma file. This is actually defined in code. It's it's uh, moderately interactive just like our our real software. And where we began this journey was we asked both our product designers as well as our product managers to begin to use agents to iterate on this prototype repo so that when they were creating ideas for new projects they were doing it as interactive prototypes defined in code. So, not fully functional software um but still at a much higher level fidelity than you would get from a spec or from something like a static mockup like you might do in Figma. And so this is where we started. We enabled teams with this repo uh and then they would use uh tools like cursor or cloud code to to generate prototypes. One of the things that we then found uh is that people started creating a large volume of these. And so sort of the next problem for us to solve was was on a higher order which was how do we create more visibility and more organization to all of these essentially design artifacts that everyone across the product or was making. Uh and so this is an internal tool uh that our our design leads built uh called atrium. And this is a place for us to organize and catalog all of these design concepts that our teams are building. And so uh this is a thing that I think we're going to continue to see uh not only product teams but really all teams uh that are uh driving work in this new era do which is create their own tool set. Um, so atrium here is a place for teams to showcase uh work that they've been doing and it's um it's meant to be flexible because people are creating artifacts in lots of different mediums. It may be a pre-recorded Loom video or an actual video file from drive they've uploaded. It may need to link out to a particular repo that they've deployed somewhere for people to interact with. And so because all of the nature of these artifacts has has become less uniform over time, it became really helpful for us to create our own tool to find a place to to collect them. So that was sort of one of the first iterations of this journey that we went on and this is where we started. The next was we wanted to create clarity for the product team on what our expectations were for product managers and product designers in this new era of AI. And so I'm going to show you a a document that we developed internally um because we wanted to make those expectations really clear in our product manager career ladder. So I won't read through this whole thing but I wanted to highlight a couple of concepts and then also show you how we communicated it out uh to um to the team because I think this is creates some helpful framework that you might apply to your own teams. We really set about thinking about AI competency in three ways. The first is the the work that a PM does. Uh so and you can think about this for product designers as well, but their actual craft. So things like doing customer discovery, driving strategy, creating specs, enabling the go-to market functions. Uh so how can that all be accelerated with AI was the first thing. The second was delivering AI powered product experiences. So, it's not just enough for us to use AI to make our traditional work go faster, but also making sure that the product experiences we were creating were giving our customers uh uh AI superpowers as well. Um, so that was the second dimension. And then the third was really leaning into this concept of product team members as builders so that they're actually directly building functional software that gets delivered to our customers. So we um we aligned around these three concepts. And then the next thing that we did was we took our existing um career expectations for different levels and rather than create a a whole another um set of requirements for um a career ladder specifically for AI, we took our existing organization and we added in um uh expectations around AI along those three dimensions. And so this is a diff view we created where it has both the original set of expectations at different levels uh and then how these new principles around AI competencies uh fit into each of those. So there there is also a combined version of this document but as we were working through the change management here we wanted people to clearly see where each of these expectations folded in to uh the existing career ladder that we already had. All right. So that was the next step. And then once we set this expectation around um uh PMS as builders especially uh some of the feedback that we got was that we needed to create time in the in the calendar for our team to work on on on actually becoming builders themselves and actually shipping code to production. And so we u we went through a few iterations here. These started as a a quarterly builder day where we did specific enablement for teams to understand how do I use tools like cloud code and cursor. Um and eventually we got to the point now where this is something that as a team we do every Wednesday. So we we worked with the team and all our cross functional partners to uh clear any standing meetings from Wednesday so that everyone had dedicated time that they could work on building up this skill uh and and and creating this building up this muscle of building. And so um we have a lot of fun sort of rituals that we do around this not only dedicated Slack channel but we also have uh this uh what we call this builder board here. And so um people are able to to track how uh different PMs and product designers and members of our ops team are actually creating work to improve our the quality of our product experience. So um so it's uh we wanted to make sure this was really visible to the entire organization and then obviously celebrate people who are leaning in here. Um and so uh this is this is fairly recent for us. We we just announced in our hall of builders. Um this is one of our PMs who had the most FPRs that were actually shipped to production. For us, it's not about the number, but it's about celebrating people leaning into this new version of the craft. And so there's different ways that teams can hold up examples of people that are leaning into this new way of work. Um but this has been a fun way uh for some for us here. So this is the next step. And then the next thing that I wanted to show here was um we then begin to develop our own tool set um and so um not only do we have teams using tools like cursor and cloud code and codeex um but we've also been creating our own uh harnesses so that one our best practices can get uh imp can get baked in by default so people don't always have to remember the right way to prompt an agent for example. Um and then also creating integrations to where we already work. So flower is the name of an internal harness that we've developed that not only do our product or use but also our engineering team uh to drive a lot of the code changes that they work on now. And this also has a direct integration with our Slack. And so u for example um if I have an idea for an improvement to the product or better yet I hear about a point of friction from a customer I can come into Slack and just type in a quick prompt here. So I I'll kick this off. We won't have time to actually see the whole the whole feature being implemented, but just so you can get a sense of this. So we have um we have a feature in Webflow where teams can define in their design system their design tokens or variables. Um but uh sometimes this has like a cold start problem. So uh let me go ahead and write a prompt here. Um, when customers are viewing their variables tab and they haven't created any yet, um, give them a prompt to enter their primary and secondary brand colors. Then um a button to generate um those variables and a complimentary set of color variables. Um, using aliases back aliases and functions that reference the brand colors. Oops, I made a mistake here, which is um I forgot to mention flower. So, let me go ahead and do that and type that again. Okay, great. So, um you can see Flower responded right away and uh it's going to start kicking off an agent to begin trying to figure out what the heck I was even talking about and then drafting a PR. So, it'll come back to me with questions if it needs clarification. Um uh but really what it's going to do is it's going to kick off an implementation of this idea. So again before it's fully crystallized I can begin to play with real working software um before I think through is this even a good idea what's the naive implementation the agents going to make how can I make the design better all that happens with the PR first rather than at the very end and then uh you can see here so this is a UI um where we can get visibility into how our team members are using flower so we can see the prompts and the types of things that they're creating and we have a team uh dedicated ated to making Flower better and better. Uh so it can do things like reference screenshots um be able to um get more context from a Slack thread if it's if we're referencing some conversation that we've had from another uh customer that we want to pull in here. Um and so as we lean more into agentic development, we've continued to um see exponential acceleration in our productivity by uh creating more and more tool sets uh for us to help accelerate our work. And then the last thing I wanted to show here uh so this is this is a PRD based off of um uh a feature that someone had prompted an agent to build. And once the feature was implemented um then uh it gave it this gave the agent this prompt here which was take a look at the PR and in this case it was actually multiple PRs in a stack and then said hey use the web flow PRD template to create a PRD and so what the agent then did was it looked at the entire commit history for this PR and um and then it took that understood what the changes were that the code was asking for and the back and forth with the PM when it was going through all the iteration and then taking that context and marrying it with our PRD template. And so it automatically generated all of this documentation which is several pages worth going through all of these different features that this code change touch coming up with a clear crisp uh articulation of the product the problem statement the solution that was implemented the target users and the personas that this feature is really oriented towards where there's competitive um uh capabilities in the market and all of this would have taken a PM um at least a couple of hours to handwrite. But instead, as I mentioned before, in building backwards, all of this documentation happened at the very end and it was written by an agent who was able to say, "Hey, let me look at the final code that we created uh and then create all the context for all of the other uh stakeholders, whether it's customer support or product marketing so they can quickly understand what this is and help us bring it to market. So uh that was a little bit about how web flow is actually bringing this philosophy of building backwards uh into reality. So just to recap quickly uh this was a journey for us. We didn't start with uh our product or shipping code. Uh instead we started at the beginning which was how can we use codebacked AI prototypes to create higher fidelity artifacts for us to iterate on. Then we created internal tooling to help us navigate all of this explosion of of artifacts that we were creating. Then we really leaned into a thoughtful progression of enablement, making sure that we were training our teams on uh what it means to use these new tools that didn't exist a couple of years ago. uh and we kept iterating and sort of raising the expectations from prototype to functional software to actually shipping PRs into production to now builder Wednesday is just a part of our our regular weeks. We've also built up more tooling to continue to think about how can we remove the friction for the product or that is building in this way. And so you saw me uh kicking off an agent from a from a Slack thread. So I didn't have to totally switch contacts to use a different tool and I didn't have to think about all the best practices that I would have to manually ask an agent to do if I was just using a vanilla tool rather than this customuilt uh this customuilt harness that we've implemented uh as as a Slack app. And then we also uh set a goal for ourselves. So in this current in this current quarter we set a goal for not only engineering but all of our product team members, our designers, members of our ops team uh that they all have shipped a shipped code that actually lands in production. Um and so this was our first quarter we just finished uh where we had this as a goal and and I'm really excited that that we actually we we made it. Um so we had literally 100% of our team uh shipping code to production. And if you think about just the product or at the beginning of the calendar year, that was probably between zero and 5%. And so this was a big change. Um but but I think because we were so intentional about uh creating this progressive enablement strategy as well as better and better tooling, we were able to to pull this off. So uh and then again, we set the right expectations for the team uh and really wo AI skills into our career ladder. so that there was clarity for everyone on how their work was changing and how we were going to help them navigate that change. So uh this is this is I think my last slide here um but uh you know you can think about us uh and the way we designed this process and this transformation that we were leading our teams through is um one we started with prototypes. Uh two, we were really intentional about how we enabled the team um and sort of continually raised the expectations so that we could get all the way to our end goal of shipping code to production for people that had never done it before. We also built specific rituals so that this was protected time for everyone to go on this journey. Then we set we set a goal for ourselves and we measured our progress along the way. Then finally we codified it so that it was really clear to everyone what our new expectations were for them. Okay. So that was building backwards. You know the uh I think what I would just leave you with before we get into a couple questions is that you know the reality is the hard part of software is no longer generating code which used to be where all the time and investment really was. Now, it's really more about knowing what's worth building and recognizing quality when you see it and iterating fast enough so that you can get to the version that matters. So, the arrow of product development is really running the the opposite direction of where where it used to. And as I said at the beginning, this really has to change nearly every process that we built up along the last couple of decades. going through this kind of change and taking your teams along with you, you're gonna break some eggs along the way. That that's okay. I think one of the things that's really important is as we're all figuring out this out together, one, it's worth us sharing sort of our wins and our losses so we can help learn together. Um, and two, as you take this back to your teams, be sure to bake in grace into the process. Make sure that your system is resilient enough to handle like setbacks when things don't go as expected because we're all f figuring this out together. But when when we do that the sky is really the limit here. All right. Well, thanks so much for your time today. This was really fun to talk about. Um definitely uh feel free if you're going on this journey as well, feel free to reach out to me on LinkedIn. And I'm always excited to learn about how folks uh from any part of product are working through this and how it's changing their work and how they're able to deliver more value to to their customers. So, thanks again so much and looking forward to connecting in the future.