From PRDs to Prompts

For most of my career, which has been quite some time it hurts me to say, product development followed a fairly predictable rhythm. An idea would emerge, a Product Manager would write a detailed PRD, designers would produce polished UI mockups, engineering would break the work into stories, and eventually development would begin. Weeks or months later, a feature would ship. The process was deliberate and methodical, and while it wasn’t always fast, it provided structure and alignment.

That model served the industry well for a long time. But it was built on a reality that is beginning to change. That reality was, that writing software is expensive and slow.

With the rise and rapid evolution of AI code generation tools, that reality is rapidly fading away. When tools like Claude Code, Cursor or similar systems can produce working code in minutes, the cost and effort of creating a prototype drops dramatically. And once that happens, the entire logic behind the traditional Product Development Lifecycle (PDLC) starts to shift.

Over the past few weeks, our team has begun experimenting with what I would describe as an AI-assisted PDLC. It’s still evolving, and I’ll admit there are moments where it feels both exciting and a little unsettling. But the early signals suggest that AI will fundamentally change how product teams move from idea to working software.

The most visible change is that the heavy front-end planning process begins to fade away. In the traditional model, a significant portion of the work happened before a single line of code was written. We invested enormous effort in documentation. PRDs, detailed story breakdowns, full UI designs, backlog grooming sessions, all designed to reduce ambiguity before development began.

But when code generation becomes nearly instantaneous, that kind of front-loaded planning becomes less necessary.

Instead of trying to perfectly describe a product before building it, teams can now explore ideas directly in working code. The process becomes much more iterative and, frankly, much more experimental. An idea is fed into an AI code generator, and a working version of the concept appears quickly. The team then evaluates that output together.

Product reviews the solution to determine whether it actually solves the user’s problem. Engineering examines the output for architectural soundness, scalability, and code quality. Design evaluates the experience from a usability and interface perspective. The feedback from those reviews is then fed back into the AI system to refine the solution. The cycle repeats until the product reaches the level of quality needed for release.

In many ways, the process resembles a loop rather than a pipeline. Instead of spending weeks describing a solution before development begins, we are rapidly generating, reviewing, and refining working software.

One engineer jokingly described the shift as “ready, fire, aim,” and while that might sound reckless at first, the reality is more nuanced. The reason this approach works is because the cost of experimentation has dropped dramatically. If a generated solution doesn’t work, we can throw it away and the cost of doing so is minimal.

In the past, abandoning an implementation meant writing off weeks of engineering effort. Today, discarding a prototype that took minutes or hours to generate barely registers on the timeline. That dramatically lowers the risk of experimentation and encourages teams to test ideas more aggressively.

This reduction in cost changes the economics of product development. Instead of carefully protecting engineering capacity, teams can explore multiple directions quickly, learn from what works, and move forward with greater confidence. In many cases, the fastest way to determine whether an idea is viable is simply to generate it and see how it behaves.

Another interesting side effect of this shift is the increasing value of generalists.

For years, product organizations have grown increasingly specialized. Product managers defined requirements, engineers built systems, and designers crafted experiences. Each discipline played a crucial role, but the work was often segmented into distinct phases.

In a fast, iterative AI-driven process, the boundaries between those phases begin to blur. The individuals who seem to thrive most in this environment are those who understand multiple parts of the system. Someone with experience in product thinking, engineering constraints, and design principles becomes incredibly valuable. They can translate a problem into a prompt, evaluate the generated output, identify usability issues, and recognize architectural concerns all within the same cycle.

That kind of cross-disciplinary awareness allows the team to move faster without sacrificing quality. It doesn’t replace specialists, but it helps connect the loop between disciplines.

Perhaps the most obvious benefit of this new approach is speed. When working code can be generated quickly, iteration cycles shrink dramatically. What might once have taken weeks of development can now be explored in hours or days. Conversations become more productive because they revolve around actual working software rather than hypothetical descriptions that turn into multi-meeting wrestling matches.

But while development speed increases, another reality quickly emerges: shipping code faster creates pressure everywhere else in the organization.

If product teams are producing features at a much faster pace, the downstream parts of the business must adapt as well. Enabling internal teams, writing documentation, and preparing support resources can easily become bottlenecks if they are still operating at the pace of a traditional development cycle. The same is true for marketing and communication. If new capabilities appear rapidly, the organization must figure out how to introduce them in a way that customers can absorb. Otherwise, the product evolves faster than the story around it.

Customer fatigue also becomes a real concern. Rapid iteration is valuable internally, but customers don’t necessarily want their tools changing every week. Product teams need to think carefully about how frequently visible changes are introduced and how those changes are communicated. Just because something can ship quickly doesn’t always mean it should.

In many ways, adopting an AI-assisted PDLC isn’t just a development shift. It’s an operational one. Faster development requires faster enablement, faster documentation, faster communication, and thoughtful pacing so customers can keep up with the product.

These are all considerations we are actively thinking through as we experiment with this new model.

I should also acknowledge that the transition isn’t without apprehension. Traditional development processes existed for a reason. They created structure, predictability, and alignment across teams. Moving toward a more iterative and experimental model can feel messy at times, especially early on.

Questions naturally arise about maintaining architectural discipline, ensuring quality, and avoiding the trap of building the wrong things faster.

But every major shift in how software is built has required teams to rethink their processes. Agile challenged the rigidity of waterfall. DevOps changed how we approached deployment and operations. AI may now be forcing us to rethink the entire development lifecycle itself.

If there’s one observation that feels increasingly clear, it’s this: the role of product teams is shifting.

In the past, a significant portion of the work involved describing software so engineers could build it. Today, AI can generate much of that software directly. The human role increasingly becomes evaluating whether the solution is correct, whether it solves the right problem, creates the right experience, and can scale in the real world.

In other words, the PDLC is becoming less about producing code and more about evaluating and refining solutions.

We are still early in this journey, and our process will undoubtedly continue to evolve. But the direction feels clear enough to say this:

The future of product development will not be defined by how carefully we plan software in advance. It will be defined by how quickly we can generate it, evaluate it, and learn from it.

Thanks for reading.

All the best

Mike