The Development Stages of a Generative AI Application – A Practical Playbook from a Product Management Perspective

ℹ️ This is the first article in a series that will take shape over the coming months. It presents a general playbook for developing generative AI applications. Follow-up articles cover each stage in detail. The first two are already done:
Stage 1 – Understand
Stage 2 – MVP & Tech Stack

Wild times. Generative AI is shaking up the space of what’s possible in digital product development. It’s a hype that in many ways reminds me of the mobile revolution, when the internet suddenly moved into our pockets – and in whose wake, looking back, a lot of worthless software was produced: “Let’s just turn the company website into an app.”

Besides the uncertainty about where to put the new possibilities to good use, I see other parallels too, namely in how polarized the discussions are. Only today, on LinkedIn, in blogs, and among colleagues, the question isn’t whether the desktop computer will be abolished tomorrow, but generative AI extremes:

“Thanks to Cursor, one engineer does the work of an entire team.” vs. “Vibe coding is far from ever delivering production software.” “With AI, I can automate every aspect of my work.” vs. “AI hallucinates and gives me platitudes; I’m faster doing it manually.” “AGI could become reality as early as December and abolish humanity.” vs. “A statistical model that generates the probability of word fragments can’t deliver anything intelligent.”

The truth, however, lies somewhere in between: with large language models, we are dealing with a technology that can without question create value, but that can’t magically solve every problem. I don’t just know this in theory, as someone who understands transformer technology at least at the level of a model, but also in practice, because I have now been involved in six projects that make intensive use of large language models. That certainly doesn’t make me an expert, but I notice that it is sometimes more experience than many a dedicated AI consultant can claim.

Combined with more than twelve years of experience in product management by now, I feel just about confident enough to put a framework for developing AI products up for discussion. Why am I doing this? Well, the simple answer: I want to demystify! With generative AI, it seems, many voices are currently talking more about the latest technology and very few about its practical use in the product. That has often confused me more than it has created focus, so I want to do things differently here. LLMs are statistical models that give us impressive output for an input – let’s put this simple fact to use and not get lost in quasi-religious discussions about AGI (Artificial General Intelligence).

How Do We Approach AI Product Management?

This is the first article in a series in which I describe, stage by stage and from a product manager’s perspective, how to build a generative AI application that uses large language models in practice. In this first article, I describe the approach at a general level. After that, I’ll write further articles that each zoom into the individual stages and describe in detail what needs to be done.

Disclaimer: we are all just figuring out how to use this new technology well, and even though I believe I’ve spotted a pattern here, some aspects may well not stand the test of time. So I ask you to see this article series as a proposal, while I revise it continuously as a living document. A changelog will be listed at the bottom of each article so we can all follow how the approach evolves.

You work hands-on with large language models and want to add points or see things differently? Great! Feel free to write to me, and we’ll see how we can build your observation in! jan@produktkraft.com

In What Ways Does AI Product Management Differ from Digital Product Management for Deterministic Applications?

One important principle to remember: the core principles of good digital product development remain. In my view, the differences lie mainly in the following three detailed questions.

First, you have to be clear about which risks you want to mitigate in your product work. In classic software development, for example, the question is whether a UI is understood. Risk number one in AI product management, however, is whether the AI can solve our problem consistently. So we need methods that answer this question first.

Second, there is the difference between deterministic software – software that is supposed to behave predictably based on clear if-then rules – and software that can surprise us with completely new outputs. In other words, the software does what it wants, and this tension also has to be met with new techniques.

Third, cost control plays a bigger role when we use generative AI. AI may be able to solve our problem, but at infrastructure costs that are ultimately so high that our business case no longer works. A chatbot with 1,000 users a day can quickly cost €500–5,000 per month – far more than a classic web application.

The framework deliberately addresses all three of these aspects while remaining compatible with every other aspect of modern product work. As I said, in this article we start with the overview, and over the coming months the deep dives into the individual stages will follow. All clear? Let’s go!

How Should the Stages of Developing Generative AI Products Be Understood?

Based on what I have experienced in hands-on product work over the past few years, I propose approaching generative AI applications based on large language models in six stages. These should be understood as a pyramid: each stage rests on the one below and adds to it rather than replacing it. The foundation, ‘Understand,’ carries everything else and remains relevant even when you are long since scaling. In practice, this means you work your way up through the pyramid from bottom to top, but you never complete a stage – instead, more simply gets added. See the diagram as an idealized orientation that helps reduce complexity, especially at the start, and by no means as a rigid framework.

I’d also like to state up front that this model focuses on developing applications that use large language models. Parts of it may also make sense for other generative AI applications or even discriminative AI, but I am explicitly not looking at those here. Furthermore, this is not about how AI tools can change the work of a product manager; the full focus is on the product.

Playbook for Developing LLM Applications

Stage 1 – Understand

The idealistic product management theorist in me sometimes feels drawn to a structure in which you always start with the problem. A clear product vision sets a direction, an explicit strategy narrows the room for maneuver, and opportunity solution trees create an overview of all possible solutions. Only after a few experiments do we decide on the solution with the best chance of being really good – regardless of the tech stack or whether someone had a specific feature idea early on. But I also know that reality looks different. Especially in the current phase of the hype cycle, many organizations simply say, “Let’s use AI,” without it being clear why.

Here’s my hot take: at this point in time, that’s okay as a starting point! Only through practice and experimentation can we learn which problems generative AI solves well and which topics it isn’t suited for. So let’s get our hands dirty, even if in some cases it’s questionable whether the problems couldn’t be solved without AI as well.

However, you at least have to understand what the AI is supposed to do and what a good outcome looks like in order to work in a targeted way. Over the past few years, I have talked to too many teams that use AI somehow to achieve something or other. The result: prompts get rewritten and rewritten and rewritten, and at some point the AI initiative is stopped because it falls short of nebulous, undefined expectations.

As always in digital product development, we start by understanding a problem space, focusing on one problem, and formulating ideas for a solution. The difference from traditional digital product development, though, is that we don’t sketch the idea as a PRD (product requirements document) or wireframe, but as a desired input/output combination from a large language model.

So you might sketch, for example, the running text of an ideal conversation with a chatbot or an ideal JSON file to be produced from unstructured text. Conveniently, these are your first evals, and, much like the approach of test-driven development, they can serve as the basis for seeing when our software is good enough.

Learn More

Stage 2 – MVP & Tech Stack

Once it’s clear what you want to solve, the next step is for a cross-functional team from product and engineering to build a prototype for validation. When building probabilistic software, two topics are especially relevant: can the AI handle your case at all, and what are the costs? You can test both with the internal dev tools of the common LLM providers: write prompts you would also use in the software, look at the responses, and watch the costs so you can project them.

Once you have a green check mark there, it’s time to build a first version of the generative AI application or feature. For the most part, the same rules apply here as for any MVP. A few special considerations should be kept in mind, though, so that you can iterate quickly. Specifically, software for observing inputs and outputs (traces), user feedback on responses (human annotations), and prompt management should be implemented right away.

There are many comparable large language model engineering platforms that provide this functionality, and most of them are quick to integrate. I have personally had good experiences with Langfuse, but LangSmith, Lilypad, LangWatch, and Lunary are also said to be good. Even if it’s tempting to skip the integration for the MVP: I assure you that this usually small investment is worth the time. Because only if you can see what your users write, can assess the quality of the responses, and can adjust your prompts quickly can you learn and develop in a targeted way.

Learn more

Stage 3 – Internal MVP Test Run

The team that developed the MVP tests its own software with clear hypotheses and won’t have many of the things people type into open systems on its radar at all. An example: the app from my own startup is supposed to answer questions about psychotherapy, but at first it was also happy to weigh in on how tall Hamburg’s TV tower is. You can anticipate many of these early traps with members of your own organization or with friends.

This step also produces more evals, because real usage introduces you to the first edge cases, which call into question the alignment you thought was correct.

Only when a clearly set success target is met – for example, 70% of the manually managed evals or 95% of user interactions going well – should external testers use the product.

Stage 4 – External MVP Test Run

Next, you should get a group of real pilot users actively using the product. What matters is not just whether they use the app; their behavior should be captured in detail so you learn as much as possible, as quickly as possible. In concrete terms: read your users’ conversations and conduct qualitative interviews. AI won’t help you here! You have to build product sense for your generative AI software, and that only works if you know the real conversations and understand empathetically what using it feels like. Anyone who wants to sell you a magic prompt is lying. But look at it positively: by reading the traces, you are much closer to your users’ sessions than we are used to with deterministic software.

Stage 5 – Building GenAI Operations

If the test usage from the external MVP test run works well, you should build out the operations behind your feature properly in preparation for the big launch. In concrete terms, that means modularizing your prompts based on what you’ve learned, using playgrounds for faster prompt engineering, considering A/B testing, and, by now at the latest, separating prompt deployment between staging and production systems. This foundation will help you handle the complexity of the broad rollout better.

At this stage, it’s important to keep a cool head and use every tool the LLM toolbox provides. Just as not every domain necessarily needs its own microservice, or every aspect of an app needs test coverage, not every project needs to use the full range of generative AI.

Stage 6 – Full Rollout & Scaling

The top of the pyramid: full launch! In the final step, you need LLM-as-a-judge evals, because thanks to broad usage you will hopefully no longer be able to read every conversation yourself. On top of that comes the problem that, in long-term operation, you will go through model upgrades every now and then, and automated evals are worth their weight in gold for those as well.

As the application rolls out to many users, cost optimization also needs more attention, which brings the deliberate use of different LLMs and the corresponding model routing into focus.

In Summary, What Matters in Developing Large Language Model Software?

I’ll say it again: at the level of principles, nothing has changed with generative AI. Digital product management still means that we have to understand a problem and then, in the fastest possible feedback cycles, find a solution that works for users and for our business. Define your goal and head for the build-measure-learn cycle so you can iterate in contact with reality. The only difference is that there are other risks to consider, other methods are needed for QA, and the cost structure has changed.

The framework above is now my guiding principle, the one that has so far served me best in meeting the other challenges. If you know an even leaner and more focused way from your own practice to approach generative AI applications in product management, please get in touch – jan@produktkraft.com – I look forward to the exchange and to learning together!

What Comes Next

As I said, we as an industry are only just learning how to build applications based on large language models effectively and efficiently, and it’s quite possible that the process I’ve described overlooks individual aspects that matter in your work. So I’d first like to wait a few weeks, collect feedback on this structure, and incorporate it where needed. After that, I’ll start writing six more articles, each going into detail on the individual steps.

I hope this post helps especially those of you who haven’t yet built a full AI application to gain a better understanding of what it looks like in practice and not to get lost in buzzword bingo.