Why UAT is better than Demo for me as a PM

As a product manager (PM), I always discuss the product development workflow with the dev team at the beginning of the project and one topic always comes up, which is UAT vs. Demo. The dev team always asks me whether I want to do UAT or I want to let the dev team do the Demo to me (and other stakeholders).

So let's begin with what UAT and Demo are. UAT stands for "User Acceptance Testing", which is the phase in software development lifecycle that product owners or stakeholders or intended users test the actual product to make sure the requirements are implemented correctly and the product behaves in the intended ways. For Demo, it is simply a demonstration of the product by the dev team to product owners or stakeholders or intended users. Instead of letting those people test the actual product, the dev team will demonstrate the product to those people and collect comments from them to improve or fix the product before deliver it.

Personally, there are two main advantages that I prefer to do UAT than Demo. First of all, UAT allows me to check the software engineering works to make sure the specifications are met and the implementation is done in a good way for a user. Secondly, the result of UAT at the early stage of the development can decrease the total implementation time since the dev team can fix or improve the product at the early stage before QA process and even other software testing process. Since I as a PM is responsible for the experience that a user will have with my product and also responsible to ship the product on time. Thus, I need to test the product myself as early as possible to make sure everything is right and the team is pacing to the expected deliver date with a correct product.  Without performing UAT by myself, it sometimes occurs to me that the product isn't implemented correctly because the dev team doesn't clearly understand the ticket or the desired outcome. Also, since the PM doesn't normally involve with the way the product is built, sometimes the best engineering approach per the dev team's idea may not be the best solution from the PM's standpoint or the user's perspective. Thus, without detailed discussion before hand or capturing this kind of issue during the UAT, the product that is working per the technical requirements may be delivered to the user without the best interest for the user. In addition, once the issue is found during the UAT, the dev team can fix and improve the product at the early stage of the development process, which is faster than fixing it at the later stage.

For Demo, it allows the dev team to move to other stage of development faster without waiting for product review by a product owner if that product owner doesn't hand on in the development process, which could be a blockage. Also, if the project has many stakeholders who can comment about the product directly to the dev team, this will be troublesome for the dev team to wait for all of the comments and move forward with the process. Instead, the dev team can easily schedule a demo session with every stakeholder to demonstrate the product and collect all comments in a single meeting, which is easier for the implementation to move forward. However, the Demo has a major drawback that the product manger or stakeholders or intended users aren't be able to check the product by themselves to uncover any issue that may arise from the implementation until it is being shipped or near the end of the development process. Since the Demo is usually done by the dev team by showing the actual implementation, the dev team will present the works based on how it is implemented and how it is intended to be used. But the user may have other ways in using the product that is differently than the dev team. This kind of issue may not be uncovered until the product is in the user's hand and it'll take a while to correct the issue.

Thus, I prefer the UAT than the Demo to make sure everything is implemented correctly in term of both the product perspective and the user perspective. It'll improve the development process as well to fix any issue arising from the PM's perspective without wasting our dev and QA resources. Ultimately, to do this, the PM needs to be handed on in the product development part and committed to this UAT step without causing this step to delay later development steps. Also, the PM needs to be trusted by stakeholders to make the right decision and ship the right product for them without stakeholders' direct involvement in the development process.