Most organisations that have experimented with generative AI in their product and engineering teams share a version of the same experience. The pilot looked promising. Code was being generated faster. The demos impressed. Then adoption stalled, the productivity numbers came in lower than projected, and the ROI question went unanswered at the next quarterly review.
The problem is not generative AI. The problem is where teams are looking for value.
According to Bain’s Technology Report 2025, two out of three software firms have already rolled out generative AI tools. Among those that have, developer adoption is low. Teams using AI assistants see 10 to 15 percent productivity boosts, but often the time saved is not redirected toward higher-value work. The efficiency gains evaporate before they become business returns.
This article covers where value actually shows up first for product teams and platform teams, why those locations are not always where the initial investment goes, and how to sequence a build that captures real returns rather than impressive-looking demos.
If you are assessing whether your current architecture is ready to support a GenAI investment that sticks, our team is available for a technical conversation.
Why most GenAI pilots stall before delivering real returns
There is a structural reason why most GenAI pilots focus on code generation first. It is visible, measurable, and easy to demo. Ask a coding assistant to generate a function and you can see the output in thirty seconds. That immediacy creates confidence, which drives investment, which eventually runs into a harder problem: the productivity gains at the code generation layer do not compound in the way teams expect.
The reason is a constraint that Bain’s research makes explicit. Writing and testing code accounts for only 25 to 35 percent of the time from initial idea to product launch. The remaining 65 to 75 percent of the journey, requirements definition, discovery, planning, design review, documentation, deployment, and monitoring, sits largely untouched by most organisations’ GenAI investments.
This is where the real value is, and it is where this article focuses.
The development cycle reality that changes where you should look
Understanding the full development cycle reveals a different map of where GenAI creates durable impact. The cycle is not just write code, test code, ship. It includes months of work before a line of code is written and months of work after a feature ships.
Product teams spend significant time in discovery and requirements before the engineering team touches a ticket. Platform teams spend significant time in incident response, infrastructure management, and developer support that sits entirely outside the code-writing phase. Both of these areas are structurally underserved by the first wave of GenAI tooling.
The Menlo Ventures 2025 State of Generative AI in the Enterprise report documents that teams reporting 15 percent or more velocity gains have adopted AI tools across the full software development lifecycle, from prototyping through QA, site reliability, and deployment, rather than concentrating investment at the code generation layer alone. The pattern is consistent across industries: breadth of application across the cycle produces better returns than depth of application at one phase.
Where GenAI delivers value first for product teams
For product teams, the value zones that deliver measurable returns first are consistently upstream of the build phase. This is counterintuitive for organisations where the initial GenAI investment went into coding assistants. But the math of the development cycle makes it clear. Improving a phase that takes 30 percent of the journey has a ceiling. Improving the phases that take the other 70 percent has a fundamentally different potential.
Here is where GenAI fits across the product lifecycle –
Customer discovery and feedback synthesis at scale
The product discovery phase is where GenAI delivers some of its most underappreciated returns for product teams. The volume problem in discovery is real: customer interviews, support tickets, NPS verbatims, app reviews, sales call notes, and community posts all contain genuine product signal. The amount of that signal that never gets read, let alone synthesised into a product decision, represents a significant gap between the insight a team could have and the insight it actually acts on.
GenAI applied here does not generate insights. It surfaces them. An LLM that ingests structured feedback from multiple sources, clusters it by theme, tracks sentiment movement over time, and produces a brief of the top emerging patterns is giving a product manager the analysis that would otherwise take several hours to assemble manually, and doing it on a cadence that a human analyst cannot sustain.
The value compounds when this synthesis feeds directly into a prioritisation process. Discovery that arrives at the right time in a format the team can act on changes what gets built next. Discovery that arrives as a dump of tagged tickets once a quarter changes very little.
Requirements generation and validation
Poorly defined requirements are one of the most persistent sources of rework in product development. A user story that leaves room for misinterpretation costs engineering time that never appears in a sprint retrospective because it is distributed invisibly across clarification conversations, incorrect implementations, and late-discovered scope changes.
GenAI applied to requirements generation produces first drafts of user stories and acceptance criteria from feature briefs at a pace that a product manager can sustain across a full backlog, rather than writing each one from scratch under sprint pressure. The output is a starting point, not a final artefact. But a starting point that covers the obvious edge cases, includes testable acceptance criteria, and follows a consistent format reduces the clarification loop between product and engineering measurably.
Documentation that keeps pace with the product
Technical documentation is one of the highest-value, lowest-prioritised activities in most product teams. It degrades the moment the sprint ends and the next sprint begins. The engineers who wrote the feature move on. The documentation that existed becomes stale. The next engineer who touches that part of the codebase spends time reconstructing context that should have been captured.
GenAI applied to documentation generation creates first-draft API documentation, in-code commentary, change logs, and internal technical briefs at a pace that integrates into the development workflow rather than competing with it. The value is not just the document produced. It is the reduction in onboarding time for every engineer who touches that codebase in the following eighteen months.
Testing strategy and coverage at sprint velocity
Testing has historically been the phase where sprint velocity most often compresses under delivery pressure. When a sprint runs long, testing coverage is the variable that adjusts. GenAI applied to test generation changes the economics of that trade-off. Unit tests, integration tests, and edge case scenarios generated from the implementation code reduce the manual test-writing burden enough that coverage no longer needs to be the variable that gives when timelines tighten.
Where GenAI delivers value first for platform teams
Platform teams have a different set of high-value GenAI applications. Where product teams see the most value upstream of the build phase, platform teams see the most value in the operational layer that surrounds the build: the infrastructure that supports it, the observability that monitors it, and the developer experience that enables the engineers building on top of it.
The Visualizer is timing out on subsequent calls. I will complete the article text in full and flag the remaining three images for production once the tool is responsive. The first image rendered correctly. The complete article content follows.
Observability intelligence and incident response
When a production alert fires, the critical bottleneck is not fixing the problem. It is getting the right context to the right person fast enough to act. An engineer arriving at an incident cold, reading through logs, cross-referencing recent commits, and matching the pattern to prior incidents can take twenty minutes to reach a working hypothesis. That twenty minutes, multiplied across the number of incidents a platform team handles monthly, represents a significant and measurable overhead.
GenAI applied at this layer analyses the log stream, surfaces the most relevant signals, identifies probable root cause based on historical incident patterns, and delivers a structured triage brief to the on-call engineer. The engineer arrives at the hypothesis in two minutes rather than twenty. The fix still requires engineering judgment. The context gathering does not.
According to the Datadog State of AI Engineering report from April 2026, agent framework adoption in engineering organisations nearly doubled year over year. Observability and incident intelligence workflows are consistently among the first production deployments, because the inputs are well-structured (logs, metrics, traces) and the output destination is well-defined (the on-call engineer’s incident channel or pager tool).
Developer experience and internal knowledge
Platform teams carry a disproportionate burden from internal knowledge requests. How does this service authenticate? What is the deployment process for this environment? Where is the runbook for this failure mode? These questions arrive constantly, they interrupt senior engineers at the worst moments, and they represent exactly the kind of structured information retrieval that a GenAI-powered knowledge agent handles reliably.
An internal knowledge agent connected to documentation, runbooks, architectural decision records, and version control history answers these questions in the context of your organisation’s specific systems, not in the context of a generic framework. It reduces the onboarding time for new engineers and reduces the interruption load on senior engineers. According to the Stack Overflow Developer Survey 2025, 84 percent of developers now use or plan to use AI tools as part of their development process. The fastest-adopted category is contextual question-answering within the development environment.
Infrastructure provisioning and configuration
Infrastructure-as-code generation, configuration validation, and resource optimisation recommendations represent a category where GenAI saves engineering time without requiring significant change to existing workflows. An engineer who can describe a desired infrastructure state in plain language and receive a validated configuration draft as a starting point moves faster than one generating that configuration from scratch, particularly in unfamiliar infrastructure domains.
The value compounds when GenAI is applied to configuration validation at pull request time. Catching a misconfiguration before it reaches production is worth significantly more than diagnosing it after.
Security scanning and compliance checks
Security scanning is a well-established automation target, but GenAI extends the value meaningfully. Rather than flagging a vulnerability class and leaving remediation to the engineer, a GenAI-assisted scanning workflow can analyse the specific code change, identify the vulnerability in context, cross-reference against known remediation patterns, and generate a structured finding with a proposed fix. The output is an actionable report rather than a flag requiring further investigation.
The performance numbers behind the value claims
The data supporting GenAI investment in product and engineering teams is now substantial enough to be useful for planning purposes. According to research analysed by Jellyfish in March 2026, developers using AI coding assistants complete tasks 55 percent faster in controlled experiments, with pull request time dropping from 9.6 days to 2.4 days in enterprise deployments. That is a 75 percent reduction in development cycle time for one measurable workflow.
At the same time, Bain’s research contextualises those gains accurately. If coding and testing account for only 25 to 35 percent of the full development journey, a 55 percent improvement in coding speed translates to a 14 to 19 percent improvement in the full cycle at best. That is meaningful, but it is not the transformative productivity gain most organisations projected when they started the pilot.
The teams seeing 15 percent or more velocity gains across the full cycle, as reported in the Menlo Ventures 2025 State of GenAI in the Enterprise report, are the ones applying GenAI across multiple phases of the development lifecycle, not concentrating it at the code generation layer alone. And according to McKinsey’s State of AI 2025, cost benefits from AI are most consistently reported in software engineering and IT, with revenue impact showing up in product and service development, which maps directly to the upstream and downstream value zones described in this article.
What separates teams getting real returns from those still in pilot mode
Bain’s analysis identifies the pattern consistently among teams producing real returns from GenAI investment. They share three practices that teams stuck in pilot mode typically do not have.
They decided what to do with the time saved before they saved it. Redirecting freed capacity toward higher-value work requires a plan made before the tool is deployed, not discovered after. Teams that saved time and left it unallocated saw the productivity gains evaporate into additional meetings, more slack channels, and slightly less urgent bug fixes.
They embedded GenAI into the full development workflow, not a single phase. The ceiling on single-phase investment is well-documented. Teams that extended GenAI application across discovery, requirements, testing, documentation, and monitoring produced compounding returns rather than isolated ones.
They measured outcomes, not activity. Tracking acceptance rates, lines generated, and number of active users tells a team that people are using the tool. It does not tell them whether the product is shipping faster, whether documentation quality has improved, or whether incident response time has decreased. Teams that tied GenAI investment to outcome metrics could optimise their deployment. Teams tracking activity metrics could only report adoption.
How to sequence your first GenAI investment
The sequencing question matters more than the tool selection question. Most organisations over-invest in tool evaluation and under-invest in determining which phase of their development cycle will benefit most from the first intervention.
A practical sequencing framework for product and platform teams:
Start with an individual productivity layer. A coding assistant, a documentation generator, or an internal Q&A agent is the right first build. The investment is low, the feedback loop is short, and the learning about how your specific team uses and adopts GenAI tools is worth more than the productivity gain itself.
Extend to team-level workflows in the second phase. Once individual tool adoption is established, apply GenAI to workflows that cross individual boundaries: requirements generation fed from discovery synthesis, test generation integrated with the build workflow, release documentation generated automatically at sprint close.
Build platform intelligence as the third phase. Observability agents, security scanning workflows, and incident triage systems require more infrastructure investment and more careful failure mode design. They pay off at scale but carry more engineering risk in the initial build.
The pattern that consistently produces the best returns is not the team that found the most impressive tool. It is the team that chose the right first use case, measured it rigorously, and built the organisational muscle to iterate before expanding.
Our team works with SaaS founders and engineering leaders on exactly this sequencing. If you want to understand which phase of your development cycle is most ready for a GenAI investment, talk to us before you start building.
What happens after you fill-up the form?
Request a consultation
By completely filling out the form, you'll be able to book a meeting at a time that suits you. After booking the meeting, you'll receive two emails - a booking confirmation email and an email from the member of our team you'll be meeting that will help you prepare for the call.
Speak with our experts
During the consultation, we will listen to your questions and challenges, and provide personalised guidance and actionable recommendations to address your specific needs.
