When is a feature, a user story or a function good enough to be put into production? Anyone who has grown up with traditional software projects instinctively turns to checklists, acceptance criteria and status reports. But generative AI systems do not operate deterministically. They behave. And this behaviour cannot simply be ticked off a list.
For us, this represents a shift that runs deeper than it might initially appear. The central guiding principle is no longer ‘finished’, but ‘good enough’. This article explains what that means in practical terms and outlines the measures that help us make good decisions in the face of uncertainty.
There is one question that runs through almost every AI project. Sometimes it is asked out loud – during a review, at a stakeholder meeting, or occasionally even in the corridor. Most of the time, however, it remains unspoken, yet still hangs over everything: When will we actually be finished?
Anyone familiar with traditional software projects has a well-rehearsed answer to this. When all requirements have been met. When the acceptance criteria give the green light. When the checklist has been ticked off. This answer has worked for years because it was designed for systems that operate deterministically: a function either does what it’s supposed to do, or it doesn’t. Right or wrong. Done or not done.
Generative AI isn’t interested in this logic.
An AI system does not produce binary results. It behaves. It reacts to context, tone and the exact wording of a question. The same query may produce a precise, helpful answer today and one that leaves the user at a loss tomorrow. Not because something is broken. But because that is how the model works. For product owners and project managers, this represents a shift that runs deeper than it first appears: the most important tool is no longer the checklist. It is sound judgement.
‘Good enough’ sounds like an excuse. Like the compromise you make when time is running out or the budget isn’t enough. This interpretation isn’t just wrong. It’s detrimental to productivity.
In AI projects, ‘good enough’ is a conscious, informed decision. It is not a surrender. The real question is: at what point does this feature have a sufficient impact in a real-world usage context, even if it has not yet reached its technical limits? Answering this question is harder than it sounds. It requires judgement and the interpretation of non-deterministic answers, rather than the verification of unambiguous results. The difference between these two interpretations determines whether teams get bogged down in optimisation loops or whether they deliver, learn and move forward.
One of the most far-reaching prioritisation decisions in GenAI projects concerns the order of priorities. Many teams invest early on in tone, linguistic elegance and visual presentation. This is understandable: these aspects are visible in demos and they make an impression. Nevertheless, they are the wrong area to focus on at the outset.
The opposite mistake is at least as dangerous: scaling up the technology too early, before the content foundation is in place. It is possible to bring a large number of agents into production within a short space of time. However, if the subject-matter foundation and the data context are not right, it will still be of no use. Anyone who builds a sophisticated system on the basis of a poor understanding of the data, a lack of subject-matter consultation with the client and unresolved questions regarding impact is building in the wrong place. Technical excellence does not protect against a lack of substance, any more than linguistic polish does.
Technical robustness takes precedence. Does the system deliver reliable, useful results in terms of content within the application context? Only when this question can be answered in the affirmative is it worth putting the finishing touches to it. Anyone who polishes before this stage is merely polishing a surface over an unstable core. That sounds simple. In practice, it takes resilience to withstand the pressure to shine at an early stage. This pressure is real. And, if left unchecked, it leads in the wrong direction.
‘Good enough’ is not a state that you reach once and then tick off the list. It is a continuously negotiated reference point that shifts in line with the context of use, stakeholder expectations and the system’s level of learning. Sometimes up, sometimes down; rarely stable.
For product owners and project managers, this means that the real task is not to set a quality level once and for all. It is the iterative refinement, communication and defence of this benchmark throughout the entire project lifecycle.
The targeted development of an AI system requires feedback. Lots of feedback. And at this stage, hardly anything is more important than the ability to sort through this feedback. If you give everything equal weight, you’ll get lost in the noise. If you don’t prioritise anything, you’ll end up optimising in all directions at once. It all boils down to the same thing: you’ll get nowhere.
The following table shows the four categories of feedback and their significance for project management:
| Category | Example | What it means |
|---|---|---|
| Opinion | “That sounds a bit odd.” | Subjective perception; not yet a call to action |
| Requirement | “The AI should address the user informally.” | Specific request regarding system behaviour |
| Expectation | “I thought the AI would make suggestions to me.” | Implicit bias that was never communicated |
| Observation | “The answers always come in bullet points.” | Describable, repeatable system behaviour |
This distinction is not an academic exercise. It determines the response that follows. An opinion requires a different response to a request. An expectation that has never been voiced must first be made visible before it can be addressed.
A real-world example: During a meeting, a department expresses the wish that the AI should only display results when it is certain. Sounds reasonable. But what does ‘certain’ mean in technical terms? A probability of over 95 per cent? No verifiable hallucinations? Consensus across multiple models? Anyone who enters this wish into the backlog as a requirement without clarifying it is setting the development team an unsolvable task. Anyone who treats it as an implicit expectation that must first be operationalised lays the foundation for a genuine solution.
In this process, Product Owners and project managers become curators of feedback. They collect, filter, structure and make assessable what others feel or observe. This is translation work. And it is more demanding than it looks.
The shifts described cannot be resolved by introducing a new process model that simply eliminates the uncertainty inherent in GenAI projects. However, this does not mean that a systematic approach is impossible; on the contrary: it requires different mindsets and practices. As a Product Owner, uncertainty can be specifically mitigated through clear roles, agreed quality criteria and a shared frame of reference within the team. At the architectural level, there are tried-and-tested patterns that make variance manageable, such as sensibly embedding uncertainty directly into the system design via an appropriate interplay of agents and data access. This can also be systematically mapped in testing, for example by neatly translating business criteria into semantic quality metrics (keyword: Trust Index: https://arxiv.org/html/2507.16028v1). What cannot be eliminated by definition is the need for judgement.
The central question in quality assessment is undergoing a fundamental shift. The focus is no longer on ‘Does the feature work?’, but rather: Does it produce the desired effect in a real-world usage context? This requires observation rather than acceptance testing, and genuine user feedback rather than internal test scenarios. And it requires a willingness to understand quality as something that only becomes apparent in use – in real, messy, unexpected use.
Stakeholders accustomed to traditional IT projects bring with them patterns of expectation that do not fit GenAI contexts. They want predictability, clear milestones and reliable forecasts. Ignoring these expectations leads to disappointment. Uncritically catering to them creates pressure that leads to poor decisions.
The more productive approach: shaping expectations early on and transparently. Communicating what development feels like in a GenAI context. What it means to think in iterations. Why results vary. And why this is not a failure, but an inherent characteristic of this technology.
Practical tip: Make it clear to stakeholders at an early stage that results in GenAI projects can vary. By actively setting this expectation, you prevent disappointment and create space for honest feedback.
In GenAI projects, feedback is not merely a corrective signal at the end of a cycle. It is the primary steering tool throughout the entire course of the project. By collecting and analysing user feedback early on and systematically, and feeding it into the further development of prompts and system architecture, you gradually build up a robust understanding of what ‘good enough’ actually means for your own user group.
For this to work, feedback must not fall on deaf ears. Clear processes are needed:
Setting up this infrastructure is one of the most frequently underestimated tasks in GenAI projects.
In the end, there is always a decision to be made. One that must be taken whilst some uncertainty remains. There will never be a moment when all the information is fully available, all stakeholders are in agreement, and the system behaves optimally in every situation. This is not a transitional state. It will not resolve itself simply because more time or a larger budget becomes available.
Project managers who are effective in this environment are not those who create the greatest certainty. They are those who remain capable of taking action despite uncertainty, make clear decisions and stand by them in front of teams and stakeholders. This is an art form in its own right. And, contrary to what many believe, it can be learnt.
The question posed at the outset remains until the very end: when is this feature good enough? There is no definitive answer. What does exist, however, are the tools to answer this question anew time and again, and the courage to put them to use.
Those who take this to heart do not deliver less. They deliver better.
This article is based on insights from the book “When Is It Good Enough? Softwareprojekte im Zeitalter generativer KI” by Dr. Felix Böhmer, Dr. Tehseen Rug, and Tessa Pfattheicher (iteratec).