In recent discussions with Mendix developers I touched upon the influence of the product owner on the quality of Mendix apps. For example, a product owner that requests features that lead to lower quality of the app because a new feature contradicts with the way things have been built in the past and therefore leads to lower quality.
Another example of the influence of the product owner was about the time horizon of the product owner. Does he/she only care about the next 3 months or is the horizion multiple years from now and how much time/resources he/she is willing to spend on quality improvement actions, given this horizon?
Since I am a product owner myself I would like to gather feedback on good (and bad) behaviour of a product owner on the quality of an app. Please feel free to add your feedback to this post. We will try to collect some best practices out of it.
It’s possible to socialize some standards for product development to set expectations or provide guidance. However, as others have pointed out, the ultimate responsibility falls on developers.
Consider this analogy: if I hire someone to build a house, I can describe the result I want, but I probably don’t know all the construction standards they should follow. I have to trust they’ll adhere to those standards. What I can do, however, is ensure I’m not creating conditions that encourage cutting corners—like being overly rigid with the budget or timelines.
If a product owner wants to foster quality in development, here’s what they can do:
Shield developers from the stress of tight timelines:
The biggest reason I hear developers skip writing unit tests is that they “don’t have the time.” This perception often stems from product pushing hard to meet deliverables (which is their job). Inexperienced developers might just comply, while seasoned ones will push back or explain trade-offs. Product owners should avoid pressuring devs to work faster at the expense of quality. Instead, they should consider trimming deliverables or adjusting scope to allow time for proper development practices.
Promote a culture where quality is valued:
Clear messaging can make a huge difference, especially with less experienced teams. Simply saying, “I want this done right—don’t sacrifice quality for speed,” can empower developers to prioritize the right things. Many teams assume product doesn’t care about quality, which leads to bad habits like skipping unit tests. Addressing this misconception upfront creates a healthier dynamic. 9 out of 10 teams I talk to feel like product doesn't give them space to write unit tests, while I believe it's a falacy to believe product is responsible for how you do your job as a developer, I still hear this a lot.
Hi Derryn,
I agree with you and Rom about how things should happen. However, in reality things are sometimes complicated because either the product owner or the development team are not that experienced. Let me provide some examples from my own career as a product owner.
My first assignment as a product owner was back in 2006, with only 1,5 years of work experience after graduating. The development team was a very experienced team with 7 developers. They played exactly their role (even in the very early days of Agile) as they were supposed to do. So basically they taught me what my role was and what their role was. They prevented me (without me even knowing) of making many mistakes. I was a young and enthousiastic fulltime product owner, who understood the business and was eager to learn new things with respect to software development. I think this combination went pretty well.
Fast forward a few years later. I was again a product owner and, based on my previous experience I thought I knew what it takes to be a product owner. However, this time I was working with a very inexperienced development team. They never pushed back and built immedeately what I described in the backlog. The result: a total disaster. I was spending more and more time on testing and the team spent more and more time on debugging. The developers were always eager to changes things, but in many cases they broke more than they fixed. In the end, when I left the company, I felt like we did a terrible job. I guess I learned the hard way that there is a big difference in being a product owner for an experienced team compared to being it for a not so experienced team. The lesson that I learned from this is that as a product owner I need to be aware of the team maturity and act accordingly.
But the problem for a product owner is. How do you know your team is not so experienced? What signs do you get? How to act once you notice what is going on? Again, if you are an experienced product owner you probably see this coming and know what to do, but what if you are not (like in my second job)? What about product owners that do this as a part-time job and have no time or interest to act? What about product owners that do not know the basics of agile custom software development and have never heard about things like "technical debt", "Regression errors",...?
I fear that this might happen moreoften than we think. Specially in the context of Mendix apps, where the business is closely involved and developers have not always had a formal training in software development and are still learning the basics themselves.
I guess I would have appreciated a lot if someone would have told me how these things worked, so I could have avoided the most obvious mistakes.
I agree with Rom. The technical solution should be owned by the dev team and they should provide options with a variance in effort so the PO can make the call on whether any option justifies solving the problem looking at the TCO. However, there are situations where a call must be made between speed and quality. Winning over a large customer by introducing a quick and dirty feature might seem unlikely, but if you need that customer to pay the bills your principles will only result in the company falling. For me technical debt is a team decision where all variables are weighed and the devs combined with the PO make the call on accepting it .
I would like to define quality of software as the easiness to change. The 'only challenge' is that once you find out your product becomes hard to change, it is already too late. I agree with Roms comment that quality is a team effort, which means that it should be part of training as well. The team, including a PO, should never compromise quality in exchange for (new) functionality. If the quality is already good, it will never be difficult to deliver new functionality in short time. Several tools can support to detect possible compromises to quality.
Hi Joost,
I fully agree with the first bullet. We always ask our users to describe their problem. With that input we can design a solution with the development team, validate it with the user and then build/test it. This is much more effective than asking users for features
With respect to allocating time for refactoring/maintenance I agree that this is important. However, this is where the interests of product owners and the development team might not be aligned. Refactoring might add value in the (long term) future, but it typically does not add value on the short term. The product owner is the owner of the value of the product. However, does he look at short term value vs long term value. This might lead to conflicts of interest with the development team, if they do not share a similar timeframe in which they measure the value.
Your third point relates more to the organization of the work of the product owner. I agree with you that the product owner should not become a bottleneck in the software delivery process. If he is a bottleneck he is effectively destroying value by making the "time to value" longer than necessary. This is something that should be solved as quick as possible.
Hi Markus,
I also feel that the development team is primarily responsible for the build quality of an application. If a product owner requests a feature with impact on existing functionality, the dev team should include refactoring of existing code in their estimations to ensure quality is maintained.
I do feel that product owners can influence the quality of the application in other ways:
For example, a product owner can provide a user story saying "As a <userrole> I need an Excel export". I have often encountered product owners that describe requirements without providing the business problem to solve. An immature dev team will not ask too many followup questions and you get exactly what you asked for. However, the same story can also be written like this:"As a <userrole> I need to periodically share reporting data with the management, because they need to forecast data for the next quarter". The latter form provides more room for alternative/higher quality implementation suggestions from the development team.
These activities do not add any new features to the system and are sometimes seen as expensive and unnecessary work. However, in the long run it will prevent many quality-related issues and less decrease of velocity of development teams over time.
I have seen many times that a PO is doing their job in between their own busy schedules. This means that issues might not be detected until later in the sprint, which then could lead to developers trying to fix/correct mistakes close to the deadline, increasing risk of errors and shortcut fixes
Last but not least, product owners can also influence the team composition. For example, if the development team's expertise is more back-end/technical oriented, add a UX/UI expert to the team to create mock-ups.
Best,
Joost
Neither of these are good examples of the influence of a product owner. They are examples of an immature development team: a development team should not deliver low quality software. Hence, when a product owner asks for a feature that leads to a lower quality application, the estimation of that feature should instead be high enough to allow an implementation in the application so that the quality remains high. The product owner can then decide to not prioritize the feature due to excessive perceived cost, or to keep it on the backlog for the estimated cost that includes quality.
The potential 'bad behavior' of a product owner would be to try to negotiate the estimation down. However, this can simply be ignored.