Why the AI era demands a barbell approach to product development

Written by
Craig Watson
May 11, 2026
In this article

Before AI, engineering resources were the primary constraint that product managers and designers faced every day. Engineers were expensive, and engineering resources were non-fungible; teams had to be judicious about where to allocate them.Β 

PMs and designers were often backed into an intermediary role, working as interfaces between engineering teams and the product. You’d thoroughly validate a problem, write a spec that would sit in a backlog for six weeks, and wait.Β 

Now, with AI, PMs and designers can directly manipulate the product surface rather than operate at the coordination layer, where engineering resources limit them. PMs and designers can operate at the execution layer alongside engineers.

With engineering resources shifting from scarce to plentiful, we see the next constraints emerging: Decision quality and taste. Enter the barbell framework – a new approach to product development that helps us focus on the right things.Β 

The barbell framework

Traditionally, PMs define problems and priorities, and designers work closely with them to explore those problems and validate potential solutions. Engineers step in to bring validated solutions to life, but there are rarely enough engineering resources to go around.Β 

The need to translate ideas into production-ready code often limits PMs and designers to whatever engineering bandwidth is available, slowing down iteration and learning. If you plotted the amount of work possible, you’d see something like a bell curve, with most of the work happening in the middle because engineering is too constrained to accommodate more work from either side.

Synthesia is flipping this model and shifting to a barbell framework, where more work happens at the beginning and end, with AI taking on most of the work in the middle – especially the raw coding.Β 

On one end of the barbell, we encourage more exploration and experimentation, and more teams trying to rapidly solve the same problems from different angles. Rapid prototyping gets even faster now that it’s accelerated by AI, and the breadth of exploration expands as PMs generate more ideas in less time.Β 

On the other end, we need more discernment about what gets shipped. The emphasis is on high agency and owning the problem. User validation, polish, edge-case coverage, and distribution all support this end of the barbell.Β 

With AI, the ability to turn ideas into production-grade systems is compressed, not eliminated. You also need strong convergence mechanisms to ensure that increases in output at either end don’t just lead to noise.Β 

We don’t want to get stuck in scarcity

Given limited engineering resources, organizations tended – before AI – to optimize prematurely and ship too quickly, then move on to the next thing. If you visualize the barbell, this is fixating on the middle while losing sight of the ends.Β 

Until now, this middle zone held an inevitable gravitational pull because engineering resources were genuinely scarce. That often meant reaching, say, 80% polish and moving on to the next feature. There were diminishing returns to pursuing perfection and caring about craftsmanship. It often made more sense to spend just enough engineering resources to ship.Β 

If you treat AI only as an accelerant, you’ll just speed up old processes, leading to incremental gains. The bigger gains are only possible through process changes that give more people ownership and agency and, in particular, allow PMs and designers to work with fewer limitations.

The irony is that, counter to what you might hear, AI has the potential to enable more attention paid to craftsmanship and quality. When the speed of development is faster, engineering resources, or lack thereof, can’t be an excuse for leaving flaws on the table. Similarly, as the cost of exploring ideas in code drops dramatically, PMs and designers can explore, test, and experiment more than ever before.Β 

Taste is then the next constraint: AI commoditizes execution, so taste and judgment become the bottleneck.Β 

PMs have to be able to kill ideas, not just prioritize them. In the same way writers have to β€œkill their darlings,” good PMs have to have the discipline to kill ideas that are merely buildable. There’s a commitment to real user conversations that has to be maintained, even as iteration speed makes that work feel unnecessary. It’s as much about stewardship and ownership as it is about execution.Β 

Similarly, designers need to push the quality bar high and keep it high even as our pace increases. Designers become responsible for interaction consistency across fast-moving surfaces, and they own the states most likely to be overlooked. They need the judgment to slow down a decision to ship when the details aren't right.Β 

As a result, rigid, linear roadmaps fall by the wayside, and option portfolios replace them. We cohere our efforts around bets, taking smart gambles on which features to work on next. When it becomes trivial to generate ten viable solutions, the hard part is choosing the one worth committing to and quickly killing the other nine.

To be clear, it’s not all sunshine and rainbows. AI creates local abundance but global complexity, meaning engineers, designers, and PMs are all more productive within their domains, which means it’s harder to make all those efforts cohere.Β 

Three ways the barbell framework changes how we work

The barbell framework is working for us so far, but we’re still iterating and still finding new ways it changes how we work. To get more concrete, here are three ways our approach has changed as a result of this shift in thinking.Β 

Parallelized teams find more creative solutions

When engineering resources are limited, you have to carefully make a plan of attack and execute diligently.Β 

If you’re going to expend three months of a team’s work, you’re incentivized to plan and plan, and then stick to the plan. Rigidity is an emergent property of scarcity. Once you can work much faster, it pays off to have multiple teams working rapidly rather than one team working slowly.Β 

For example, we were recently building out our AI assistant – a complex feature that integrated with numerous legacy systems. It was tricky, and one team was stuck on it for a few months. Then, two other engineers got together after the Christmas break, broke it down to first principles, and came up with a new angle. We re-architected the entire feature using this new approach and completed it faster and better.

With this level of parallelization, we can then amplify both ends of the barbell by testing more hypotheses at one end and obtaining more validation and falsification at the other. Experimentation and feedback both rise, and our teams, because they don’t need to sink too much effort into any given approach, are less prone to the sunk cost fallacy and less likely to overcommit to one way of looking at a problem.

More people can work across the stack

At Synthesia, two of our key working principles have always been agency and ownership. Since our founding, we’ve always emphasized giving our employees autonomy over their work while encouraging them to own the problem, solution, and process.

But theory was often limited by reality. When engineering resources were a constraint, we could only expect PMs and designers to own the problem to a limited degree. Now, with AI, we can enable higher levels of agency and ownership than were possible before. PMs and designers can own the problem from ideation to the pixels shipped.

Again, this doesn’t mean development is suddenly without friction. We still have to do the hard work of understanding who we’re building for and why, or else we’re just building faster for no one. But with AI, many of our features can now be feasibility-led, with PMs and designers rapidly and autonomously prototyping. More people can work across the stack and through the product development cycle, allowing for more agency across the company.

For example, last year, a product manager was working on new learning features. As they tested ideas in the market to understand how they would resonate, what we thought was a side featureβ€”our Skills offeringβ€”started to stand out to customers. Because they wanted it even more than we anticipated, we pivoted, and now, Skills is showing strong early traction alongside Courses.Β 

There’s also a critical input problem: This model only works if we have PMs and designers who operate with builder-level agency. Thankfully, our current crop of PMs and designers is fantastic, but we need to both encourage more people to apply while filtering for those willing (and excited!) to take on this level of autonomy.Β 

More feedback speeds up iteration

Given high-agency PMs and designers working alongside strong engineers, we often face more feedback constraints than engineering constraints. We’re addressing the right problems with the right people supported by a resource surplus, but if we don’t have enough feedback, we can build more and more, but in the wrong direction.Β 

Because of that, we focus on decision speed and feedback, encouraging PMs and designers to make decisions fast, iterate quickly, and spin up new ideas rather than build consensus for them first. If we’re waiting for everyone to agree on an idea before building it, feedback is always delayed. If we embrace the speed, we can make decisions faster (knowing we can just as quickly unwind them) and iterate in faster bursts once we get that feedback.Β 

Feedback is so critical that when we can, we dogfood the product to get it sooner. We were building a sales enablement tool, for example, and because we have a big sales team at Synthesia, we were able to test it internally. We ran observation studies in the office two to three times a week to get the production front of our sales team, let them test it, and incorporate their feedback. With AI, we can see what’s working in real time, tweak it that evening, and ready it for another day of testing.Β 

Standing still is falling behind

Much attention has been given to how AI will affect engineers, but the downstream impact on PMs and designers will matter even more. At Synthesia, we want to be at the forefront of this change, not waiting for it.Β 

If you’re a PM, that means you will prototype and be judged on the speed of your validation and invalidation.

If you’re a designer, you will operate at a higher volume, and your taste will become a source of leverage.Β 

As PMs, designers, and engineers work together, there will be fewer handoffs and less friction. More people in each role will need to be full-stack, and the roles between boundaries will have to be less rigid.Β 

If you’re excited about this kind of work, check out our open positions here.Β 

Craig Watson

Craig Watson is VP of Product at Synthesia, where he leads the development of AI-powered video products used by leading global enterprises.

Go to author's profile
Get started

Make videos with AI avatars in 160+ languages

VIDEO TEMPLATE