A Guide for Users, Product Owners, and Product Managers
Anyone who works on software projects knows the situation: A user reports that something is “wrong.” For them, the matter is clear. The application isn’t behaving as expected. However, the development team often starts discussing: Is this actually a bug? Is this a new requirement? Was this ever agreed upon?
This is precisely where it becomes clear that not every deviation from a user’s expectations is automatically a bug. For the daily work of product owners, product managers, and development teams, it is therefore worthwhile to clearly distinguish between these terms. Not for academic reasons, but because the classification has a direct impact on prioritization, effort estimation, and responsibilities.
Bug, Defect and Feature Request
In everyday language, the terms are often used interchangeably. However, the following distinction has proven useful for practical purposes.
A bug exists when the software behaves differently than described in the agreed-upon requirements. This does not necessarily mean a crash or an error message. Even seemingly minor deviations are bugs.
For example, it was agreed that a project list would be sorted by project number by default. However, after the release, the list is now displayed sorted by creation date by default. The application functions technically without any issues, but the behavior deviates from the agreed-upon requirement. This constitutes a bug.
A defect exists when the application deviates from a legitimate expectation of the user or stakeholder, but this expectation was never defined as a requirement or communicated to the development team.
From a user’s perspective, this difference is often barely noticeable. The user typically doesn’t know which details were actually agreed upon and which weren’t. To them, both are simply mistakes. However, for product owners and product managers, this distinction is crucial, as they usually have insight into requirements, specifications, and agreements.
In practice, defects can have various causes. Two common forms are the requirement deficit and the behavior gap.
A requirements deficiency occurs when a relevant use case or business expectation is not adequately described in the requirements or is even completely overlooked. The development team correctly implemented the existing specification, but the specification itself was incomplete.
A typical example is an export function where the specifications for exporting data are defined, but not how to handle very large datasets. As soon as the first users want to export several thousand records, it becomes clear that a crucial use case was never considered.
A behavior gap exists when the application behaves according to the requirements, but this behavior does not correspond to the actual expectations or common usage patterns of the users.
For example, a search function distinguishes between uppercase and lowercase letters. This behavior was never specified and is technically implemented correctly. However, many users today expect a case-insensitive search. The software meets the documented requirements but fails to meet practical user expectations.
A defect therefore does not necessarily mean that the development process made a mistake. Often, it indicates that the stakeholders had different ideas about the desired behavior or that important requirements were not sufficiently identified during the analysis.
A feature request describes a new function or an extension of existing functionality. The software then behaves exactly as agreed.
For example, if users want to sort by creation date in addition to the existing sorting by name, this is not a bug, but a feature request.
This creates a hierarchy that is often very helpful from the product owner’s perspective:
- Bug → Requirement violated
- Defect
- Requirements deficit → Requirements incomplete or missing
- Behavior gap → requirement met, but user expectation not met
- Feature Request → new function or enhancement
Why the distinction?
A good classification has far more than just terminological significance.
For one it’s prioritization. A bug indicates that a promised feature has not been implemented correctly. This immediately poses a risk that users will not be able to perform their work as agreed.
While a requirement gap or defect as described above can also be highly relevant, it often represents a new insight into actual user needs. Therefore, many organizations initially prioritize bugs over such functional gaps. Of course, there are exceptions. An unspecified but business-critical use case might be more important than a cosmetic bug.
Secondly, the distinction is important to assign responsibilities and costs correctly.
This distinction often plays a significant role, especially when working with external service providers.
If a bug exists, an agreed-upon requirement has not been implemented correctly. The responsibility then typically lies with the development team or the contractor. The fix is often provided under warranty, maintenance, or within the original scope of work.
If, on the other hand, there is only an unspecified user expectation, the development has proceeded correctly according to the existing requirements. In this case, it is effectively a new or clarified requirement. The effort for analysis, implementation, and testing is usually charged to the client.
That’s precisely why a product owner should be careful not to automatically classify every reported error as a bug.
What a good bug report should look like
Regardless of whether it later turns out to be a bug, a requirement gap, or a feature request, the original message should always be formulated as neutrally as possible.
A common mistake is to try to describe the cause right away:
The database does not store the data.
The user usually has no idea whether the database is actually the cause.
Pure observation is significantly more helpful:
After saving, the message “Successfully saved” appears. However, after reloading the page, the data record is no longer there.
A good report initially only describes the facts:
- What was done?
- What was expected?
- What happened instead?
- Under what conditions did the problem occur?
Especially with web applications, the concrete steps for reproduction are often more important than any technical analysis.
Instead of writing:
The project module is not working.
The following description is significantly more valuable:
As project manager, I open project 4711. After clicking on “Change status,” I select “Released” and save. A success message then appears. After refreshing the page, the status reverts to “In progress.”
Additional information such as browser, user role, URL, time of occurrence, or screenshots greatly assists the team in their analysis. Details about whether the behavior occurs consistently or only sporadically are particularly helpful.
The role of the Product Owner
Users should not be forced to distinguish between bugs , defects , and feature requests. They simply report an observation. That is perfectly sufficient.
The actual classification is the responsibility of the Product Owner or Product Manager.
This includes, in particular, the question:
Does the behavior deviate from an agreed-upon requirement or merely from an expectation?
Further classification should only take place after this question has been answered.
A good bug report therefore begins by describing observable behavior and avoids premature blame. It provides enough information for the product owner and development team to objectively assess the situation. This significantly simplifies the subsequent classification as a bug, requirement gap, or feature request and reduces conflicts between the business unit, the client, and the development team.
Ultimately, a good bug report is not just an error message, but a precise, technical report about an observation. That’s precisely what makes it valuable.
This post is also available in:
