What is the modern product development lifecycle?

I hear this story every single day: “We’ve rolled out Claude, Codex, Cursor, and Copilot, and nothing sped up. Individual engineers have seen large leaps in productivity, but at the end of the day, we’re not shipping faster, and the work they’re doing is not hitting the bottom line in a meaningful way.”

Or, as one CTO put it more bluntly:

So what happened? Where is the Dark Factory running on infinite intelligence? Whither the Twitter bros who spin up 1,000 agents to run their business while they nap in a hammock?

This problem is endemic to organizations collaborating on software, and the problem is simply that bringing software to market is about more than how fast you can generate code. That is certainly one challenge of a scaled software team, but it is not where the majority of the energy goes, and certainly not today.

There’s no magic trick here. I’ve written about this a number of times, but in six years of fractional product leadership, working with more than 20 companies, I cracked the code on the why of software development.

1. 1 Organization Who are you, who are your customers, why are you competitive, and why do they like you?
2. 2 Goals Where do you need to be in the next three to six months, or however far out you can project? Increasingly, that horizon is shorter and shorter.
3. 3 Roadmap The roadmap is a reflection of company goals. What does the product need to look like over that time span to do what we need it to do?
4. 4 Refinement Research, metrics, collaboration, putting out fires, understanding customer needs at a micro and macro level, talking to people. All of the squishy human work that goes into building the right thing, including discussions with compliance, legal, infra, and the other teams that own critical pieces of infrastructure.
5. 5 Specification Breaking projects into individual tasks.
6. 6 Build Build, QA, delivery, iteration, scale, measurement.
7. 7 Go to market Coordination with marketing, sales, customer support, the exec team, BD, platforms, and dev rel. Getting the attention important initiatives need to make the most impact.

Woven through all of this, every cycle is iterative. You can go from step five back up to step one.

You can spend months in step four making sure you understand exactly what you need to do. And everything can be sidelined by a new fire drill, a new customer, or a new competitor.

A team of 2,000 might have:

• 1,000 engineers
• ~200 product people
• 800+ supporting the operations to run this system

None of this is to say the SDLC is easy, or that it is entirely subsumed into step six. Suffice it to say it is a tangential set of tasks and goals. Coding agents don’t alleviate or drastically improve the other steps of this process. If anything, they put more pressure on it, leading to:

Sped up

6 Build Code, written by agents

Landed on everyone else

• More asks for the data team to pull numbers
• More requests to talk to customers
• More time spent with compliance and legal
• More coordination and status reporting
• More phone calls
• More needs

They’ve stressed a system that was designed to be deliberative in a world where software development was scarce. Add the external pressure of competition from AI-native teams doing AI-everything, and product managers, designers, and teams are more stressed than ever. Longer hours for what feels like the same, or incrementally improved, results.

To go forward, I think it’s easiest to look back. Where did coding agents start impacting the SDLC? Copilot is not a new invention. Initially, velocity came from filling in boilerplate, based on an understanding of the types of work software developers do. The humble tab. Tabbing through boilerplate became standard engineering practice and drove much of the early success of companies like Cursor.

The tab

1. I Engineering time is the constraint
2. II Early adopters build their own setups
3. III A dedicated team leads adoption
4. IV AI adoption goes company-wide
5. V The company redesigns how work gets done
6. VI Product teams run on the new model
7. VII Strategy develops across the company

Stage I. Engineering time is the constraint

Every change moves from execs to product leads to PM to eng lead to engineers, with a person reviewing at each handoff. Engineering hours set the pace.

Stage II. Early adopters build their own setups

Individual PMs and engineers pick up agents on their own. The handoffs and the reviews stay exactly where they were.

Now, we shouldn’t take this literally to mean we’re going to be tabbing through PRDs. You can already generate basic boilerplate PRDs pretty effectively with Claude Cowork. Of course, I would strongly advocate having long-form discussions with your agents before you do anything like that, lest you end up in a world of PRD slop and, worse yet, strategy slop.

The why behind the tab interface, and the value created by early versions of Cowork, is that they took drudgery away from engineers. The annoying stuff, they could do pretty effectively.

When we look back at the stack of things PMs do every day, a lot of it is:

1. 01 Status reporting
2. 02 Explaining to my manager what’s going on
3. 03 Explaining to my peers what we’re working on
4. 04 Justifying increased spend
5. 05 Educating the field
6. 06 Working with customer support

For my own part, I twice made the move from sales engineer to product management. The first time, as an SE, I was constantly pushing the product team for new features and capabilities, trying to deliver as much important messaging from the field as I could so the PM team would be as informed as possible. I was frustrated by how slowly the product organization often responded when the needs of the field felt so acute to me.

I vowed then, as I moved from sales engineering into product management, that I was going to be the PM who answered every email. Not realizing that two months later we’d be bought by a global organization, I would wake up every day to over 350 emails, all directed at me, asking questions about the product and what to do. Of course I did my best, but that effort isn’t sustainable. It doesn’t scale, which is why product people try to create systems of communication with the field, so they can have structured input.

350+ emails a day, asking about the product and what to do

Let’s just say Slack nuked a lot of those systems, because it’s much easier to send a DM than to work through an official channel to get the right response. As I always assumed as an SE, getting that information to the field has real value. Getting it to the place where it can be communicated to customers helps close deals, minimize churn, and decrease support load.

The product team doesn’t scale like that.

The simplest starting point for the modern PDLC is scalable context over the build:

Provide that interface, and it can sit between the product organization and the rest of the team, helping them scale in a way that is critical to the organization.

The context era

Stage III. A dedicated team leads adoption

An AI adoption team forms with a dotted line to the execs. It builds prototypes, but has no mandate to change how product, engineering, or risk work.

Stage IV. AI adoption goes company-wide

Agents show up in every team. The work now piles up at the same review gates, waiting on people.

Stage V. The company redesigns how work gets done

The longest stage. Review gates become rules that agents check on every change. Material decisions go to a named owner, routine ones stay with the team. Context is pushed into the ticket, the PR, and the meeting instead of searched for.

Next, where did agentic software development go? To larger tasks, larger generation, larger functions and files, and the ability to handle broader context with human guidance.

Mapped to the PDLC, that means a better understanding of, and ability to work with, company strategy decisions and trade-offs. A deeper understanding of the environment in which we operate, and being a better partner in the day-to-day work that drives it.

Now we are in the context era, where agents are expected to work on larger swaths of product, given appropriate specs, tools, MCPs, CLIs, loops, and graphs.

Of course, the PDLC has just as much necessary context as the SDLC, if not more, but it’s much more diffuse. It lives in customer calls the CS team did, and calls the sales team did. It comes from executives and the overall strategy. It’s in review meetings, feedback on Jira tickets, documents, drawings, and whiteboards. Oh my.

Where it lives today

• Customer calls
• Review meetings
• Executive strategy
• Whiteboards
• Jira ticket feedback
• Documents
• Sales calls
• Drawings
• Slack DMs
• Emails

Where it belongs

1. 1 Organization Customer calls
2. 2 Goals Executive strategy
3. 3 Roadmap Documents
4. 4 Refinement Review meetings, Whiteboards, Slack DMs
5. 5 Specification Drawings
6. 6 Build Jira ticket feedback
7. 7 Go to market Sales calls, Emails

This isn’t just a data retrieval problem. It’s a data categorization problem: not only being able to search and find everything across all these documents, but putting each piece in its proper place relative to the process of delivering product, so it’s drawn out at the right moment.

It’s understanding the trade-offs we have, the decisions we’ve made, when to act on them, when we can ignore them, and what we need to add to them. We need a system that isn’t just for storing and retrieving files, but can think through the issues, suggest alterations, and push back appropriately. One that lives within the context of the organization, rather than dropping in from time to time with PMs prodding it into the shape it needs.

Multi-agent coordination

Stage VI. Product teams run on the new model

A planning group sets the plan. Product teams, each a lead working with agents, ship through agent checks, and a named owner signs off only the exceptions.

Stage VII. Strategy develops across the company

Anyone, people or agents, can propose. Proposals flow back to the execs who decide, and the work ships through the same agent checks.

And finally, where the SDLC is going. What we hear and understand of the future is multi-agent coordination systems: much broader, deeper context and understanding across many codebases, many libraries and functions, and many types of agents with different specializations. A world model of software development that can not only understand the state of the world today but predict outcomes in the future.

For the PDLC, this means a system that doesn’t just respond, catalog, and understand, but can be a thought partner in developing and delivering product strategy, communicating with the rest of the org, and handling the drudge work required to coordinate a large organization’s ability to ship great software.

It’s predictive. It makes recommendations and models what the world would look like across different iterations of the product’s capabilities. It pushes these back to the users. It orchestrates documentation and coordination with multi-agent orchestrators, judging and refining its understanding all the way from executive strategy through the roadmap, individual projects, tasks, research, iterations with coding agents, QA, metrics, and the GTM motions of sales, marketing, and support.