When to off-road the product roadmap

As we enter the new year, you’re probably already in execution mode, working through carefully plotted 6-to-12 month roadmaps. Your team has done the heavy lifting of synthesizing research and user feedback, aligning with other teams, and ensuring that your plan is adequately resourced. Now, it’s time to go from scoping to shipping. There are Gantt charts to make, kickoffs to have, and launch strategies to create.

But before you get consumed by the tactics and to-dos, take a step back. Things are different this year. AI technology is evolving rapidly. Agents and assistants are transforming our workflows, and tools like Claude and Cursor promise to make app building as easy as writing a few prompts. These new tools have changed the game, and users expect more from the apps they use every day. This requires a quicker pace than traditional product development methodologies allow, along with a more experimental mindset to match. Amidst all this change, clear direction is appealing. But when we follow a roadmap prescriptively, we run the risk of holding too tightly to a specific direction—even if it’s no longer the right path forward.

Over the past few years, Figma has grown beyond a tool for designers, to a multi-product platform that includes FigJam, Dev Mode, and most recently, Figma Slides. Having spent the past two years building Dev Mode from the ground up, I’m reminded that building new products is never easy. The process feels messy. It can be chaotic. And often, it’s nonlinear. There’s a myth, especially in tech, that launching new products hinges on committing to a singular vision—and that product builders should be unwavering about where their product is headed. While vision is important, launching a new product also requires careful planning, operational Tetris, and flexibility—listening to users and adapting to feedback, sometimes to the point where you have to pivot your product entirely.

When we first started working on Dev Mode, a tool in Figma that makes it easier to go from design to development, we imagined it as a way to automate design to code. Early versions were promising, but as we heard feedback from users, we found that developers didn’t always find the code useful. Most developers with design systems already have reusable code written for their components, which means they spend more time assembling existing components than generating entirely new code. So, we pivoted. Instead of doubling down on codegen last year, we built Code Connect, a feature that allows developers to customize the code snippets that appear in Dev Mode so they see code from their design system instead of auto-generated CSS. And even today, we’re continuing to iterate on this approach.

This pivot might seem obvious. We had a roadmap, executed on that roadmap, and changed course when we heard meaningful feedback from users. But there were real costs. We delayed launches and frustrated team members who had spent months working towards that original vision. I’m here to tell you that there’s nothing wrong with that.

Great products aren’t derailed by twists and turns; they are defined by them. So many of the products we use started in a very different place than where they are today: Loom began as a network of “expert” friends giving companies product feedback, and they pivoted several times before finally making a breakthrough with their current video recording platform. Slack originally started as a multiplayer online gaming platform called Glitch. These companies weren’t afraid of taking their products in a different direction based on learnings that challenged existing assumptions.

The same is true for us at Figma. Here, we don’t let sunk costs hold us back from changing our minds. We constantly question whether the things we’re building matter and whether they’re actually good, and it’s never too late to course correct. We get deep into the development stages of projects, try things out for ourselves, and sometimes we decide we need to start again because something doesn’t click. When we announced Dev Mode at Config in 2023, we had a roadmap we were excited to execute. Once the beta went live and user feedback started coming in, we realized that it was more important to respond to their feedback than stick to our roadmap. As a result, we launched over 200 fixes and new features in a month.

Don’t get me wrong: Changing course can be incredibly frustrating. But it can also be freeing. The freedom to change your mind, to gather more information—through user research, input from internal dogfooding, or feedback from a beta—will inevitably bring you closer to something that does feel right. It’s less about being attached to a specific outcome and more about arriving at the best outcome for your users.

So as you think about the year ahead, stay open, curious, and just go with it. Maybe you flip the script and try rapid prototyping an idea before in-depth product and design specifications are completed. Maybe you finally make the hard call to go back to square one on a product that just isn’t landing. Maybe you rethink longstanding assumptions that might no longer hold true in the current product climate. Don’t be afraid of leaving your tried and true framework or methodology behind in favor of a more fluid approach—one that can help you decide when to follow the roadmap, and when to go off-road.

We turned six big ideas percolating around the Figma office—written from the perspective of devs, designers, analysts, writers, PMs, card-carrying generalists—and put them on record. Here’s a look at what’s on our minds for 2025.