Redesigning the Product Development Lifecycle with AI

There is so much talk in my product community, with my friends and family who work in different industries, about using AI tools and AI SaaS products to work faster or more efficiently.

There is an overload of questions and debates, with tensions like these:

• Where should we start first: operational workflows, client reporting, product development or engineering?
• We are not ready; our data foundations aren’t great, but we're under pressure to meet efficiency targets.
• We have a lot of great systems and SaaS products already; can’t we build our own AI layer on top?
• Some SaaS products have already done the intellectual heavy lifting and can integrate our data; isn’t it better to choose them?

It is natural to want to start with the tools rather than spend time looking at the process or workflows.

Google’s 2025 DORA research on AI-assisted software development surveyed nearly 5,000 technology professionals and describes AI as an amplifier. It found that strong teams can use AI to become better, but it can also magnify problems that already exist. In other words, if the process isn't very good to begin with, AI may simply help you do the bad process faster.

And that potentially gives you two challenges; you could be taking on changing the process and introducing AI at the same time. That’s a lot of change to land with people who already have a day job. DORA also found that while AI was helping teams produce more and improve product performance, software stability could suffer. More change, produced faster, puts more pressure on everything around it.

Which raises another question. What happens if you accelerate one part of the process and not the other? If engineering can suddenly build and test code much faster, but discovery, experimentation and writing good specifications don’t get any faster, have you improved the whole process or just moved the bottleneck somewhere else?

There is also a translation problem in product development. A customer says something. Research interprets it. A product manager pulls together the research and data and turns it into a specification. A designer interprets that. Engineering interprets it again. QA needs to understand what everyone meant in the first place.

Every time the work moves, some of the original context has to be interpreted, summarised and passed on. And think about how much time goes into finding and discussing that context in the first place.

If I am writing a product specification, I might need customer research, analytics, commercial information, competitor evidence, previous product decisions and technical constraints. That information is probably sitting across different systems, documents and people's heads.

This is where organisational knowledge and context become really important. AI can help write a new specification with the relevant history behind it, cross-reference competitor activity against your own customer and product data, explore possible future scenarios or check decisions against company policies.

And this is where specialist AI SaaS products become interesting. You are buying access to an AI model where someone has already done a lot of the thinking about the workflow, integrations, context and job you are trying to get done, ready to integrate your company data.

I don’t think every company needs to build its own AI layer from scratch. I think the right question is to look at the processes in your operating model and ask: Where in our existing process could AI genuinely make the biggest difference first? I think you would be crazy to tackle the whole thing at once.

Map how the work happens today. Where is the biggest value being lost today, and where could the biggest value be gained? Where are people waiting, searching or repeating work? Where does context get lost? And get a baseline. How long does the work take today? Where is that time going? What does good look like now? Then pick somewhere meaningful to start and experiment.

And look at what happens to the whole process, not just whether the AI tool made one task faster. Did the overall work take less time? Did the quality improve? Did the bottleneck move? Did you introduce a new risk? Where did you still need human judgement?

The canvas below is how I've been trying to make sense of this. Section 7 starts with the work and where value is being lost, not the AI tools. I think the trick is to look at the whole system, but don't try to change the whole system at once.