Navigating the SaaSpocalypse – AI-native is the Biggest Change for Product & Technology Teams (R&D) since Agile

Introduction

AI is fundamentally transforming the size and shape of product and technology (R&D) teams in what is emerging to be the most significant transformation of software development lifecycles (SDLCs) since the advent of agile methodologies and scrum teams approximately 20+ years ago.

As teams go AI-native, the previous guidelines and rule books on what teams look like and how they should be staffed need to be thrown out and re-imagined for an AI-native world. An AI-native world will look considerably leaner and flatter while delivering significantly higher levels of output at faster velocity.

The cost of Engineering was previously the largest cost of producing software, so teams and structures were optimized around maximizing the certainty of a build and reducing late arriving changes that were highly expensive. Now, with the cost to build being greatly reduced with the cost of last minute changes being near zero, “what to build” and “why to build it” and “for whom” are becoming the key questions and bottlenecks, representing the areas for most needed optimization.

This post shows where we came from, what the new world looks like, and insights around the transformation required. I’ve written this post assuming an organization size between 100-250; it will need to be scaled based on the unique need’s of one’s own team. Regardless of where one is with their own AI journeys, given the size & scope of impacts, one needs to start thinking about this end-state now given the magnitude of change. Be forewarned – this is a LONG post, because the changes for going AI-native are significant and far-reaching across an entire product/technology (R&D) organization.

Where We Came From

The traditional agile team structure has been quite stable for a number of years. (See Figure 1)

Figure 1 – a Typical Agile/Feature Team

You have:

• A dedicated Engineering Manager – typically a full-time people manager who is a pure coach leading software development activities.
• Staff and Feature Engineers – the actual fingers on keyboard building out the features. Typically around 6.
• Potentially a Scrum Master / Product Owner who is responsible for decomposing the product and design requirements and running the Agile ceremonies

From a supporting perspective, reporting into the team in a matrix fashion are:

• A dedicated Product Manager defining the what and why to build
• A dedicated UX Designer (for non-API/platform teams) defining what things should look like
• A QA Engineer responsible for testing

Supporting this for what I would deem non-startup-sized R&D teams is a management structure comprised of:

• Head of Product with typically at least 1-2 management layers
  • Feature product managers with affinity to the agile teams
  • Strategists focused on market, competition, and forward looking investments (e.g. build/buy/partner)
  • Potentially other product managers, typically focused on incubation/innovation that have yet to see feature teams assigned to them
• Head of UX with at least 1-2 management layers (though many organizations have UX report into Product)
  • Feature UX designers with affinity to agile teams
  • A Design System lead and UX designers owning the end-to-end design system and UX/human interface guidelines (if in the leanest model possible, this is where accessibility would live also)
  • A head of User Research and User Researchers focused on supporting the design initiatives within the various feature crews
• Head of Engineering with at least 1-2 management layers
  • Engineering Managers and Engineers with affinity to feature teams
  • Architects/Principals focused on end-to-end systems architecture
  • A Platform team with its requisite structure focused on the shared infrastructure and building blocks enabling all of the feature teams
  • A dedicated SRE team focused on the core infrastructure and ensuring production uptime and performance
  • A dedicated QA team focused on quality assurance, typically comprised of a team focused on end-to-end testing and then resources in a matrix with affinity to individual feature teams

For reference, please see Figure 2.

Figure 2 – a Typical Product/Technology (R&D) Team Structure

In addition, many organizations also have a Data team comprised of an Analyst leader + underlying Data Analysts and a Data Engineering leader + underlying Data engineers. This team supports Product and Design primarily, going through a lifecycle of:

1. Data Request
2. Analyst interprets underlying request
3. Analyst partners with Data Engineering to create requisite reports & then prepares analysis
4. Hand back to Product or Design

If the Data function does not exist, the analysis function is typically performed by Product and/or User Research solely.

Because AI has enabled such massive productivity gains across all disciplines, this structure is effectively obsolete and a much leaner and more efficient structure is enabled.

The Typical Feature Lifecycle

With the assumption that some semblance of a product strategy function and/or UX research function has created a backlog of problems to solveA traditional feature lifecycle has looked like the following:

• Step 1 – Research
  • User research conducted by the UX Research function to uncover customer jobs, pains, and opportunities
  • Data analysis conducted by the Data function to quantify the size and scale of those problems and opportunities within the customer base and broader market (non-customers)
  • Additional primary/market research conducted by various factions within the Product Function
• Step 2 – Product Requirements Document (PRD)
  • This has been the historical output of the Product discipline; a long-ish, complex artifact that describes a feature in-depth.
• Step 3 – UX Designs
  • Built off of the PRD, these include wireframes and/or high fidelity composites based upon the PRD to describe the UX of the feature in-depth.
• Step 4 – Build, Test, and Deploy
  • Engineering steps in to build and deploy the feature relying upon partnership with Product and Design.
• Step 5 – Analyze Business Results
  • Product and Data partner together to analyze the business performance of the feature once live to inform future backlogs.

As with the team structures, AI enables a significantly simpler and leaner model with considerably higher degrees of automation.

The Evolution of Product

Product Managers have historically worn many various hats. This no longer needs to be the case. In a leaner, AI-native world, two principal archetypes emerge:

• The End-to-End Builder – This archetype conducts his/her own research and analysis. They then build an end-to-end interactive prototype leveraging AI while documenting the requirements and acceptance criteria in a Statement of Intent. Said interactive prototype is validated with customers and refined until it is ready to build, at which point it is built for production by Engineering.
• The Strategic Leader – This archetype is where frontline people management comes into play. It is also responsible for understanding the market, the competition, and prioritizing the macro problems or jobs that need improvement or that should be solved next. This leader thinks in terms of winning hte market, not specifically what to build next.

Other roles that may have existed in the past now become redundant, unless one is planning a net new zero-to-one or build/buy/partner, in which case one simply adds more of the archetypes above in order to work ahead.

AI fundamentally changes the day-to-day Product workflows in many ways:

• Research synthesis can now be done by AI; it can take reams of raw materials and then normalize and synthesize into consistent and structured inputs for use when planning product in accordance with the desires of the team and organization.
• Data analysis can also now be done with AI. Provided that the right natural language query interfaces are built on top of corporate data assets, data analysis that would have been the historical remit of a Data Analyst can now be self-service and synthesized into other research also using AI.
• User research can now be self-fielded and folded into other analyses using AI. To get to statistically valid populations of data, PMs can design surveys an field them leveraging cost-effective market research firms such as GLG or Alphasights or SaaS platforms such as usertesting.com; survey results can then be synthesized using AI.
• Interactive Prototypes remove market and user uncertainty. By being able to validate interactive functionality with live customers, the uncertainty around what is to-be-built is simply removed. Depending upon an organization’s Engineering AI maturity, this can either be built in a throw-away manner using something like Lovable or on a feature-branch that Engineering could ultimately take to production.
• UX design is now effectively done by the PM as part of the interactive prototype and should follow organizational human interface guidelines. Tools such as Claude Design can be utilized and organizational guidelines followed as part of the AI’s ability to build UX/UI within established style guidelines and other ground rules.
• A shorter Statement of Intent replaces a long-ish PRD. It accompanies the prototype and captures what is being built, why, and what success looks like.
• PMs now Produce Evals (Evaluations). Evals are systematic frameworks, test suites, data sets, and scoring metrics to quantify the performance, quality, safety, and reliability of an AI feature or product. They replace traditional acceptance criteria and look like “Must maintain >92% accuracy on user intent classification” or whatever the equivalent is for one’s own application. Evals can be explicit, evaluated by LLMs, or have a Human-in-the-Loop (HITL) (in house, direct user feedback through in-app, or third-party) or some combination thereof.
• AI can curate the backlog of features post-launch. It can take real-time feedback (e.g. eval outputs, support tickets, forums, or other direct customer feedback from calls/transcripts such as Gong recordings or internal feedback) and do the first run at creating and curating the backlog, saving considerable time for the PM. Select feedback can then be extracted to repeat the process and building more prototypes and Statements of Intent as required. Provided production success agents are created as part of the feature build from an observability perspective, performance outside of desired/expected business parameters can also be automatically curated. And, depending upon the Engineering AI maturity, much of the work to execute the backlog can also be automatically built and tested via AI.
  • If this sounds like science fiction it isn’t. The OpenClaw project, which builds entirely in public, has demonstrated that this is entirely real and achievable today, albeit the token costs can get quite expensive depending upon the models utilized…

This has a profound impact on PM talent profiles, as the following additional skills are needed that many not have been historical core competencies:

• Technological Savvy to become an Expert User of AI – PMs need to be at “ninja” level when using tools such as Claude or Codex. They need to have enough technical proficiency to become absolute power users and be able to create their own skills and guidelines
• Data Analysis – With the help of AI, PMs are now fully capable of doing their own analysis in minutes-to-hours versus needing supporting functions to do it for them. This requires an analytical skill set that many PMs may not have historically possessed.
• Design Taste – As PMs through the act of building interactive prototypes are now effectively UX designers, they must bring to the table excellent UX taste and be capable of following design system and human interface guidelines.

Given the typical productivity gains realized by going all-in on AI, the number of PMs required is going to effectively double. Either twice the headcount is needed or PMs have to use AI to effectively take on double the scope and workload. This is largely going to be talent-dependent. If more headcount or different talent is needed, it will create a considerable strain on recruitment and team growth. All PMs will need to be strong in the newly added core competencies, which have not been historically consistent PM strengths.

The Evolution of UX/Design

From a people and team perspective, UX/Design is probably one of the most disrupted disciplines. With exceptions, instead of being an integral part of the feature development process, the UX discipline has effectively shrunk to the following charters:

1. Owning the Design System + Human Interface Guidelines – As has historically been the case, it is the responsibility of the UX/Design discipline to own the end-to-end system for what and how user experiences should be constructed. This now needs to be extremely well-defined and documented so that other disciplines such as Product can consume it.
2. Applying the Design System + Human Interface Guideline Compliance – Given the fact that things will be built far faster with far fewer players & roles involved, post-build review and compliance assessment with the design system and human interface guidelines becomes a new mandate for the team.

Given the narrower mandate, the number of management layers and UX designers will materially shrink – especially given the big change of not being involved in day-to-day feature construction any longer but a post-build review process. Likewise, the role of UX Research (with a few key exceptions) also can be materially shrunk or eliminated.

However, this does not mean the death and demise of UX. As noted, there are several key exceptions that do require dedicated staffing outside of this core mandate dependent upon business charter. These include:

1. Adding New User Personae – this scenario still requires the need for UX Research to profile and build new user personae such that Product has sufficient depth of understanding to be able to execute successfully.
2. Handling Rapidly Evolving User Personae – in the event that an organization’s user personae are not stable, UX Research is still needed to enable Product on the changes in the personae. This should generally be a highly infrequent occurrence and may be the sign of a much larger product/market fit issue.
3. Building a New Zero-to-One Product and/or Major Redesigns/Refactors – this is a case where UX designers do need to be involved in the feature development process in order to get the new capabilities right from the outset, including handling any potential modifications to Design System and/or Human Interface Guidelines.
4. Developing Synthetic Users for analysis and testing before entering prototyping stage. This is the future of User Research in an AI-native world and represents where a dedicated investment could make sense if desired organizationally.

AI will also change UX workflows materially, though not to the breadth of the extent in Product. Key changes include:

• Using AI to design new UXs or modify existing ones – tools such as Claude Design or Gemini can easily produce new designs while following existing guidelines and then rapidly iterate based upon feedback, cutting the timeframe down to get to high quality wireframes and composites materially. This can work equally well on the Design System as well as
• Using AI to review for Design System & HIG compliance – AI skills can be created to review UXs (both prototypes as well as production) for compliance with all established design guidelines. AI can also be used to automatically curate a backlog of lack of compliance so that UX issues find their way into the product backlog with minimum human effort.
• Building AI skills to enable UX creation – With a mature Design System and/or Human Interface Guidelines in place, AI skills and underlying templates can be created to enable others such as PMs to be able to easily create new user experiences that are compliant with all established guidelines.

From a skill perspective, UX staff will need to become power users of AI tools such as Claude or Codex and be fully versed in creating skills and agent context to execute the core discipline at maximum velocity while using AI tools.

The Evolution of Engineering

AI tools such as Claude Code, Codex, or Copilot represent one of the largest tooling changes since the shift from on-premise to public cloud computing. At a macro-level, instead of bare metal building things engineers are managing agents to do their building and are responsible for providing the right input context and then reviewing the agentic work product to ensure that the right outputs are being constructed in the right manner.

One can think of this as everyone is now an engineering leader for a fleet of agents. This requires that everyone be of requisite seniority to ensure that they can adequately review the inputs and outputs to ensure correctness. This does bias teams towards being more senior and does absolutely create a problem with how to leverage and mature junior engineers (but handling this a topic for another day). This needs to be counter-balanced with senior staff often being more resistant to new ways of working whereas juniors being more hungry to deliver and open to new ideas. This is where the “art” versus “science” of people leadership comes into play and evaluations/determinations must be made on a person-by-person basis.

The gains to be had are profoundly amazing – significantly higher levels of output at significantly faster velocity are very achievable without sacrificing quality. (More on this in a future post.) This does require, however, a fundamental rework of core workflows and the standardized build and maintenance of agents, skills, and agent context in a centralized fashion such that it does not turn into every person for themselves.

Although the size/shape/structure of the team will not change nearly as much as other disciplines, how an Engineering team operates will look materially different. What this looks like in practice is:

• Specification Agents – these will decompose interactive prototypes, Statements of Intent, and Evals created by PMs into the following sets of artifacts: a Refined/Detailed Intent Statement, Testable Scenarios written in Behavioral-driven Development (BDD) / Gherkin syntax, an Architectural Decision Record, and Non-Functional Acceptance Criteria.
• PMs and Engineering Leads will need to review and refine these in detail, applying requisite levels of discernment and judgment to ensure that the AI has the right context to build what is desired.
• Implementation Agents – these will take the post-PM/Engineering refined outputs of the Specification Agents and actually write the code and then test the code based upon the Gherkin scenarios until development is complete.
  • It is imperative that the Implementation Agents have sufficient context to make the right implementation choice. Likewise, it also assumes that there is sufficient historical end-to-end tests and resultant infrastructure that the new tests can be appended and requisite end to end coverage applied.
• Review Agents – these will take the output from the Implementation Agents and review them against specifications plus other organizational needs such as semantic consistency, domain alignment, architectural conformance, and UX design guidelines along with anything else that should be verified prior to creating a Pull Request, which is the ultimate step for this stage of the journey.
  • It is imperative that the agents performing this work have sufficient context around what is needed organizationally so that they can catch everything.
  • If the same LLM is being utilized for Review Agents as for Implementation Agents, it should be a completely separate instance ensuring new context and providing the AI-equivalent of fresh eyes. Alternatively, a different LLM can be utilized (e.g. Codex parity checks Claude or vice versa). Getting this right is critical for long-term success and should be invested appropriately.
  • This is also the stage where PMs and Engineers should once again get involved for review to make sure everything is ship-shape. But, ideally this is not line-by-line review but a more macro-level review of implementation versus intent.
  • Issues flagged by the Review Agents are fed back to the Implementation Agents for rework until the effective issue count is down to zero.
• PR in CI Pipeline – Review agents are run again with fresh context to ensure nothing slipped through the last round. Runbook Agents are leveraged to keep operational documentation refreshed and current. Flaky Test agents identifies and quarantines intermittent test failures to prevent them from becoming noise. Once everything is clean here, it’s time to promote to production.
• Observability Agents – these monitor production metrics end-to-end against production. As thresholds are not met, new work items are generated for the product backlog to remediate as the process cycles around to the beginning.
• Business Observability Agents – these monitor user behavior and ensure that feature success metrics as well as macro business goals are being achieved. This is where Evals are turned into Loops with AI doing the proactive monitoring and interpretation of whether a new feature is working from a customer and business perspective. When they are not, issues are created back into the product backlog for triage and curation as the process cycles around to the beginning.

Building and maintaining this level of agentic infrastructure requires dedicated commitment and investment. Although anyone should be able to contribute to it in an internal open-source manner, it does require dedicated ownership and curation. This is especially important because AI is moving so quickly so that an organization can stay on top of the latest model developments, evaluate new tools as they become available, and keeping an eye on token consumption and cost (e.g. don’t just upgrade immediately to the newest model because it may several-X token costs). From a practical perspective, if one has multiple codebases, flavors of this may need to be created for each codebase to ensure appropriate context, though the Specification and Observability stages should be able to be leveraged horizontally across one’s entire stack.

From a team perspective, the changes are more nuanced given that this is more of a technology and process change than a people change, but there are still some material differences in an AI-first organization versus one that is not:

• Agile/Feature Team sizes will shrink by approximately half. Instead of having 6 engineers one will most likely end up with 3 (a senior/staff + 2 engineers) doing the same amount of work.
• Engineering Managers will run 2 teams and be hands-on once again. This is a natural evolution of the fact that with AI, there is absolutely no reason for leaders to not become player coaches. Span-of-control from a HR perspective does not change, but scope effectively doubles due to the gains to be had from AI.
• Dedicated QAs are no longer needed. AI will be writing and executing the tests. Any issues with the tests need to be caught at the Review Agent stage. This effectively eliminates the need for dedicated QAs, with the skillsets such that they can hopefully be re-purposed into core engineering roles.
  • The need for dedicated QA leadership also effectively goes away.
  • A handful (1-2 senior people with end-to-end knowledge) of senior QA resources at a principal/architect level (probably reporting into SRE) are needed to own the test infrastructure and coverage end-to-end.
• Management layers can be flattened – the new industry standard for span-of-control in Engineering is 8-12. This can be applied uniformly even with managers of managers.
• Agile ceremonies should be shared between the PM/Sr. Engineer and/or Engineering Manager. Dedicated roles no longer make sense.
• Agentic AI infrastructure requires a dedicated investment. As mentioned above, if this does not receive adequate care and feeding one will be left behind given the rapid evolution of AI technology. Existing Platform teams can be a logical home for the organization’s AI infrastructure and tooling.

Thinking Through the Change Management

To net out the changes:

• Product becomes the new bottleneck; approximately twice as many Product Managers will be required as in the past or Product Managers need to use AI to be twice as productive to run two teams.
• PMs now need to be well-versed in AI tool usage; have a much higher level of technical proficiency; strong data analytical skills; the ability to conduct research via 3rd parties when required; excellent taste in UX design + an ability to follow a design system/user interface guidelines; and be able to build interactive prototypes and validate them with customers.
• PM archetypes will cement around leaders who are strategists prioritizing problems to solve based upon market and competitive needs and opportunities and Builders who will own those problems from cradle-to-grave with the hallmark being replacing traditional PRDs for interactive prototypes.
• With key exceptions, UX’s remit (and teams) will shrink to owning the design system and user interface guidelines + building the AI tools to enable others to build within them and to validate outputs against them. This impacts not only the number of designers but the required management structure.
• The key exceptions for UX include new zero-to-one builds, the additions of new user personae, or rapidly evolving changes to existing user personae, at which point more traditional role needs still exist.
• UX may be a source of talent to help fill the gaps now created within the Product discipline.
• Although the size/shape of an Engineering team will not shift as materially, how it operates will. Operations will need to be totally redefined around agentic AI workflows starting with requirements; transitioning into build/core test; validation and review; deployment; and observability.
• The number of Agile/Feature teams will approximately double given the gains to be realized in terms of output and velocity. Engineering Managers will typically run 2 teams and be considerably more hands-on than in the past given what is achievable with AI tools.
• The QA discipline will shrink to a handful of architect/principal level staff (likely reporting into SRE) responsible for the test infrastructure and ensuring proper end-to-end systems coverage as AI writes and adds to the test suites.
• AI infrastructure and tooling needs dedicated ownership; existing Platform teams are the most logical owners.
• From a R&D perspective, the traditional role of a Data Analyst will largely be replaced by self-service on behalf of a PM interacting with a natural language query engine hosted on top of all systems data. (This may not be the case when supporting other disciplines such as Finance or Go-to-Market.)

To visually summarize:

Figure 3 (above) represents the evolution of the Agile/Feature Teams.

Figure 4 (above) represents the net flattening/optimization of a traditional R&D structure.

Lastly, Figure 5 (above) represents the evolved / go-forward AI-native R&D structure.

As noted in the beginning, regardless of where one is at on their own AI transformation journey – a people end-state needs to be thought about sooner than later given the significant amount of change management involved. From an organizational productivity perspective, the means will justify the ends – but one cannot underestimate the amount of work and change required to get there.