Product Teams vs Feature Teams in an AI world.
All the way back in 2019, Marty Cagan wrote an article titled "Product vs Feature Teams". If you're building things you should read it in full but right now I want to take a look at how these ideas land as more and more teams are being encouraged to use AI in their daily workflow.
Marty Cagan
The Silicon Valley Product Group (SVPG) have written many very popular books on how to run successful product teams and product focused companies. A common theme across all of their work is that Product, the capital-p function in a business, works best when it's role is to maximize problems-solved rather than product features delivered. This helps empower people and ultimately, so they claim, deliveries more value to end customers. As worthy a goal in 2026 as much as it was in 2019.
The third type of team and how to avoid it.
Before the article gets into full swing, Cagan points out a third type of team:
The most common in terms of sheer numbers are not really product teams at all, they are delivery teams. Also referred to as “dev teams” or “scrum teams” or “engineering teams” and if your company is running something like SAFe, then unfortunately this is you.
Through working with and within many engineering teams, I still think this is the most common team type by absolute numbers. I also think this style of team correlates fairly well with an initial burst of growth followed by a long stagnation.
What's missing in these teams is the process of product itself. These teams, often under the direction of a non-technical leader, are asked to "just build what I tell you". Those leaders have a grand, but often blurry, vision for what they want and teams end up shipping the 60% version of that vision quite quickly.
Once the initial version is shipped it becomes harder and harder to articulate what's missing. As a result, output, judged on the number of new things shipped, shifts to shipping small inconsequential tickets as fast as possible to maximize a metric.
This is likely to happen even more frequently in a world where AI can get you to the 60% version very quickly. Assuming your "scrum team" remains in place, the output here is going to be an increased focus on tickets shipped per week. These teams will still end up stuck in the 60% solution because churning through a backlog of tiny ideas is rarely the path to unique and valuable product.
As much as it ever was, the path to avoiding becoming one of these teams is to champion the value of Product. Someone within the organization needs to believe that there is value in the product management function and that taking the time to discover and refine ideas is worth more than hitting the maximum of tickets shipped per sprint.
Assuming you have no budget for additional people and you're in one of these teams this change can be simulated with some minor changes in process. Many of the AI models available today do an okay job acting as a product manager. They're not going to go and talk to customers on your behalf but with careful prompting you can inject some product consideration into the process.
As it does with Product, this process will take extra effort and intention. All the AI coding assistants I have used are biased towards action and speed to code unless you put them in a mode that slows them down. They may ask the occasional question but by default these are implementation details rather than product consideration.
These changes however, will shift your team into the 'Feature Team' setup rather than the 'Product Team' described in the article. It's still an initial step worth taking as skipping from 'Delivery Team' to 'Product Team' in one change is nearly impossible.
Product Teams, Feature Teams and the Four Risks
When comparing the two main types of Product team, Cagan calls out four specific risks:
Value risk (will people buy it, or choose to use it?)
Usability risk (can users figure out how to use it?)
Feasibility risk (can we build it with the time, skills, and technology we have?)
Business Viability risk (will this solution work for the various dimensions of our business?)
Cagan states that the product manager is most importantly in charge of Value and Viability risk. Usability sits with design and Feasibility sits with engineering. Ideally all working together to solve problems.
What I like about this framework is that it aligns well with the current capabilities, and gaps, in AI tooling.
Feasibility risk has been significantly lowered thanks to AI coding agents. You still need someone in the loop to help make correct decisions but the leverage a team has to maximize time, skill and technology has dramatically increased.
Usability risk is also on its way down thanks to AI. Tools like Google Stitch can increase the leverage of a competent designer dramatically. The path to a viable prototype is now much shorter and design can focus on the small but high impact changes that are so often lost in the time pressures of shipping product.
In the vast majority of cases where you have feature teams, the designer (if there is one) is a graphic designer. It’s not that graphic or visual design is not important, but what’s relevant here is that now there’s a big gap – someone needs to figure out at least the interaction design and hopefully do some user research.
Value risk, and Viability risk still remain outside the remit of AI. That's not to say ChatGPT wouldn't have opinions on whether a feature will sell. There have always been teams that are willing to build on internal opinions and those willing to do the hard work of talking to and understanding their customers.
Similarly, Viability risk is often reduced by saying no to things, something AI is not typically setup to do. While we all have access to a lot more output-per-workday than we did in 2019, we're still limited by the precious resource of time.
If, as most companies are, you're in competition with others, then the value of building only what matters is doubled. If your competitor ships a higher ratio of features that are valuable to your customer then they will start to become the preferred product.
I can foresee a lot of teams landing in the "Feature Team" bucket with an increase in AI tooling. When your designers and developers now seem to have multiplied, product managers in feature teams end up "herding cats" more than ever before. You've suddenly introduced another layer of hierarchy in your teams by turning developers and designers into managers of agents.
The job of the product manager on a feature team is most commonly described as a form of facilitator, “herding the cats” in order to get the feature designed and delivered, or some nebulous and weak form of cross-functional leader that’s not really responsible for anything specific. These feature teams will often think they are doing product discovery, but really it’s just design and maybe a little usability testing.
Looking at the opposite state now, the Empowered Product Leader, how can they thrive in a world full of AI tools?
Firstly, I think a focus on maximizing "problems solved" remains as important as ever. As we see more and more AI related layoffs there is a clear bias towards AI being a tool to maximize efficiency. Teams will end up measured on tokens used per day in much the same way that they were once measured on lines of code committed. If an organization has the foresight to focus on measuring and solving real problems those tokens are going to be far better spent.
I am not advocating by any means for a complete avoidance of efficiency maximization but the goal, and metrics, should be true efficiency gains rather than some loose leading metrics.
An AI equipped product leader should be spending as much of their time refining as they are executing. That means talking to customers, planning out how features should interact and fit into the product and how their success will be measured.
All of these steps can be assisted by AI tools but an Empowered Product team isn't going to assume that whatever training and prompts an off the shelf AI model comes with are a substitution for this work. Forgetting this will result in the sudden launch of thousands of indistinguishable products all generated by similar prompting.
This brings with it a focus on craft and quality over pure output. Customers are fast developing a distaste for rushed, sloppy features pushed out without care or attention. Even in 'boring B2B' there's value in care and attention. I'm yet to meet a company that managed to find product market fit through thousands of A/B tests or by shipping feature after feature until all users were happy.
Being 'Empowered' as Cagan describes it is all about having the ability to choose what you deliver knowing it's in service of solving problems. It takes a certain amount of trust in those teams because seeing results takes longer. These teams will be judged on the ultimate success or failure of their work rather than the speed of their output. This comes with both higher risk and higher reward.
When teams can say "well we shipped all the things quickly, don't blame us" then they decouple themselves from the success of whatever features were shipped. In large or inefficient organizations, this results in long lived zombie-teams that are immune to any scrutiny short of a major organizational restructure. This can be great for job security but is very likely to limit your potential for career growth.
As an AI driven push towards output at all costs lands more companies into the Feature team / Delivery team mindset I'll wrap this up with one last snippet from the original article. As you read it, imagine that 'true product manager' to be the kind that has access to, and mastery of the AI tooling to scale the term Empowered:
It is sad to me that so many designers and engineers have never been exposed to a true product manager, and have never been able to work on a truly empowered team. This is why I argue that there is so much underutilized talent out there, and why I continue to try to persuade people to try working like the best companies do.