Product Transformation Marty Cagan

Preparing For The Future

Note: This article is the written narrative that I prepared prior to a keynote address I gave to the Future Week conference in Norway.  Normally I write about the practices I witness up close with strong product teams, but this article is necessarily a bit different because I need to try to predict where the technologies and trends will lead us to.  So everything in here should be taken with a large grain of salt, but I still think the exercise is useful, as we all should be doing our best to think through the implications and consequences of the technologies we create.

I want to be clear right up front, this article is not going to try to predict all the new types of applications and devices that the new generation of generative AI will enable.  I follow several technology leaders that are all far smarter than I am, and I don’t think anyone knows that today.

Instead, this article is for those of us that will be building the products of the future.

Most AI related content out there is concerned with how to use AI to improve our products and services.  That’s certainly a very fun topic, as literally every day we hear about yet more inspiring examples, and more people are coming to view generative AI as a platform shift.

But the focus of my work is on how we build products.  How that’s already starting to change, what changes I think are coming, and what you can do to prepare.


I suppose my main advantage is that I’ve been working in the heart of the tech industry for more than 40 years, and I’ve lived through several major technology disruptions.

My career began during the introduction of personal computers, and it’s hard to describe to people today just how profound it was to consider the idea of a computer in every home and every office.

Then came distributed computing and high-speed networking, which enabled us to tackle some much tougher problems.

Then the Internet happened, which literally caused companies to revisit nearly everything about how we live and work.  It’s hard to explain to people what it was like, other than to say it felt a lot like things do right now.

There was a tremendous burst of innovation, coming from both startups and large companies.  There were literally dozens of new technologies, scores of new tools, and hundreds of new businesses created every week.  It was very difficult to keep up, often leaving my head spinning.  OpenAI is probably the closest thing today to the role that Netscape played then.

Then mobile computing combined all three of these innovations in a device that fit in our pockets.

I realize that these earlier disruptions can sound somewhat quaint today, just as GPT4 will likely sound quaint in a few years.

But in every case, untold numbers of companies and products were disrupted.

Another thing I’ve learned about disruptive technologies, and I try to always keep in mind, is known as Amara’s law: “We tend to overestimate the effect of a technology in the short run, and underestimate the effect in the long run.”  Maybe generative AI will prove to be an exception, but I doubt it.

In product companies, we live for these disruptive technologies.  They are what allow us to solve long-standing problems in ways we could not have imagined before.


Now if we turn our attention to how we build products, I would argue that it was the Internet that had the most profound impact so far.  

Before the internet, product teams were much larger, took much longer to create products, getting feedback took much longer, and there were fewer iterations.

By pure luck, I was right in the center of the Internet disruption, responsible for the platform and developer tools for the company at the epicenter of the birth of the Internet: Netscape Communications.  

The Internet enabled new models of product discovery, product delivery, distribution and feedback cycles.  

The product teams at Netscape, as well as the growing ecosystem that we were at the center of, were on the front lines experimenting with how we should change how we discover and deliver products, and Agile, customer development, and Lean Startup techniques were born out of what these early teams learned.

So all this begs the question, how will the rise of generative AI impact how we build products?


At one level, generative AI is a new and powerful class of tool.  Sounds straightforward enough, but tools are tricky things.  

As Benedict Evans points out: “There’s an old saying that when we get a new tool, we begin by making it fit the old way of working, and then we change the way we work to fit the new tool.”

I think we’re already seeing clear signs of both.  Both are interesting, but I want to focus my thoughts here on how these technologies will likely change how we work.

Additionally, some tools can be used to create products, and some can be used to run products.  A business model canvas is an example of the first, and AWS is an example of the second.  However, generative AI is a tool that has major applications for both.


The products our company’s sell come from product teams.  Since most products have multiple product teams working on different areas, team topology refers to how we structure those product teams.  

That’s currently one of the most difficult, but most important decisions product leaders need to make.  There are many constraints today that influence the decisions of what the best team topology should be.  

One of the major constraints is referred to as “cognitive load,” which refers to how much can the engineers keep in their heads?  Realize that many products today are literally tens of millions of lines of code, so this is a very real concern.  We do have various ways of abstracting this complexity, but still this is a major factor.

However, primarily because of new AI-powered tools for engineers, the cognitive load is likely to go down, potentially dramatically, which means the scope of what a team is responsible for can increase, again potentially dramatically.

Fewer product teams, with smaller product team sizes, is a big win for companies.  This has a number of very real benefits including improved empowerment, autonomy, communication, coordination, collaboration, and job satisfaction.

Obviously, one possibility is that a company simply reduces the number of product people they need.  We can already see some of this happening.  But historically, over time, companies pursue more products, and more new companies are created, so the industry experiences overall growth. 

There’s no law that says this will continue to happen, but I believe it will.  Although as you’ll see below, it’s never a smooth transition.  There are always casualties.


One of the major drivers of job satisfaction among members of product teams is their level of autonomy.  In practical terms, what this means is how much of what they depend on can they control themselves, versus how much they must depend on others for.  

In most large organizations, it can be very frustrating and disempowering to have to depend on so many other product teams in order to get anything meaningful accomplished.  Even small features can be unreasonably complex due to limited autonomy.

This can be so frustrating that many product teams and product organizations simply avoid working on the most meaningful problems because they just don’t want to deal with the overhead of communication, coordination and dependency management, and the resulting time and cost.

One of the likely major benefits of the new generation of AI-powered tools, especially for engineers, is that product teams will have much higher degrees of autonomy.

In general, product teams work on all sizes of efforts.  From smaller features, to medium sized projects, to big initiatives that impact multiple product teams.

Most companies have always been conflicted about initiatives.  Initiatives often are bets for tackling the most meaningful problems, with the biggest potential for impact.  Yet due to the lack of autonomy, initiatives come with heavy overhead.

One of the big hopes of the new technology is that autonomy increases to the level where a single product team can completely own and deliver not just normal features and projects, but also the larger initiatives. 

As technology absorbs more of the cognitive load for the engineers, and as technology raises the level of experience design for the designers, and as technology frees up product managers from more of the administrative burden – all trends we discuss more below – then product teams can hopefully take on responsibility for more of an end to end experience, with far fewer dependencies.  Hopefully this will allow a product team to tackle a larger initiative with the level of autonomy comparable to what they have today when they take on a new feature. 


Product teams are very much social constructs, based on trust.  They are necessarily cross-functional, and the key to real innovation is collaboration.  

Even before generative AI, many teams found trust difficult to build and to maintain, especially with team members working remotely.

The question is whether the new generation of generative AI tools will find ways to help build trust, or unintentionally contribute to the problem by making it easier for people to retreat into themselves, and interact primarily with AI-based agents, and even less with their cross-functional colleagues. 

This is more nuanced than it sounds because healthy collaboration involves some necessary friction – the ability to disagree and work through many often conflicting goals and constraints.  It is tempting for many people to just avoid the friction.  But the innovation would likely suffer.

Certainly there is the potential for tools to help nurture the necessary trust and collaboration, but given people’s predisposition to avoid these interactions, there’s a real concern that this will hurt rather than help.


This next point has both the greatest potential, but also the greatest risk.  I am simultaneously the most excited, and the most scared about how this will play out.

The new generation of AI-powered tools has the potential to improve our ability to think and reason more than perhaps anything else we’ve ever seen.  

Yet it also has the potential to take over the necessary thinking and judgment, which could seriously damage product teams, as well as society at large.

Product teams are all about solving hard problems in ways that our customers love, yet work for our business.  This requires a cross-functional group of skills to ideate and debate the various tradeoffs.  But mostly it requires thinking and judgment, and in fact one of the most important skills we coach product managers, product designers and engineers on is how to think through these sorts of tough problems.

That said, it is remarkable the extent to which many people will go to in order to avoid thinking.

Just within the past few months of product teams experimenting with ChatGPT, I have seen examples of each.  Examples where the person uses the service to challenge their thinking, to find the best way to articulate an argument, or to summarize existing research.  

Yet I have also seen too many examples where someone gets a response to a prompt, and accepts it blindly without thinking through whether it makes sense, whether it is truly the best course of action, or if the output is even relevant.

It’s hard to emphasize this enough, but if people end up abdicating actual thinking and judgment to these tools, then I fear we are headed in a very bad direction.  If, on the other hand, we ensure that people use these tools to improve the quality of their thinking, it will have been a tremendous contribution.


With the new AI-powered tools that are coming available, it will be easier and faster than ever before to create the artifacts that product teams and product organizations use to communicate and produce products.  

This has the potential to be a significant time saver, and free people up from often tedious and time-consuming work.

However, for many people, especially those that are reluctant to think and do the work, the work becomes about the artifacts, instead of the artifact just being a side-effect of doing the actual work.

As an example, if you’ve done the necessary product discovery work, you will still often need to document your decisions somewhere like a product roadmap, PRD or annotated user stories so that you can communicate these details to the engineers, so they understand the nuances of what needs to be built and tested.  But if you end up doing the artifact instead of the necessary discovery work, then you will be basing the artifact on your guesses, and not on the actual evidence created during the product discovery work. 

The artifact may look the same superficially, but the artifact’s value will not be.


Another area that has both tremendous potential as well as significant risk is the topic of quality assurance.  How do we ensure that our products consistently do the right thing for our customers?

On the one hand, this has always been a very difficult problem for a great many product teams.  One that usually required significant investment in test automation and then ongoing investment in maintaining those (all too fragile) automated tests.  The new generation of AI-based test automation tools has the promise to revolutionize our approach to ensuring the product is behaving properly.

On the other hand, our current approach to quality is largely based on deterministic products.  This means that given a set of inputs we can predict what the appropriate output should be, and we can count on that being true indefinitely.  

Yet for many new products built on generative AI, our products are no longer deterministic, but rather probabilistic.  We can no longer count on the same inputs generating the same outputs.  For many contexts, this is not a problem.  But for other contexts, especially when safety is involved, this will require different approaches to ensure appropriate behavior.


Let’s now look at the impact of AI technologies on the specific roles themselves, starting with engineers.

The tools that engineers use to build, test and deploy products have been continuously improving since the profession was first created more than half a century ago.

That said, the new generation of AI-based tools represent a dramatic leap forward in capability, to the degree that it truly is changing the shape of product teams.

Will some engineers be rendered obsolete going forward?  Certainly, just as some lower level designers and lower level product managers will.  But it’s likely that this will primarily be a function of the level of engineering.  Software that’s been done countless times, such as moving an application from iOS to Android, will almost certainly be dramatically aided by tools.  Yet coming up with a software architecture that reflects the unique needs of the organization, the product vision, and the legacy systems, will likely be less so.  

I am most definitely hoping and expecting that this will lead to the end for traditional engineering outsourcing.

But perhaps counterintuitively, I am expecting this to mark the beginning of a golden era of engineering.

As someone that started as an engineer during the days of lower-level programming languages where we operated very close to the level of the machine, and then experiencing the liberation and step function increases in productivity that came with progressively raising the level of abstraction, the promise of the new generation of tools is to enable ordinary engineers to have the sorts of superpowers associated with so-called “10X engineers.”

This both reduces the necessary size of teams, and also increases the scope of what a team can be responsible for.  

I’m optimistic that we’ll see empowerment, autonomy, impact, and job satisfaction all rise.

I know that many are concerned about whether we’ll still need engineers.  But my expectation is that while on a per-team basis the number will drop, on a per-company and especially on an industry basis, the number will rise.

It’s also important to acknowledge that just as with every disruptive technology, there will be some engineers that embrace learning the new – many already are – but others will avoid change as long as possible.

Strong engineers know that learning new technologies is right at the heart of their responsibilities and their contributions.  In fact, determining whether an engineer is genuinely eager to learn new technologies is among the most important goals of an interview.

There are many engineers wondering today if they need to become expert in creating models, or in training those models.  While I do think that’s the case for certain companies, for the vast majority of cases, as with other disruptive enabling technologies, most engineers will need to become capable in how to utilize the models, but won’t have to know the nuances of creating or training them.  Much as with enabling technologies such as AWS, strong engineers can be expert in utilizing the services, without needing expertise in how those services were built or run.

We have already seen the specific engineering skill sets evolve to include more machine learning, data science and data engineering, and we can expect this to continue.


When we refer to product designers we’re talking about designers skilled at a range of design disciplines, from service design to interaction design to visual design.  

Today, there are many designers that are skilled in visual design, but not in interaction or service design.  For several years I have been encouraging this group to raise their skill level because of automation and tooling already disrupting the visual design job.  With the new generation of design tools, this is all but certain.  In fact, layoffs due to the new generation of design tools have already started to impact this group.

On the other hand, for those product designers skilled at service and interaction design, their skills are more important than ever, especially as the new generation of technology is exposing technology in ways that are new and in many cases unfamiliar to users, so the product designer role needs to be front and center.

So while the need will be for skilled product designers able to craft strong end-to-end user experiences, I am expecting that these people will be more in demand than ever.


For this discussion it really is critical to distinguish between the product manager role on an empowered product team, versus a product manager role on a feature team, versus an Agile product owner role on a delivery team.

Because those three definitions of product management are so different, the implications are also very different.

I have written about this in much more detail elsewhere, but for the purposes of this discussion, a product manager for an empowered product team is primarily responsible for the value and viability of the solutions the team creates.  

A product manager for a feature team is primarily a program/project manager responsible for getting roadmap items designed, built and delivered.

An Agile product owner is primarily an administrative role responsible for the product backlog.

For feature team product managers, and especially for administrative product owners, I will be surprised if the new generation of tools does not seriously disrupt those roles.  

Personally, I consider that a good thing, as these are not roles that I consider worthy of the minds of the people that serve in those roles.  

That said, if I’m right then a lot of product people may find themselves at least temporarily out of a job, which can disrupt their lives and their families, so I say this in the spirit of encouraging people to start preparing for this possibility sooner rather than later.

On the other hand, if you’re a product manager on an empowered product team, then your role is likely to become more critical rather than less.  I do think the execution elements will be significantly reduced, but most product managers I know will be very grateful for that.  And they’ll need every available ounce of mental energy to deal with the value and viability questions.  More on this below.

But for those product managers of empowered product teams, the time spent creating artifacts such as written narratives, roadmaps, PRD’s, and acceptance criteria, as just a few examples, should be significantly assisted by the new generation of tools, some of which are already starting to appear.  Even at the very rudimentary level, if the new generation of tools can significantly reduce the time a product manager (or engineer) spends dealing with tools like Jira, that will be a substantial win.


This final point is, I think, the most important.

It is very easy to get caught up in the genuinely amazing things that we are now capable of building.  Many of us entered this career because we hoped to leverage technology to improve the world in some small way.

Yet over the past decade we have seen too many examples of serious ethical misses and lapses, even for products using conventional technologies.

Today I have to reluctantly admit that I know of many companies that simply can’t or shouldn’t be trusted to do the right thing.  Evil really does exist in the world, but I think the even larger issue is that there are simply too many examples of “let’s build this cool thing first, then maybe consider ethics later.”  An example of this is not paying enough attention to bias in our training data.

I’m still genuinely optimistic about the benefits of these new enabling technologies, but I’m just as concerned about the dangers.

Product teams are on the front lines of developing these new products and services, so we need to take a more proactive role in detecting and preventing negative consequences to people, to society and to the environment.

But there is some good news in terms of ethics and AI: at least we no longer have to worry about the ethical and environmental disaster which was crypto.


Three final points to leave you with.  

First, as Shreyas Doshi says, “The best way to prepare yourself for the future is to invest in your empathy, thinking, and creativity.”

Second, as Dr. Marily Nika says, “Don’t do AI for the sake of doing AI.  Make sure there is a problem there. Make sure there is a pain point that needs to be solved in a smart way.

Third, please keep in mind that it’s still very early in terms of the impact of generative AI, and also in terms of the development of generative AI.  Some things we can predict with reasonable confidence, but please always keep in mind the first principle of product: “know what you can’t know.” 

We can’t know what the future will bring.  What we can do is prepare ourselves as best we can, and work to learn the new emerging technologies, and constantly consider how we might utilize the new technologies to help our customers.

Those that can quickly learn and apply new technologies, those that have genuine empathy for users and customers, and those with the judgment and ability to think through hard problems have always done well in prior technology disruptions, and I’m betting they will once again.

Special thanks to Chris Jones, Dr. Marily Nika and Shreyas Doshi for their thoughts on early drafts of this article.