agileA technology services scale-up running SAFe with a small team of two to five people faces a real problem: creating meaningful user acceptance testing. The company builds a cloud infrastructure management platform that helps DevOps teams provision, monitor, and optimize cloud resources across multiple providers. It has been around for three years, with forty-eight employees across two offices. The product development organization has one SAFe team of four people. (1/34)
That four-person team builds new features for the platform. More features mean a better platform. A better platform attracts more DevOps teams. More users mean more revenue. But meaningful user acceptance testing remains a persistent challenge. (2/34)
When the team does not create meaningful user acceptance testing, it tests features with users in ways that do not produce useful feedback. Without useful feedback, the team does not learn what users actually need. Without learning, the team builds features that miss the mark. Users do not adopt those features, and the platform does not grow. (3/34)
Last year, the team released sixteen features. Only five had meaningful user acceptance testing. The other eleven had an average adoption rate of just twenty-three percent. The five features with meaningful testing had an average adoption rate of seventy-four percent. The eleven poorly tested features generated a total revenue impact of three hundred and thirty thousand dollars. The team also spent one hundred and twenty thousand dollars building features users did not adopt (4/34)
. The combined loss was four hundred and fifty thousand dollars.
The root cause came down to one thing: the team was not creating meaningful user acceptance testing. And that failure cost four hundred and fifty thousand dollars. (5/34)
Azim Premji built Wipro on the ethical leadership model. His insight was straightforward. He recognized that the biggest problem in business is the tendency to treat people as means to an end. When you treat people as means to an end, you use people to get what you want. When you use people, they do not trust you. When people do not trust you, they do not give you honest feedback. When people do not give you honest feedback, you do not learn. (6/34)
Premji attacked that tendency head-on. He created the ethical leadership model around one principle: treat people as ends in themselves and they will trust you. When people trust you, they give you honest feedback. When they give you honest feedback, you learn. When you learn, you win. (7/34)
For a technology services scale-up, the user acceptance testing problem is the same. The four-person SAFe team treats users as means to an end. The team uses users to validate features. Users do not trust the team. Users do not give honest feedback. The team does not learn. That failure costs four hundred and fifty thousand dollars. (8/34)
Premji's ethical leadership model says: treat people as ends in themselves and they will trust you. Apply that to user acceptance testing: treat users as ends in themselves and they will give you honest feedback. When users give you honest feedback, you learn. When you learn, you create meaningful user acceptance testing.
## The Core Principle (9/34)
Premji built Wipro by treating people as ends in themselves. That approach earned him trust. Trust brought honest feedback. Honest feedback led to learning. Learning built Wipro. (10/34)
The four-person SAFe team treated users as means to an end. The team used users to validate features. Users did not trust the team. Users did not give honest feedback. The team released sixteen features. Only five had meaningful user acceptance testing. Eleven had an average adoption rate of twenty-three percent. Five had an average adoption rate of seventy-four percent (11/34)
. The company lost three hundred and thirty thousand dollars in revenue and wasted one hundred and twenty thousand dollars in development costs. The combined loss was four hundred and fifty thousand dollars.
The fix is to start treating users as ends in themselves. When you do, users trust you. When users trust you, they give you honest feedback. When they give you honest feedback, you learn. When you learn, you create meaningful user acceptance testing. (12/34)
## Four Steps to Apply the Ethical Leadership Model
1. Treat People as Ends in Themselves and They Will Trust You
Start by creating a user respect practice that treats every testing participant as a valued partner rather than a validation tool. The team needs to stop using users to validate features and start treating them as partners in the development process. (13/34)
The user respect practice has four steps. First, recruit users as partners, not testers. Send a personal invitation that says We are building a new feature and we would like you to be our partner in making it great. Your expertise and perspective are valuable to us. Do not say We need you to test our new feature. Recruit five users per feature. That is a manageable number for a small team. (14/34)
Second, explain the purpose of the partnership. Make it clear that the goal is to learn from the user. Tell users they are the expert. For the cloud infrastructure management platform, say You are a DevOps engineer. You know more about cloud infrastructure management than we do. We want to learn from your experience and understand your pain points. (15/34)
Third, compensate users for their time. Offer a fifty-dollar gift card for each session. Offer early access to the feature. Offer to implement one feature request from the user within thirty days. Compensation shows the user that the team values their time. (16/34)
Fourth, thank users personally. Send a personal thank-you email after each session that lists the specific ways the user's input helped improve the feature. Send a follow-up email thirty days later showing what the team built based on their feedback. (17/34)
Last year, the team used this practice for six months across eight features. Before the practice, only five of sixteen features had meaningful testing. After the practice, seven of eight features had meaningful testing. The team increased the percentage of features with meaningful testing from thirty-one percent to eighty-eight percent. The team saved four hundred and fifty thousand dollars.
2. When You Treat Users as Ends in Themselves, Users Trust You (18/34)
Build a trust-building feedback loop that asks users for honest feedback and shows users how their feedback was used. The team needs to stop getting surface-level feedback and start getting honest feedback that leads to meaningful improvements.
The feedback loop has four steps. First, ask open-ended questions. Do not ask yes-or-no questions. Ask questions like What was the most frustrating part of using this feature? and What would you change if you could change anything? (19/34)
Second, listen without defending. When a user gives negative feedback, do not explain why the feature is the way it is. Do not argue. Say Thank you for telling us that. Can you tell us more? Take notes. Record the session with the user's permission.
Third, show users how their feedback was used. After implementing changes, send a feedback report with three sections: What you told us, What we changed, and What we decided not to change and why. (20/34)
Fourth, close the feedback loop every sprint. Review all user feedback at the start of each sprint. Identify the most common themes. Add them to the sprint backlog. Send feedback reports to users. (21/34)
The team used this loop for six months across eight features. Before the loop, the team got surface-level feedback. After the loop, the team collected one hundred and twenty pieces of honest feedback. The team sent forty feedback reports and closed the loop eight times. Seven of eight features had meaningful testing. The team increased meaningful testing from thirty-one percent to eighty-eight percent and saved four hundred and fifty thousand dollars. (22/34)
3. When Users Trust You, They Give You Honest Feedback
Create a safe feedback environment that makes users comfortable sharing negative feedback. The team needs to stop hearing only positive feedback and start hearing the negative feedback that is most valuable for improving features. (23/34)
The safe feedback environment has four steps. First, start with a safety statement. At the beginning of each session, say We want your honest feedback. There are no wrong answers. Negative feedback is more valuable to us than positive feedback because it helps us improve. (24/34)
Second, separate the user from the feedback. Say We are evaluating the feature. We are not evaluating you. This makes users feel safe. They do not feel like they are criticizing the team. They feel like they are helping.
Third, normalize negative feedback. Share examples from previous sessions. Say In our last session, a user told us the dashboard was confusing. That feedback helped us redesign it. The new dashboard has a forty percent higher satisfaction score. (25/34)
Fourth, respond to negative feedback with gratitude. When a user gives negative feedback, say Thank you. That is exactly what we needed to hear. Do not say But we designed it that way because. Just say thank you and take notes. (26/34)
The team used this environment for six months across eight features. The team started with safety statements in forty sessions, separated users from feedback in forty sessions, normalized negative feedback in forty sessions, and responded with gratitude in forty sessions. The team received eighty-seven pieces of negative feedback and acted on sixty-two of them. Seven of eight features had meaningful testing. The team saved four hundred and fifty thousand dollars. (27/34)
4. When Users Give You Honest Feedback, You Learn
Build a feedback-to-feature pipeline that turns user feedback into improvements within one sprint. The team needs to stop collecting feedback and forgetting about it. Start turning feedback into action quickly. (28/34)
The pipeline has four steps. First, categorize feedback within twenty-four hours. After each session, review the feedback and sort it into three categories: quick wins that take less than four hours, sprint items that fit within one sprint, and backlog items that require more than one sprint.
Second, add quick wins to the current sprint immediately. Prioritize them at the top of the backlog. Complete them before the sprint ends. (29/34)
Third, add sprint items to the next sprint backlog during planning. Prioritize based on frequency. If three users gave the same feedback, rank it higher.
Fourth, add backlog items to the product backlog. Prioritize based on impact on user satisfaction. Review backlog items every program increment. (30/34)
The team used this pipeline for six months across eight features. The team categorized one hundred and twenty pieces of feedback within twenty-four hours, identified thirty-seven quick wins and completed them all, identified fifty-two sprint items and completed forty-one, and identified thirty-one backlog items and added them to the product backlog. Seven of eight features had meaningful testing. The team saved four hundred and fifty thousand dollars.
## Closing (31/34)
Azim Premji built Wipro by treating people as ends in themselves. The four-person SAFe team can do the same. Start by creating a user respect practice for the next feature. Then build the trust-building feedback loop, the safe feedback environment, and the feedback-to-feature pipeline. (32/34)
When the team treats users as ends in itself, users trust the team. When users trust the team, they give honest feedback. When they give honest feedback, the team learns. When the team learns, it creates meaningful user acceptance testing. And when the team creates meaningful user acceptance testing, the company stops losing four hundred and fifty thousand dollars a year. (33/34)