User Acceptance Testing Challenges

Client UAT (user acceptance testing) is a constant challenge for a services firm like AWH. UAT challenges are not reserved for firms like ours, however.

Clients often underestimate the time, energy, and work needed for user acceptance testing. This is true for external clients, but it is also true for internal clients at a company.

User acceptance testing isn’t new, and clients who have worked with product teams previously to create or evolve products should be and in some cases are better at it, but most still struggle to fully value and get good at it.

Our challenge as a services firm working with clients who don’t create software products frequently, if ever before, is that they don’t understand and value user acceptance testing. This causes clients to discount their focus and commitment to doing it. Clients will often assign user acceptance testing to a team member or a few team members who already have full-time roles. Therefore, the user acceptance testing gets deprioritized, done last minute or after hours, causing it to be done inadequately, incompletely, or untimely. User acceptance testing is a crucial part of the process, and when it isn’t performed well and promptly, it causes unnecessary thrashing.

So how can clients work in their and a product’s best interest around user acceptance testing? Here are some tips:

  • Dedicate team member time: It doesn’t work to have UAT performed as an additional responsibility for team members who already have full plates and schedules. UAT will not be performed well, and the product will be viewed negatively by those who are asked to perform UAT in addition to their regular work, especially if it means after-hours work.
  • Single point of contact: Multiple team members can be doing UAT, but the feedback and findings need to flow through a single person. Too many people trying to communicate and collaborate with the product team on issues or clarity of functionality creates confusion. One person should be responsible for distilling and communicating with the product team on any UAT issues.
  • Context: One of the reasons to have a single person manage UAT findings is that this person should have the context of how the functionality of a product is expected to work and why. Not just at a basic functional level but at an experiential level too. This helps speed the communication and remediation of an issue with the product team. It will also allow the person to prune the list of issues before involving the development team.
  • Timely: UAT happening promptly is critical because the more time elapses, the more it impacts a product’s timeline, the more context gets lost, and the more expensive the effort becomes. UAT that happens randomly or at unexpected times isn’t accounted for as part of a production schedule and roadmap, so it will cause the product team to have to adjust. It will also create workflow and staffing challenges for a product team expecting UAT to happen at a particular time and pace. Unexpected timing and workflow from UAT send product teams into reactive mode instead of a planned mode. This causes friction around designer, developer, quality assurance, and DevOps involvement and scattered work rather than intentional.
  • One place to track findings: All UAT findings should be tracked in one place. It doesn’t matter where so long as the UAT lead and product team agree on where and how. The tool for tracking UAT findings matters less than it happens in one place in an agreed-upon manner. Too often, UAT findings are being tracked and documented differently by team members performing UAT. The UAT lead needs to enforce where and how UAT findings are captured. This is another reason to have a UAT lead.
  • Significant releases: The intent is to have iterative, minor releases, but when a substantial release is unavoidable, the workweek should be organized to remove most regular duties from SMEs involved in testing and allow that group to focus on testing during a designated block of days strictly. This ensures all testing gets done promptly and everyone is given the appropriate time and space to be thorough.

Product Managers need to ensure they have a sound and cohesive UAT plan with a client (external or internal). The plan needs to align what, who, how, and when UAT will get performed. It also needs to be discussed and agreed on how UAT will be prioritized against other work for the testing team members. Team members performing UAT should never be unclear about its priority compared to other work. They should also never conflict with UAT versus other work or personal matters. UAT will lose to competing work and personal time every time.

The importance of timely and well-executed UAT must be reinforced before and throughout testing. Too often, it gets treated as an afterthought by product teams and testers. The product teams want to release, and testers wish the work to go away and the associated annoyance. The push to release is essential. Everyone involved in a product should be operating with a sense of urgency, but the push to release without reasonably practical and thorough testing doesn’t serve anyone well.

One more thing I would add somewhere is that it is important to “train” and prepare a client in advance of UAT. We all know that clients miss the mark in their first few rounds of UAT so the sooner we can deliver the message that it will take far more time than you think, the sooner they will get up to speed.




We help companies fuel growth through technology. Connect with us at

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Key Digital Product Manager Skills

The dilemma between Done and Perfect in product design

A typographic overview, showing the words “Done” and “Perfect” with strikethrough and the words “Perfectly done” underlined.

Making Your Users Feel “Warm & Fuzzy” About Your Product

Qualio: The Future of Quality Management

40 things I’ve learned as a SAAS Enterprise B2B Product manager

The magic loop — how to improve your product team continuously

Strategy in JSON format: An introduction to API Product Management

Product roadmap: Step by step guide to prioritize product features for internal products

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


We help companies fuel growth through technology. Connect with us at

More from Medium

Understanding TOGAF ADM Phase A (Part 1 of 4) — Architecture Vision

Limitations & Strengths of McLuhan’s Ideas

Differences between static and dynamic libraries

Change Sets in Salesforce