A Vision For Product Teams

In this article, I want to talk about where I believe generative AI is going to take the roles on a product team, and the team topologies of product organizations.

I’m motivated to write this both because I think a vision of where we should try to go is important, and also because I see so many people spouting so much of what I consider nonsense on this topic.

I see so much confusion and angst out there, with some people with their heads in the sand, arguing (praying) that nothing substantial will change, and others predicting the end of product managers, designers and engineers.

So I think it’s an important topic to discuss, but it’s also a sensitive topic.  While I’ve been working on these concepts for a while, I’ve been hesitant to publish this because of two reasons:

First, trying to predict the future based on newly emerging technology is at best difficult, at worst ill-advised.

Second, we are talking about something very personal and emotional – the lives and careers of the people on product teams.  If I’m right, then some people will end up as big winners, but many people will have their lives disrupted, probably either being forced to upskill, and/or losing their jobs.

I worry there is a very real danger of being perceived as making light of the disruption to people’s lives.  I’m also concerned about the subset of people out there that are prone to overreacting (freaking out) to the possibility of the potential future I’m about to describe.

But I also believe that with disruptive technology, it is better to lean in rather than away, and work to help take the technology in a better direction, even when it is uncomfortable.

But to be clear, I absolutely believe significant disruption is coming whether I write about this or not – in this case, mainly to countless product owners, product managers, product designers and engineers.

Timeframe

When I talk vision, I’m talking about something like a 3-10 year timeframe.

What I’m about to describe is not something that’s possible today, but it’s also not something that I consider beyond the reach of current enabling technology.

But it’s also important to point out that this is explicitly not trying to address what product teams will look like beyond this 10 year timeframe.  There are just too many unknowns and moving pieces at this point to be useful.

Discovery vs Delivery

When we look at the roles on a product team, there are two important overarching responsibilities of each member of the product team:

We need to understand the problem we’ve been asked to solve, and figure out a good solution (product discovery), and then we need to build, test and deploy that solution to our customers (product delivery).

Everything in product has some amount of judgement, and some amount of process, but product discovery is primarily about judgement, and product delivery is much more about process.

Most of the newly emerging tools focus on product delivery.  Helping product managers create artifacts such as PRD’s.   Helping designers with design assets, wireframes and comps.  And especially helping engineers with coding, testing and deployment.

That said, there are also new tools helping with product discovery.  Anything that helps us understand the market and our customers, and quickly and safely flesh out ideas and test them with users, buyers and stakeholders, and then rapidly iterate, is all to the good.  I’ll discuss this more in a future article.

The Main Confusion

The root issue that I believe is causing the most angst and confusion is that just because new tools can define requirements, design experiences, and write code, does not mean that anyone with an idea will be able to produce a successful product.

Steve Jobs referred to this as “the disease of thinking that a really great idea is 90% of the work.”

So many people are seeing the new tools that automate these tasks, and thinking that means we no longer need product managers, product designers, or engineers.

But the question is not whether the tools can automate tasks; the question is whether this will create successful products?

Many people think that the new tools will mean that anyone could cover any of these roles.  

For example, a technically-inclined product manager could cover the engineering and design responsibilities, or a business-inclined engineer could cover the product responsibilities.

Or, the extreme version of this, where anyone with an idea will be able to serve as a so-called “solopreneur” and use gen ai-based tools to design and build everything themselves.

Single person startups have always existed in the past, and will continue to exist in the future, (and I do know a handful of true “triple threat” people that I consider deeply skilled in all three), but I expect these people to continue to be the rare exceptions and not the rule.

Realize that we have had no-code and low-code user programming tools for several years.  And we have also known that design tools can be learned and used by product managers and engineers alike.  Yet the results are rarely what anyone was hoping for.  As always, it’s not the tool; it’s what you choose to do with that tool.

The majority of the people that believe all these roles are about to be automated are just telling me that they are not yet aware of what they don’t know.  

Due to human nature (thinking that everyone else’s job is much easier than theirs), this has always been a problem, and probably will always be a problem.

Increases in Productivity

As of this writing, the current generative AI-based tools are helping to improve the productivity of engineers by something in the range of 20-30%.  ¹

In terms of historical comparisons, this is actually very significant.  But in practice, it means that where you might have had 8 engineers on a product team, now you might have 5 or 6.

I’m already starting to see average team sizes go down due to the improved productivity, especially developer productivity, and as most people know, there are additional benefits that come along with reduced team sizes.

And I’m just starting to see similar benefits impact designers.

But as is often the case, it’s a mixed bag with product managers: 

For product owners and feature team product managers, where the job is primarily about delivery, and driven by a delivery process, it seems pretty clear to me that there will be very substantial productivity improvements, if not full automation.  And yes, as I’ve written elsewhere, I consider these roles (product owners, and feature team product managers) as very vulnerable in this timeframe, and I’ve been strongly encouraging my friends in this situation to upskill to better protect themselves.

Thinking vs Executing

I am most interested in the question of what is the optimal blend of human judgement and thinking (aka product sense), and technology-powered tools, to yield the best outcomes?

Recently Tim O’Reilly published The End of Programming as We Know It, which explores precisely this topic as it pertains to engineers.

Among many excellent points, he includes a quote from (Ms.) Chip Huyen, the author of the newly released book AI Engineering. “I don’t think AI introduces a new kind of thinking. It reveals what actually requires thinking.”

I think she is exactly right.  Most jobs involve some blend of judgement and process, and the process aspects are prime targets for the tools.  What remains is the judgement.  For a description of this judgement as it pertains to product managers, see the article AI Product Management.

As Delivery Time Approaches Zero

If today the average team size is reducing by maybe 20-30%, what do we expect in the next several years?

I’m expecting that the productivity of delivery will continue to improve, in many cases to the point where a well-defined solution can be built, tested and deployed as a production-quality product, for all intents and purposes, nearly instantaneously.

At this point we would have product teams that spend almost all of their time on product discovery (deciding on the solution that best solves the problem, or improves the outcomes).

The Discovery Trio Becomes The Product Team

I believe that what will happen (again, in the 3-10 year timeframe) is that product discovery will become the main activity of product teams, and gen ai-based tools will automate most of the delivery.

Further, I argue that the critical competencies needed will continue to be distinct enough, and deep enough, that in most cases, product teams will need a product manager to solve for the many business constraints, a product designer to solve for the user experience, and an engineer to solve for the technology.

For products that are not designed for human use², as with today, this discovery work will likely be done by a platform product manager and a platform engineer.

Impact to Staffing

So if I’m right, over the next 3-10 years we’ll continue to see the average product team drop from something like 8 people (6 engineers, a product manager and a product designer), down to 3 (a product manager, a product designer, and an engineer).

This would of course be disruptive to many people, but it also would represent a dramatic cost savings to the company.

But wait, there’s more. This is just one of two dimensions to this discussion.

Impact to Team Topology 

Thus far, we’ve been discussing the size and composition of the product team.

However, there is another major benefit from the new generation of tools that have even more profound consequences, that go beyond efficiency or productivity, which is the scope of the product team.

Today the scope of a product team is driven by a number of factors, including the expertise in specific technologies, and the cognitive load on the product manager, the product designer, and especially the engineers.

In most current team topologies, one of the primary limiting factors driving reduced sense of autonomy, and overall frustration, is that it so often requires multiple product teams coordinating in order to solve even straightforward problems.  That’s because each product team is responsible for only a relatively small subset of the overall product or system.

One of the most profound consequences of the new class of tools will be the ability for a given product team to have a much broader scope of responsibility, in large part due to tools providing assisted cognitive load.³

Impact to Company Economics

For a medium-sized product company, say a scale-up currently with 15-20 product teams, with an average of 8 people each (120-160 total product people), this could mean reducing to something like 3-5 product teams, with an average of 3 people each (9-15 people).

If we assume $100K for an average product employee, with a roughly $200K loaded cost, then an 8-person team costs the company about $1.6M/year, so roughly $24M/year total for 15 teams (not even counting the managers and supporting roles).  Ultimately, this could drop all the way down to $1.8M/year total (plus proportionately fewer managers and supporting roles).

What About All These People No Longer Needed?

Many people like to cite the historical view that because the costs go down, companies will pursue more products, and/or more ambitious versions of their current products.

While I certainly hope this will prove true, it’s hard for me to imagine a scenario where the level of increased investment even comes close to offsetting the level of reductions.

However, another lens on this is that now the “table stakes” costs to run a tech product organization would be dramatically lower.  

How many more startups and scaleups would be created when the cost to build and run the technology has reduced this much?

I meet so many startups that are failing because they literally do not have the funds to even cover “table stakes.”  Or even if they do have the funds, they struggle to find enough people with the necessary skills.

It is possible that this vision could enable an explosion of innovation and startups unlike anything our industry has ever experienced.  While admittedly this is still optimistic, I think this possibility is much more realistic.

For those of you that might be feeling secure in your current company, with your current products and customers, realize that this would likely mean a tidal wave of innovative competition coming after you and your customers.

Consequences of Vision 

I’m the first to admit that I could be wrong about all of this, but I genuinely believe that this vision for product teams is not only possible, but I think it’s probable (within 10 years).

But it’s important to acknowledge that there would be both benefits and drawbacks if this were to become a reality.

The benefits include product teams that more consistently generate improved outcomes and innovation, have much greater autonomy and speed, and most importantly for the people involved, increased job satisfaction.

The drawbacks are that if this vision becomes a reality, there will be a dramatic disruption to much of the tech workforce.  There will be many people in largely process-oriented roles where their position is no longer necessary.  There will be many more people that will be forced to either upskill, or to change careers.  

Finally, while I believe the roles in the product trio will be more desirable than ever, I also believe it will take more effort to build the skills and knowledge to obtain these roles.

I have long advocated product vision as a powerful tool for thinking through the future you are trying to create.  I’m hoping that this vision, not of a product but of the product teams we use to create our products, can serve as a useful step towards thinking through the future we all want to create.

1. Although there is some dispute about the impact to quality.  But I consider this just a bump in the road as these tools are still very new.
   ↩︎
2. A related but distinct discussion is what will happen to the architecture of the products we build as users evolve from just being humans, to in many cases, being agents.  But in this case, I’m expecting the design of these programmatic interfaces to be driven by the engineering tech lead rather than a product designer.
   ↩︎
3. If anyone knows of an existing term for this concept please let me know, as I don’t have any desire to introduce nomenclature, but for lack of a better phrase, I’ve been using the term assisted cognitive load for the class of tools that help make it possible for product teams to grok much larger problem and solution spaces.  More on this important concept in a future article.
   ↩︎