Stage 1: Understand – Building a Generative AI Application Step by Step

ℹ️ This is the first in-depth article in a series in which I describe, step by step and from a product management perspective, how to build a generative AI application in practice. The introductory article on the generative AI playbook gives an overview of all six stages.

In the first article of this series, I presented a playbook for developing LLM applications that describes six stages. In this article, we get down to business: we zoom into Stage 1 – Understand – and I describe in detail what I mean by it and how to approach this step in practice. It’s no coincidence that ‘Understand’ sits at the very bottom of the pyramid model: it is the foundation on which all further stages rest. If things wobble here, you can’t build anything stable on top.

What is this about? Before we build software, before we discuss tech stacks or frameworks, we have to answer a very basic question: can AI solve our problem at all, and what does a good solution look like? That sounds trivial, but it gets skipped alarmingly often. Over the past few years, I’ve seen too many teams experimenting with LLMs somehow without having clearly defined what is actually supposed to come out. You know the result: prompts get rewritten and rewritten, and at some point the initiative is quietly buried because it falls short of nebulous expectations.

So that this doesn’t happen to you, let’s go through the topic step by step. As always: I describe what has worked in my hands-on work. If you see it differently or want to add something – feel free to write to me at jan@produktkraft.com. This series lives on exchange.

First, a bit of grounding: what might examples of simple AI applications look like that this playbook is suited for? I mean products like a chatbot that supports psychotherapists in their work through supervision (and yes, I’m bootstrapping exactly something like that myself right now – take a look at ganzheit-app.com if you’re interested), a data warehouse reporting tool that generates SQL and interprets data, or a sales helper that drafts emails based on CRM data. In other words, products in which a large language model forms the core of the value creation and which are about transforming an input into a useful output.

Why Now Is the Right Time to Experiment

In the overview article, I wrote that in the current phase it’s okay to simply get started and use AI – even if the idealistic product management theorist in me would prefer to see the product vision and the opportunity solution tree first. I want to go deeper into this thought here, because it is crucial for the mindset in Stage 1.

The possibilities of generative AI are changing at a speed I haven’t experienced before in my twelve years of digital product work. What didn’t work six months ago may work brilliantly today. And what is currently state of the art may be overshadowed by a new model in six months. Anyone who forms a fixed picture of what AI can and can’t do in this situation may already be wrong by the next model release.

A practical example: when Anthropic made the leap to Claude Opus 4.5, the world of vibe coding changed fundamentally. Suddenly it was possible to work productively with AI in complex codebases – something that simply hadn’t worked reliably with the previous models. Suddenly vibe coding is no longer just for MVPs and prototypes, but also makes serious engineering work faster (with all the downsides that come with it: 1, 2). Had I had an “I already know what works and what doesn’t” mindset at that point, it would never have occurred to me to even try. And that’s exactly the point: with a technology that evolves this rapidly, experimenting isn’t a gimmick but the only responsible mindset.

But so that experimenting doesn’t turn into aimless trial and error, we need a method. And it starts with a surprisingly simple question.

What Do My Ideal Input and My Ideal Output Look Like?

When I want to develop a simple AI application, the very first step is not an architecture diagram, and it isn’t a prompt either. The very first step is to get clear on two things: what goes in, and what should come out?

That sounds almost too simple, but it is the core of everything that follows. For all their fascination, large language models are statistical models that generate an output for an input. To judge whether that output is good, I have to know beforehand what good looks like. And to provide the right input, I have to understand what information the model needs.

Let me play this through with the three examples.

For the supervision chatbot for therapists, I have to understand what questions therapists typically ask in supervision. Is it about case conceptualization? About dealing with difficult therapy situations? About making sense of symptoms? And then I need to know what a good answer looks like – professionally correct, nuanced, with the right degree of caution on sensitive topics.

For the data warehouse reporting tool, the question is: what questions do my business stakeholders ask? “How did revenue in Q3 develop compared to the previous year?” for example. And the ideal output? A correct SQL statement that uses the right tables and joins, plus an understandable explanation of the results – including the limitations of the data. Because a data warehouse tool that confidently spits out a number without mentioning that the data source for the period is incomplete is more dangerous than none at all.

For the sales helper, the question is: how do excellent salespeople pick up communication with prospects? What tone do they strike? How do they personalize based on CRM data without it coming across as creepy? The ideal output is a drafted email that a good salesperson would send with minimal changes.

You notice: this step has nothing at all to do with technology. It is pure domain work. And this is exactly where there’s a blind spot I want to name explicitly: to be able to define the ideal output, you need expertise in the field you’re building the application for. For the supervision tool, someone on the team has to understand what good supervision is. For the data warehouse tool, someone has to know SQL and the data structure. For the sales helper, you need someone who knows what first-class sales communication looks like.

Without this expertise, you run the risk of being dazzled by the LLM’s eloquent output. Because one thing these models are exceptionally good at is sounding convincing, even when they’re off the mark on substance. The ability to recognize that doesn’t come from the prompt – it comes from your knowledge of the domain.

Your First Evals Emerge Almost in Passing

The pairs of question and ideal answer you’ve just defined have a name: evals. You’ll come across the word again and again in the generative AI world, and it sounds more technical than it is at this point. Essentially, evals are simply test cases: “If I put this in, roughly this should come out.” And for the current stage, they can live in a spreadsheet or a text document. A tip: just add a row for each iteration of your context and prompts.

*Example of a scrappy eval setup in a doc

Think of a work sample in a job interview. You give someone a task and have a picture of what a good solution looks like. Afterward, you can judge whether the person – or, in our case, the model – can do the job. The analogy to test-driven development is also obvious: you first define when something is good enough before you start building.

Don’t worry at this point about how to set up evals systematically or automate them – that will be covered in detail in later articles in this series, especially when we talk about MVP and tech stack in Stage 2 and about the full rollout in Stage 6. For now, this intuitive understanding is entirely enough: you’ve defined what should go in and what should come out, and with that you have your first test cases in hand.

Get Going with AI – But Still Without Code

Now it gets practical. Open a chat with an AI tool of your choice: ChatGPT, Gemini, Claude – at the beginning, I recommend trying all of them, because the models differ quite relevantly in their strengths and weaknesses.

What do you do? Exactly what your application is supposed to do later. Give the model the input your application will have later, and ask for the output your application is supposed to deliver later. In concrete terms: type a typical question into the chat that a therapist, a business stakeholder, or a salesperson would ask, and see what happens.

*Example of a Claude project with attached documents and instructions

Two things are especially important in this phase.

First: work with realistic but anonymized data. If you’re testing a supervision chatbot, don’t dump personal patient data into the chat. For the sales helper, change names and address data in CRM exports. Create anonymous but realistic test data that comes as close as possible to real usage. This isn’t just required by data protection law; it also gives you an early feel for what kind of data your application will have to process day to day.

Second: don’t let the shiny-output effect dazzle you. LLMs always produce texts that read well and sound professional. But the question isn’t whether the answer sounds impressive; it’s whether it matches the ideal output you defined beforehand. Check rigorously against your evals. Is the SQL correct? Is the supervision answer professionally right and appropriately nuanced? Would an experienced salesperson send the drafted email as is? These are the only questions that count.

Then iterate with the prompt and the different models until the output comes close to the ideal. Change the wording of the prompt. Add more context. Give the model a role. Constrain the output format. Try the same thing with another model. In this phase, you learn an enormous amount about what the AI can really do for you – and what it can’t.

Expand and Stay Honest

Once your first input/output pairs work well, it’s time to expand the scope of your tests. Formulate more questions that weren’t part of your first evals. Think of edge cases: what happens if the question is worded unclearly? What if the input is incomplete? What if someone asks something that has nothing to do with the actual use case?

Correct your prompts until you’re satisfied with the answers across this broader set of questions. That will take a few rounds, and that’s normal. A nice side effect: you develop a certain intuition for the jagged frontier of AI.

One point that is often overlooked in this phase: it isn’t enough to get a good answer once. What you have to check is whether the LLM solves the problem consistently. Ask the same question several times. Vary the wording slightly. Because a model that delivers a brilliant answer in one lucky case but misses the mark on the next attempt is of no use for a product application. Deterministic software always does the same thing given the same input – LLMs don’t. You have to keep this property in view from the start.

The First Check: Can AI Solve Your Problem Today?

If you’ve gone through the steps described above and are happy with the results – congratulations! The first check is passed: AI can solve your problem today, at least in principle. You now have a solid foundation for tackling the build of an MVP in Stage 2.

But what if the check fails? If the answers aren’t good enough despite all your prompt iterations? Then ask yourselves honestly whether AI is the right approach for this use case at this point in time. And that is a perfectly okay insight. Better now than after three months of development.

However – and this matters to me – that doesn’t mean the idea is dead. Remember the beginning of this article: the possibilities are changing rapidly. My concrete tip: write down the experiment and repeat it with the next release of a flagship model.

Here, too, a personal example: supervision with clinical cases, exactly the use case of my own product, simply wasn’t good in the LLMs of a year ago. The answers were banal, the models were overconfident, and the professional nuance was missing. Had we given up at that point, the ganzheit app wouldn’t exist today. But with the current models, it works. Not perfectly, but well enough to keep working and iterating. And that is exactly the spirit of this playbook: we don’t build perfect software; we build software that is good enough to get better on contact with reality.

What Comes Next: Stage 2 – MVP & Tech Stack

Once Stage 1 has given the green light, we move on to the exciting question: how do we actually build this? In Stage 2, we talk about which technical aspects the MVP needs, how we make sure we don’t have to run evals by hand forever, and how we keep an eye on costs – because an LLM-based product can quickly get more expensive in infrastructure than you think.