The future of product teams: Product Trio, Agile and the role of artificial intelligence

Entry:Teams creating digital products have come a long way – from the era of individual „webmasters”, through formalized waterfall processes, to agile Agile and Scrum methods. Today we stand on the threshold of another transformation. ModelProduct Trio– i.e. close cooperation between a product manager, a UX designer and a technology leader – is gaining popularity as a way to better manage product development. At the same time, the dynamic development of artificial intelligence (AI) is changing the way teams work: from the automation of tedious tasks to the creation of completely new roles. In this article, we analyze how product management has changed (from Waterfall to Agile), what the Product Trio concept is and what benefits it offers to companies such as Google, Spotify or Atlassian, as well as how AI can influence the future of development teams. We present current data from industry reports, examples from practice and potential scenarios for the future.

From Waterfall to Agile – the evolution of product management

ApproachWaterfall (cascading)is based on sequential project planning: first full requirements specification, then design, implementation, testing and implementation. This model assumed stable requirements and one-time delivery of the product. In practice, however, Waterfall’s lack of flexibility resulted in frequent failure to meet business expectations as well as delays and budget overruns. According to classic research by the Standish Group, traditional IT projects had a low percentage of complete successes – only about 31% were successful and 19% were failures (the rest were problematic or partially successful projects).¹. More recent analyzes confirm the challenges of the cascade model: only14% of Waterfall projects are successful without any major problems, while for agile methodologies this percentage reaches42%². Differences can also be seen in the failure statistics –as many as 29% of traditionally conducted projects end in failure, compared to just9% of projects based on Agile³. In short, agile projects are much more likely to achieve their intended goals.

MethodsAgile(e.g. Scrum) proposed a radical change in the product management philosophy. Instead of a detailed plan for years – an iterative approach and frequent delivery of working product increments. Agile teams existcross-functional(multidisciplinary) and self-managing. This means that one team includes all the necessary specialists (e.g. developers, testers, UX designers, DevOps specialists) cooperating on equal terms⁴. This allows the team to deliver value in every sprint without dependence on external departments. In comparison, in the Waterfall approach, the roles were strongly separated – first, analysts and business defined the requirements, then programmers wrote the code, and finally testers verified the product in a separate stage. This often led to the so-called the „throwing over the wall” effectthrow over the wall), where the lack of ongoing cooperation resulted in the product being mismatched to the users’ needs.

Data from practiceconfirm the superiority of the agile approach in many dimensions. In addition to the above-mentioned higher project success rates, companies point to tangible benefits of Agile: the ability to respond to changes in priorities (confirmed by 70% of surveyed teams), greater transparency of progress for stakeholders (65%) and better alignment of development with business goals (65%)⁵. It is therefore not surprising that Agile has become the new standard for managing technology projects, according to research71% of companies (USA) have implemented Agile as their main project management methodology, most of the teams work based on Scrum⁶. The waterfall methodology in its pure form is today used marginally, mainly in projects with unchanged requirements (e.g. in regulated industries). Overall, the transition from Waterfall to Agile represented a cultural shift:from planning and control to experimentation and adaptation, with a greater focus on cross-departmental collaboration and delivering customer value in short cycles.

(Table 1 shows the key differences between the traditional Waterfall approach and Agile methodologies based on reporting data.)

Source:own study based on data from reportsflowlu.comand Scrum Guide.

Traditional model vs. Product Trio – structure of roles and responsibilities

In traditional IT project management models (like Waterfall, but also in many organizations before the agile transformation) there was a clear division of responsibility. The project was led byproject manager(PM), who was responsible for the schedule and budget. In the analysis phasebusiness analystscollected requirements from stakeholders, often preparing extensive documents. Developers implemented strictly defined specifications, and thentesterschecked compliance with the requirements. The product manager (if he existed in the structure) was separated from the daily work of the team – he rather played the role of defining the high-level vision, which was then passed on to other departments for implementation. This arrangement meant that responsibility for the final success of the product was dispersed: everyone focused on „their own stage” of work, and there was no common owner of the value provided to the user. Product decisions were often made in a committee or hierarchical manner – e.g. by a steering committee – which lengthened the feedback loop.

Product Trioproposes a different approach to the division of roles. Instead of sequentially passing the baton between departments, a small, interdisciplinary team of product leaders emerges whotogethermanage the work from idea to implementation. The product trio usually includes:Product Manager (product manager), responsible for business purpose and user value;UX Designer (experience designer), taking care of usability and design aspects; andLead Developer/Engineering Manager (technology leader), responsible for feasibility and technical quality^{12 13}. The key feature of the trio model issharing product responsibility– all three of them make the most important decisions together and cooperate in discovering solutions. There is no room for „business vs. IT” silos or tug-of-war between departments.

Importantly,each member of the Product Trio is jointly responsible for all key aspects of the product– from desirable by users, through business profitability (viable), technical feasibility (feasible), to usability and ethics of the solution^{14 15}. At first glance, it may seem that an engineer should only worry about feasibility and a designer should only worry about interface usability. However, Teresa Torres, a propagator of the Product Trio idea, argues that the division of risks by roles leads to conflicting priorities and hinders cooperation.^{16 17}. If e.g.Justthe engineer looks at the technical aspect, aJustdesigner on usability, a conflict may arise (e.g. maximally usable design may be technologically difficult). In the trio model, all three must find a solution togetherconnectsperspectives – everyone brings their own expertise, but they make decisions together, looking for balance¹⁸. In other words,together, the trio bears full responsibility for the product’s success.

In the traditional arrangement, responsibilities were divided: „the analyst prepared the requirements – I just coded.” In Product Trio, this approach does not work – everyone feels equally the owner of the product and is responsible to the customer and the business for the result. This is a fundamental change in work culture. Eliminating „shifting responsibility” means that decisions are made faster (because they do not require escalation) and are better thought out in many aspects. Observations also show that the trio builds greater trust in the team – members learn each other’s perspectives and language, which reduces the risk of misunderstandings. This model fits into the philosophyempowered teams(teams with high autonomy), where instead of top-down management of microtasks, the focus is on communicating the product’s goal to people and trusting that, as a team, they will find the best way to achieve this goal.

What is the Product Trio concept – definition and benefits

Product Triothat’s basically ita miniature product team in a nutshell. The term was popularized by Teresa Torres in the context of an approach to continuous product discovery (Continuous Discovery). In Torres’ definition“product trio is a cross-functional product team responsible for bothdeciding what to build, as well as forbuilding it„¹⁹. In other words, the trio includes people from three key areas (business, user experience, technology) who together lead both phasesdiscovery product(searching for solutions, testing ideas) and cooperate with the rest of the team ondelivery(implementing solutions). It is important that the trio is not a separate entity –is part of a broader development teamresponsible for building the product²⁰. Unlike the old structures, where, for example, the analysis department could work independently of developers, the product trioembeds product decision-making within the development teamsoftware. This ensures a close coupling of discovery and delivery – ideas are verified on an ongoing basis with prototypes, and feedback from users quickly translates into changes in development.

Crucialroles in a trio– product manager, UX designer and engineering leader – ensurebalanced lookto the problem²¹. The PM ensures that the developed functionalities bring business value and solve the right user problems; UX Designer ensures that the solution is useful, intuitive and attractive to the recipient; Tech Lead guarantees the technical feasibility of ideas and high quality of implementation. Thanks to this, the risk of the so-calledblind spots(blind spots) is decreasing – it is more difficult to come up with an idea that is great in terms of business but terrible in terms of UX, or vice versa, a beautiful project that has no basis in technical realities.Small trio size(only three people) is not a coincidence – the smaller the group, the easier communication and faster decisions. The trio can discuss and decide efficiently, instead of bouncing the ball between numerous teams or waiting for management’s approval. As Torres writes, the goal is to have a trio“represented balanced perspectives while remaining small enough to enhance collaborative decision-making” ²².

Benefits of the Product Trio modelare revealed on several levels:

• Faster and better product decisions:Without the need to escalate decisions through the hierarchy or organize large committees, the trio can quickly agree on a course of action. These decisions are also of high quality because they immediately take into account various points of view (business, utility, technical). The traditional approach often lacked such integration – e.g. the IT department implemented something that marketing came up with, but it was not consulted with UX and resulted in poor user reception.
• Better product fit to market needs:The trio is intensively involved in the discovery phase – talking to users, testing prototypes, analyzing data – thanks to which they have a deep insight into the problems and needs of recipients. This allows you to build functionalities that actually address real needs, instead of relying on assumptions from the beginning of the project. Marty Cagan (SVPG expert) emphasizes thatempowered product teamswith a strong involvement of PM, design and engineering in discovery achieve better results than „feature factories” implementing specifications detached from context²³.
• Increasing team engagement and satisfaction:When team members feel a real influence on the shape of the product, their motivation increases. Instead of following top-down orders, they co-create the vision and see the meaning of their work. The study yielded interesting resultsContinuous Discovery Habits Benchmark– in the 2022 and 2024 editionspeople working in the product trio model reported significantly higher satisfaction with the work of the team and the company(this was one of the strongest trends in the study)²⁴. Running a product together integrates the team and gives a sense of agency, which translates into a better atmosphere and lower employee turnover.

Of course, implementing Product Trio requires changes – e.g. from senior managers – who must trust the teams and give them some decision-making control. It is also necessary to specify the scope of responsibilities of the trio versus the rest of the team (e.g. developers outside the trio, data analysts, etc.) so that everyone knows how to cooperate. However, more and more organizations realize that investing in such a model pays off. Let’s take a look at how Product Trio works in practice using the example of well-known technology companies.

Transforming teams with Product Trio – company experiences

The Product Trio model is not a purely theoretical concept – technology industry leaders have been using similar approaches for years, adapting them to their own organizational cultures.Googlehas long been known for its product triads. As former Google employee Itamar Gilad recalls, in this companyeach product team was led by a triad: PM + tech lead + UX designer, sometimes called „trio”²⁵. These three team leaders jointly set quarterly goals, decided which ideas to prototype first, etc., working by consensus.²⁶. Moreover, the trio structure at Google was replicated at higher levels – several product teams reported to the trio of product, technology and design managers (directors), who in turn reported to the vice presidents forming the trio at the top of the product organization²⁷. Yesmatrix triad structureensured consistency of decisions and balance of perspectives at all levels – from strategic vision to day-to-day tactics. Gilad emphasizes that the trio model at Google helped to include all points of view in decisions:technology leaderbrought an engineering perspective,UX designer– user’s gaze, aPM– knowledge about the market and business²⁸. Thanks to this, the product had a chance to be technically feasible, attractive to the user and meet business goals. Of course, even a trio does not eliminate all tensions – success depends on people’s attitude. Gilad notes that where the trio’s managers respected each other and were able to compromise disputes „for the good of the product,” the model worked great; in cases where one force tried to dominate (e.g. the head of design pushed for the centralization of designers outside the teams), challenges appeared. Nevertheless, Google is often cited as an example of an organization where„three-legged stool”PM-UX-Engineering is the foundation of product culture.

Product management structure in the trio model – from the level of a single team, through product groups, to the highest level of the product organization. Each level is managed jointly by a trio of leaders (product, design, technology), which ensures balanced decisions and alignment of the entire organization. Source: ItamarGilad.com

Spotifybecame famous a few years ago with its own Agile scaling model (the so-calledSpotify Engineering Culture), where the basic organizational unit isSquad– small, autonomous product team. In this model we also find the concept of a triad (sometimes called„TPD trio”, FromTrio: Product-Design-Development). Typical Squad on Spotify isled by a trio consisting of a Product Manager, a leading engineer (Tech Lead) and an Agile Coach/Scrum Master²⁹. These three ensure full synchronization of business needs, processes and technical aspects within the team³⁰. Product Manager focuses on„why and what we build”(value for the user, priorities), Tech Lead – on„how will we build it”(architecture, technical decisions), and the Agile Coach keeps an eye on it„how we work”(process, agility, good communication). This separation of roles in the Spotify triad is slightly different in emphasis from the Torres model (where the trio includes a UX designer instead of a Scrum Master), but the goal is similar –sustainable leadershipin the team, covering key areas. In practice, Spotify assigns each group of bands (Tribe) a so-calledTribe Lead Trio(head of product, head of design, head of engineering) taking care of the direction for the entire product area. This ensures that although individual Squads are autonomous, their activities remain consistent with the company’s goals. Spotify’s experience shows that allowing teams autonomy within a clearly defined purpose and the support of a triad of leaders promotes innovation and rapid functionality delivery. In this modelstrong emphasis was placed on culture– the trio of leaders is to inspire, remove obstacles and take care of people’s development, instead of giving orders. This makes employees feel like they own the product, which, combined with lightweight Agile processes, has allowed Spotify to scale to hundreds of engineers without losing the startup dynamic.

AlsoAtlassian– a company known for its tools for teams (Jira, Confluence) – uses a variant of the trio model, calling ittriads. At Atlassian“triad” means close cooperation between the Development Lead, the Design Lead and the business/product leaderwhen setting product strategy. The company came to the conclusion that it is extremely rare to find one person who is an expert in technology, UX and business at the same time – socombine the competences of specialists into small leadership groups³¹. In practice, the triad determines the direction of product development and is supported by a wider team, including Product Owners (focused on the backlog and coordination of implementation with the rest of the development team) and, for example, Product Marketing Managers (responsible for communication with the market). The triad makes key product decisions and ensures consistency of vision and priorities.“In our case, the Product Manager sits in the engineering department shoulder to shoulder with developers”– write representatives of Atlassian –“by creating a triad with the head of design and the head of development, which allows you to combine the perspectives of business, user and technology at the strategy stage”. Atlassian emphasizes that this organization works well in an Agile environment – PMs have a technical understanding of the project and are advocates for the engineering team, and at the same time, through the triad, they are provided with support in the areas of UX and business, which unlocks the full potential of the product.

It is worth noting that smaller companies and startups are increasingly implementing practices similar to the Product Trio model. It is often not formally called a trio, but the meaning remains: to ensure thatthe product is created with the simultaneous cooperation of a business/product specialist, a design specialist and a technology specialist. In a startup, it happens that one person plays two roles (e.g. a co-founder who is also PM and UX, cooperating with the head of technology). However, the more mature the organization, the clearer the division into these three pillars becomes. Research shows that companies that break away from silos in favor of multidisciplinary, empowered product teams see improvements in metrics such as time to market, end-user satisfaction, and employee satisfaction (Torres’ survey results cited earlier are an example of this).

To sum up,the Product Trio model changes the way development teams work– from hierarchical division of tasks to joint product management. The experiences of Google, Spotify and Atlassian show that although it requires a change in mentality, the effect is better products created faster and with less cost of corrections. In the next section, we’ll look at how the current AI revolution may further impact product team roles and how to prepare for the future.

From webmaster to full-stack – the evolution of roles in IT teams

To understand where development teams are heading, it’s worth taking a look back at how IT roles have evolved over the years. In the 1990s, a popular term for a web developer was“webmaster”– the orchestra man who designed, coded and maintained the entire website. In the early days of the commercial Internet, one person was often able to build and operate even a complex website on their own. As one of the participants of the industry discussion aptly put it,„’Webmaster’ is a relic of the times when one person could single-handedly build and maintain a web application. Now applications are much more complex and roles are more specialized”.³²Indeed, with the explosion of web technologies and the increasing complexity of systems in the years 2000–2010, there wasstrong specialization of roles. They showed upfrontend developersspecialized in interfaces (HTML/CSS/JS) andbackend developersfrom server logic and databases. They operated separatelynetwork and system administrators,QA testers,security specialists,database administrators, etc. Each of these roles required in-depth knowledge in a narrow area. The project teams grew – sometimes dozens of people in different departments worked on one product, transferring work to each other in stages (which corresponded to the waterfall approach).

However, with the popularization of Agile and DevOps methodologies, it happeneda shift towards removing silos and expanding competences. Scrum teams were supposed to becross-functional– that is, capable of delivering a complete increase in the product on its own, without “handing over” the work to another department. This often meant that developers began to take over some of the testers’ tasks (development of automated tests), testers learned the basics of coding, and administrators worked closely with programmers (DevOps movement). Concept“full-stack developer”– i.e. a programmer “from frontend to backend” – has become very desirable. Interestingly, some industry veterans point out that„full-stack development” is nothing new – in the past, every developer had to be able to do a little of everything. So, in a sense, we went back to the roots, only at a higher level of complexity.

Today, many companies focus onfull-stack teams– not in the sense of a single “jack of all trades”, but rathersmall teams composed of people with broad competences, which together cover the entire technology stack and product development process. Such a team can independently design the solution, write front- and backend code, take care of the cloud infrastructure, implement and maintain the product. The classic example here is the concept“Two Pizza Team”(a team so small that two pizzas could feed it) popularized by Amazon – where 6-8 people with complementary skills are given full responsibility for a given microservice or functionality. Agile methodologies support such a model: Scrum promotes interdisciplinarity and team self-sufficiency, and DevOps encourages developers to take responsibility for implementation and operations (infrastructure as code, continuous integration, etc.), which previously belonged only to IT Operations departments.

Back to full-stack teamsit is also a response to the problems of excessive specialization. When each specialist „only looks after his own part”, it is easy to create bottlenecks (e.g. the tester will be available only in a week – work stops) and a decrease in responsibility for the whole („my part works, the rest is not my problem”). In a full-stack team, people have broader competences and are more willing to share knowledge – e.g. a programmer will learn to write integration tests, a tester will automate regression, an admin will teach a programmer how to prepare a cloud deployment. Yespolymathicit makes the team more resistant to turnover and can deliver value faster because less time is wasted on transferring work between departments. The Scrum Guide explicitly says:“Scrum teams are cross-functional, which means they have all the skills needed to produce valuable growth in each Sprint”³³. In practice, this often means that individual team members teach each other andexpand their competences, so that no key skill is unique to one person – then no one becomes a bottleneck.

Currently, a typical agile product team may consist of, for example, 5-9 people, including: 1-2 full-stack developers (or divided into frontend/backed, but with mutual understanding of their areas), 1 UX/UI designer, 1 tester automating tests, 1 DevOps/SRE specialist taking care of the infrastructure and CI/CD, and of course the above-mentionedtrio of product leaders(PM, UX, Tech Lead) managing the team’s work. The boundaries between roles are becoming more fluid. Developers are more likely to participate in conversations with users and plan functions (which used to be the domain of analysts), designers are learning the basics of frontend to better understand how their projects will be coded, and product managers are gaining technical skills to talk to engineers more effectively. In short –everyone is becoming a little more full-stackwithin its scope.

To summarize the historical trend: we have moved from generalists (webmasters) through a period of strong specialization to once again appreciate the advantages of the approach of generalists working in small, agile teams. This does not mean that specialized knowledge is not needed – on the contrary, it is crucial – but an effective team of the future is one that can assemble the knowledge of specialists into a coherent whole, instead of keeping them in separate silos. The Product Trio model fits this perfectly, combining three key specializations „at one table”. Another factor shaping roles in teams is technology – especiallyartificial intelligence, which is already starting to automate many tasks and create completely new roles in the industry.

Artificial intelligence in the work of product teams – new roles and automation

Artificial Intelligence (AI)is becoming an increasingly important element of the software development ecosystem. Its impact has two main dimensions:process automation(AI as a tool to improve team work) andchange of roles and competences(emergence of new specializations and transformation of existing ones).

Automation of discovery and development processes:In the areadiscovery productAI can relieve the team of data analysis and insight generation. For example, thanks to machine learning, it is possible to automatically process thousands of user opinions or interview transcripts and extract key topics and emotions from them. AI can also generate initial ideas for solutions based on identified problems – for human evaluation, of course. In turn, in phasedefining the product visionLanguage models can help you quickly collect information about market trends, analyze competition or even generate a business case draft. Tools that are product assistants are already emerging today and answer PM’s questions based on documentation or data (e.g.chatbotconnected to the company’s knowledge base). In short, AI has the potential to become“partner” of the product manager– performing arduous analytical work much faster. McKinsey estimates that full implementation of AI into the product development cycle will allow product developers and engineers to spend much more time on creative work and less time on routine tasks³⁴.“Integrating AI into the entire software development lifecycle can speed up the process, improve product quality and increase customer satisfaction.”– says Inbal Shani, CPO of Twilio³⁵. For example,automation of tasks such as project management, market analysis, performance tests and feedback analysisallows the PM, designer and developer to focus on more creative aspects – product strategy, concept design or solving complex problems.

Currently, the most visible example of AI in the development process iscode generation. Tools likeGitHub Copilot, Amazon CodeWhisperer or Tabninethey use AI models (e.g. OpenAI Codex) to suggest code fragments to programmers in real time. Effect? The programmer writes code faster because the assistant completes repetitive blocks, suggests syntax corrections or even entire functions based on natural language comments. According to the McKinsey 2023 report,Developers using AI coding tools report speeding up their daily work by 20-50%³⁶. GitHub conducted a study that showed that88% of developers feel more productive, and 77% spend less time searching for information when they use Copilot while working. What’s more, AI doesn’t just make writing code faster, it canimprove its quality– the tools learn from the best practices from the open source world, thanks to which they suggest solutions consistent with good patterns. Forrester estimates thatAI-assisted development can reduce the number of defects in production by up to 30%, because code supplementation models suggest proven and tested fragments instead of error-prone „handmade Easter eggs”. AI also helps inautomatic code review– there are systems (e.g. DeepCode, Codacy) that analyze changes in the repository and detect potential errors,code smellsor security gaps before the code goes into integration. There is also a revolution in the field of testing: intelligent tools can generate unit tests for a given fragment of code or end-to-end tests based on the application description, as well as automatically analyze logs to indicate the cause of the failure. All this means thatthe work of software engineers is becoming automated– tedious and repetitive tasks are performed by AI, and human programmers can devote more time to designing architecture, solving non-trivial problems and creative aspects of engineering.

Also a roleUX/UI designerchanges under the influence of AI. There are tools known asAI design assistants. For example, an applicationUizardWhetherGalileo AIthey are able to generate a user interface based on a text description – the designer enters what he wants to achieve (e.g. „registration screen with an email and password field, in a minimalist style”), and the AI ​​creates a design sketch that can be further refined.AI also automates some of the tedious design tasks: adjusting layouts to different screen resolutions, generating color variants consistent with the palette, or even creating iconography and images based on text prompts. In the area of ​​UX research, AI assistants (such as the Dora AI tool) cancollect and analyze feedback from users and support A/B tests– thanks to this, the designer receives synthetic conclusions without having to dig through hundreds of answers. All this means that the designer’s work shifts from „pixel craft” to more towardscreative supervision and synthesizing insights. AI may propose several layout variants, but it is the designer – equipped with knowledge about the user’s context – who will select and improve the right one. As the magazine concludesUX Collective: :“The role of AI in UX design is changing the way designers work – it is becoming faster, more intuitive and data-driven”³⁷. The designer of the future will therefore be morefacilitator of the design process(using AI to generate options and collect data), and to a lesser extent – an operator of graphic tools.

New AI-related roles and competencies:The dynamic development of AI has also created completely new specializations in teams. More and more organizations are hiringData Scientists and Machine Learning Engineers– experts in model training, data analysis and implementation of AI services. Product teams, especially those using data on a large scale (e.g. recommendation applications, personalized applications), integrate data scientists as permanent team members who, together with the PM and the rest, plan AI-based functions. A role appearedAI Prompt Engineer– a person who can “talk” to language models to obtain the desired results from them and constantly improve these prompts. Although it sounds exotic, some companies openly recruited prompt engineers for the positions of prompt engineers in 2023, realizing that the skillful use of, for example, GPT-4 can dramatically increase the efficiency of the entire organization. Roles are emerging in the area of ​​responsible AI implementationAI Ethics Officer / AI Governance Lead– large organizations want to develop AI in accordance with the principles of ethics and law, hence the need for specialists supervising issues of bias, privacy and compliance with regulations.

Importantly, they are also changingexisting roles. Today, a product manager must understand the basics of AI to be able to plan functionalities using this technology and assess their impact on users. Many companies even talk about the role“AI Product Manager”, i.e. a PM specializing in AI projects – combining the competences of a classic PM (understanding market needs) with knowledge of the possibilities and limitations of machine learning models. Similarlysoftware architectsmust include new AI components in their projects, asecurity specialists– take into account the attack vector through model manipulation or protection of training data. Generally, it happensfusion of the worlds of AI and „classic” IT. According to a global McKinsey survey, already in 2023 over 3/4 of companies use AI in at least one business function, and the largest corporationsthey are massively creating new AI-related positions and training employees in this area³⁸In other words, AI is no longer the domain of narrow R&D teams, but is becoming an integral part of the everyday work of product teams.

The impact of AI on the teamwork model:One of the interesting consequences of the popularization of AI may be a change in the structure of roles in the product trio itself. Since AI can take over a large part of the PM’s analytical work (e.g. market research, data analysis) or even certain design tasks (e.g. generating interface variants), the question arises – will the trio remain a trio or will it change? Some experts suggest it may appearfourth member of the product trio – AI/data specialist, who will participate equally in product management. Alternatively, perhaps the role of the designer and product manager will expand so much thanks to AI that instead of three people, in the future two will be enough (e.g. a PM combining business + UX competences supported by AI, and a Tech Lead focusing on implementation with AI assistance). We are already observing todayblurring the boundaries between roles– AI is able to create marketing texts and market analyzes (traditionally the domain of the Product Marketing Manager), which leads to the hypothesis thatthe role of PM and PMM may merge³⁹. Similarly in the field of design – some companies reduce the demand for the so-called pure UI designers, because prototypes generate AI, but their importance is increasingUX ResearcherandService Designer(things that AI cannot solve yet, because they require a deep understanding of the context). McKinsey even predicts that the boundaries between product management, design and marketing will blur – AI will replace many „traditionally other people’s” tasks, and thuspositions may converge⁴⁰.

Artificial intelligence brings enormous promiseaccelerating the product development cycle(faster time-to-market) and increased innovation. But to fulfill this promise, companies must adapt accordingly. You will need to invest intraining teams in AI tools– so that every PM, designer or developer can effectively cooperate with a “virtual colleague” and treat him as support, not a threat. It will also be important to establish principles of human-AI cooperation in the team – e.g. defining who is responsible for errors made by AI, how to verify automatically generated results (e.g. code or content) before they reach the user, etc. As the Accenture report emphasizes,trust in AIwill be crucial – organizations must develop processes that build confidence that AI works predictably and responsibly, otherwise people will not want to use it.

In summary, AI has the potential to becomethe fourth pillar of the product team– not necessarily as a separate person, but as ubiquitous technology supporting every aspect of work. In the near future, existing team members are more likely to get it“superpowers” ​​thanks to AI, than that AI will fully replace any of them. It’s already obvious thatThe best results are achieved by teams that treat AI as a partner: a developer with Copilot codes faster, a designer with a generative assistant tests more design options, a PM with an AI analyst draws more accurate conclusions from data. In the next section, we will try to go even further and consider possible scenarios for the future of development teams in 5-10 years, taking into account both the Product Trio model and the AI ​​revolution.

Scenarios for the future of development teams

What might product development teams look like in a few or a dozen years? Although predicting the future is subject to uncertainty, there are several probable scenarios on the horizon resulting from the trends described:

• Scenario 1: “Superteam” – a minimal team supported by AI.Let’s imagine a future team consisting of just…several people with broad competences, intensively supported by AI tools. Perhaps even one person will be able to accomplish what once required an entire team, because AI assistants will perform most of the auxiliary tasks for them. There are already opinions thata single engineer armed with AI can replace an entire traditional team– AI will analyze the code, detect bugs, optimize performance, and a human will manage this orchestra of tools⁴¹. In such a scenario, the demand for a large number of specialists drops dramatically and the pressure on the so-calledT-shaped skills(jedna głęboka specjalizacja + szerokie umiejętności ogólne) u liderów produktu. The band might resemble something like this„AI operators”, who configure and supervise the work of intelligent agents performing specific tasks in the project. This is an extreme vision, but startups, for example, can strive for maximum efficiency by employing a handful of talented people supported by AI, instead of building large teams.
• Scenario 2: Convergence of roles – blurring of the lines between PM, UX and dev.If AI takes over many specialized activities, roles within the team may begin to merge. Already, a product manager often performs the tasks of a business analyst himself or even writes simple SQL for analysis – with AI he will be able to do even more (e.g. generate marketing texts or interface sketches).The role of PM may therefore expand to areas previously separated (research, marketing), and on the other handthe role of a UX designer can take on more aspects of product strategy. McKinsey predicts that the line between product and marketing will blur – the positions of Product Manager and Product Marketing Manager will probably merge thanks to AI, which will make it easier for the PM to perform PMM duties⁴². A model where is also possible“designer”it will become more“service designer/strategist”i w praktyce będzie pełnić część roli PM (skupiając się na definiowaniu doświadczenia end-to-end), podczas gdy inżynierowie z AI przejmą znaczną część implementacji. This is the scenarioevolution of the trio model– perhaps not three distinct roles, or rathera team of experts with overlapping competences, jointly responsible for the entire process from concept to implementation. In an extreme case, you can imagineduets instead of trios– e.g. one person combining business + UX competences and the other combining tech + data competences, cooperating with each other and with AI. Of course, this would require multi-talented people, but AI can help fill the competence gaps.
• Scenario 3: AI as a full team member (Team + AI).In this view, it is not so much that people change, but…an „artificial friend” joins the team. Mógłby to być np. zaawansowany agent AI, który uczestniczy w codziennych stand-upach, monitoruje backlog, sam tworzy propozycje user story na podstawie analizy zachowań użytkowników i nawet przydziela je sobie do realizacji (pisząc kod/testy). Brzmi futurystycznie, ale już dziś podstawy takiego podejścia istnieją – boty DevOps w repozytoriach samoczynnie tworzą pull requesty z aktualizacjami zależności, chat-boty obsługują część zgłoszeń od użytkowników, a algorytmy monitorują metryki produktu alarmując zespół gdy dzieje się coś nietypowego. Accenture in its vision 2025 talks about“agentic systems”– independent AI agents that will be able to manage entire processes or functions in the company⁴³. Not only individual tasks, but e.g.the entire process of servicing an area(logistics, customer support, resource optimization) can be transferred to a group of cooperating AI agents. In the context of a software product, you can imagine an agent thatacts as a tester– constantly clicks around the application, looks for errors, reports them and maybe immediately suggests corrections. Another agent couldact as an analyst– check on an ongoing basis which functions are rarely used and suggest decisions to the PM to improve or withdraw them. In the Team+AI scenario, human team members must learnwork with AI almost like you would with another employee– assign him tasks, receive reports, include him in communication. Maybe we’ll see a scrum someday, whereDefinition of Doneassumes that the user story is completed only whenAI QA Botwill confirm no errors, aAI Analytics Botconfirms that the change did not worsen key metrics. Such a model could significantly increase the scalability of teams – one person can „delegate” many parallel tasks to different AI agents, maintaining supervision over them.
• Scenario 4: Evolution of the Product Trio model – trio 2.0.In this variant, the basic structure of cross-functional product leadership remains, butthe roles within the trio change under the influence of AI. For example“Tech Lead”Tomorrow may become more“AI Lead”– instead of manually managing coding by developers, it will primarily select and train AI models to generate code and architecture.“UX Lead”can turn into“Experience Lead”, focusing on the overall user experience combining product, support, community – because the interfaces will be partially generated by AI based on guidelines.“Product Manager”in turn, it can evolve towards“Strategic Value Manager”– a person focusing on defining the vision, priorities and assessing the value provided by various (also autonomous) product initiatives. Trio 2.0 could also be expanded by a fourth chair – e.g.“Data Science/AI Lead”– i.e. a data specialist who, in cooperation with PM, UX and Tech, manages the use of AI in the product. Some companies are already talking about…“Analytics Translator”– someone who translates the possibilities of AI into the language of business and vice versa. This person could join the trio if the product relies heavily on ML.

Of course, different scenarios may vary in different industries and organizations. Financial corporations will probably still have larger teams with a clear division of roles, but strongly supported by AI tools (scenario elements 3 and 4). In small software houses, the „superteam” model may dominate (scenario 1) – several full-stack developers with Copilot instead of a dozen or so narrow specialists. However, regardless of the shape, certain skills will become crucial in all variants of the future.

Summary and recommendations

Summary of main conclusions:Development teams have moved from the waterfall model, through the Agile revolution, to the current transformation towards modelsproduct-centric. Industry data clearly shows the advantage of the agile approach over the traditional one – higher project success rates and better adaptation to customer needs. However, Agile is not only about changing the process, but alsorebuilding the culture and structure of teams– odejście od silosów na rzecz cross-funkcjonalności i większej autonomii. ModelProduct Triois a natural extension of these assumptions: it integrates the perspectives of product, design and technology within one well-coordinated leadership team. Examples of leading technology companies (Google, Spotify, Atlassian) prove that a trio/triad can significantly improve product decision-making and improve cooperation between roles. Co więcej, pierwsze badania (m.in. Torres 2024) sugerują, że zespoły pracujące w tym modelu są bardziej zadowolone i efektywne.

At the same time, we observe„back to generalists”w zespołach – pełna specjalizacja ustępuje miejsca modelowi full-stack, w którym niewielkie zespoły są w stanie samodzielnie dostarczać funkcjonalności end-to-end. Wymaga to inwestowania w rozwój szerokich umiejętności członków zespołu i budowania kultury dzielenia się wiedzą (np. developer uczy się od projektanta podstaw UX i odwrotnie). Such versatility is important today, and in the era of AI it will be crucial – becauseit is easier to automate a narrow, repetitive section of work than a complex, cross-sectional task.

Artificial intelligence is already changing the way product teams work. AI plays a rolevirtual assistant, accelerating coding, testing, analysis and more. Firmy, które umieją wykorzystać te narzędzia, odnotowują wzrost produktywności (np. +30–50% szybkości developmentu dzięki asystentom kodu) i poprawę jakości produktów. AI tworzy też nowe możliwości – pozwala budować funkcje oparte o uczenie maszynowe, personalizację, predykcję, co jeszcze parę lat temu wymagało zespołów badawczych. On the other hand, AI poses challenges – how to retrain staff, how to reorganize roles to fully benefit from its potential? Organizacje musząredesign their processes and structures to generate value from AI. Without it, you can get stuck with seemingly great technology that doesn’t translate into business results.

How to prepare for changes?

1. Breaking with silos – focusing on product trios and multidisciplinary teams.Whether you formally call it Product Trio or something else, make sure it’s on your product teamthere are three key competencies: business/product, design, technologyand that these people work closely together at every stage. Reduce the intermediaries between originators and implementers – instead, seat everyone at one table (even a virtual one). Mature organizations can complement this approach with data/AI competencies as a fourth element, if the product requires it. Remember:innovation is born at the intersection of different perspectives, and not in uniform functional teams.
2. Building a „product-first” culture and end-to-end responsibility.Give product teams the autonomy to decidewhat and how to build, clearly defining success measures (OKRs, product KPIs). Encourage trio members (and the entire team) to share responsibility for the product’s business goals – this increases their commitment and orientation to delivering value, not just „getting things done.” In practice, this may mean a change in the way work is assessed – fewer points for „delivered” functions, more measurement of results (e.g. increase in user activity). Support people in making decisions close to information – a senior manager doesn’t always have the full context, so trust the team to know what to do, while expecting them to measure results and quickly correct course if results are below expectations.
3. Investments in the development of broad competences (T-shaped skills).Provide internal training and internships thanks to which specialists will broaden their horizons – e.g. train programmers in the basics of UX (user empathy, accessibility), train UX specialists in data analysis and SQL basics, train product managers – in reading code or at least understanding the development cycle. Task rotation in the team,pair programmingwith interchangeability of roles, hackathons where everyone tries something outside their specialization – all this will help build a truly cross-functional team. As a result, the team will be more flexible and communication will improve significantly (because everyone „speaks a little of the language” of their colleagues). In the era of AI, the more people understand about the work of others, the better they will be able to use tools that automate various areas and integrate the results of AI work into a coherent whole.
4. Introduce AI into your team wisely and strategically.Don’t wait until you’re left behind – experiment with available AI tools in your development process now. Start with small improvements: maybe an assistant to generate test code? Maybe using AI to generate 10 variants of marketing text and select the best one? Find out where your team wastes the most time on repetitive activities or analyzing large amounts of data – this is where AI can probably help. But keep this in mindresponsibility and quality– establish procedures for verifying AI results (code review is still necessary, every code is tested – whether written by a human or AI). Make sure the data you feed AI is secure and compliant with regulations (especially in sensitive industries). On the other hand,encourage your team to explore AI and share knowledge– do an internal demo of how someone used ChatGPT to draft specifications, or how a designer used generative AI for a mood board. Odczaruj AI jako czarną skrzynkę – traktujcie ją jak nowe narzędzie, które trzeba opanować.
5. Preparing the organization for role changes and potential staff shifts.Be honest with your team that AI will change the way they work – it won’t necessarily take away jobs, but it definitely willwill change the scope of tasks. Plan development paths for people whose current specialization may be partially automated. For example, a manual tester might retrain as a test automation engineer or a data quality analyst to train models. It is worth including less technical people in the AI ​​training process (because models need domain knowledge). The key is the approach:“AI is not intended to replace people, but to bring out the best in them”. Jeśli pojawi się konieczność redukcji etatów w jednej funkcji, postaraj się wykorzystać te talenty gdzie indziej – np. świetny dokumentalista/analityk wymagań może zostać trenerem bota konwersacyjnego (wykorzysta swą skrupulatność i umiejętność komunikacji do ulepszania odpowiedzi AI).
6. Experiment with new team structures and share knowledge.The world is just learning how to best integrate AI and the trio model into organizations. Don’t be afraid to pilot new ways of working: maybe you can create a „mini startup” within the company operating entirely as a cross-functional product team on an idea – with a full decision-making mandate? Or try it in one projectduo modelinstead of a trio (if, for example, AI took over a lot of design tasks, maybe PM + Tech Lead will be enough?). It’s important tomeasure effectsthese experiments and learn from them. Establish channels for sharing knowledge – e.g. internal blogs, brownbags, where teams talk about their experiences with a new organization or tool. The entire industry is learning this, so be open to external knowledge – participate in conferences, read reports (Accenture, McKinsey, etc. often publish case studies), get involved in communities (e.g. ProductTank, Agile meetup) to exchange lessons with others.

Finally, it is worth emphasizing an optimistic point of view:The future looks exciting for development teams. Thanks to the Product Trio model, we have the opportunity to create products that are better suited to needs and do it in an atmosphere of true cooperation, where each team member feels the ownership of the success. However, thanks to AI, we can free ourselves from many tedious tasks and focus on creating innovations. Companies that skillfully combine these two elements – strong, agile product teams and intelligent tools – will gain a competitive advantage. As Accenture notes,AI is becoming our technology partner, giving organizations the opportunity to redesign the way they work and create value. This is a “new era of autonomy” in which humans and artificial intelligence work together to achieve things that were previously unattainable. The condition for success is trust, education and openness to changes – both technological and cultural. The future will certainly bring challenges (e.g. the need for continuous improvement or ensuring responsible use of AI), but by putting people and good product practices at the center, we have a chance to tame this future and use it for the good of both the business, customers and the teams themselves.

Finally, it is worth noting that although the future brings some unpredictability, one thing remains certain:agility and adaptability– both processes, structures and people themselves – will be the most important asset of development teams. Those who can combine human skills with AI capabilities in a well-coordinated, three-full stack team will likely lead the industry in the coming years.The future belongs to brave, collaborative and learning organizations.If your company is one of them, you have reasons to be optimistic. If not, it’s high time to transform, because the world of technology does not wait for latecomers.