The proxy customer problem is one of the most common and least discussed reasons projects miss the mark. A team spends months building a new system, app or process. They hold workshops, write requirements and run demos. Yet nobody has actually spoken to the people who will use the finished product every day. Instead, a manager, a product owner or a sales rep speaks “on behalf of” the customer, and the team treats that opinion as fact.
This guide explains why the proxy customer problem happens, what it costs and how business analysts bring real users back into the conversation. If you want to build those skills yourself, we also point you to practical training from Business Analysis Courses Australia.
What Is the Proxy Customer Problem?
A proxy customer is anyone who represents users without being one. Typical examples include a senior executive, a product owner, a salesperson, a support manager or an internal subject matter expert. They usually mean well and often know the business better than anyone. The trouble starts when their view quietly replaces direct evidence from the people doing the work.
The proxy customer problem, then, is the gap between what stand-ins believe users need and what users actually need. Because proxies sit close to the project, their opinions arrive fast, confidently and in meeting-friendly language. Real users are busier, quieter and harder to reach, so they get left out.
Why Organisations Fall Into the Proxy Customer Problem
Speed and convenience
Booking time with a handful of real users takes effort. Asking the person in the next office is easy. Under deadline pressure, convenience usually wins.
Hierarchy and assumptions
Senior people are often assumed to know best. When an executive says “our customers want X”, challenging them feels risky, even if nobody has checked.
Access barriers
Privacy rules, customer-facing teams guarding relationships and remote or shift-based users can make direct access difficult. Teams give up instead of finding workable ways in.
Confusing the buyer with the user
The person who signs off a system is often not the person who uses it. Procurement may care about cost and compliance while frontline staff care about speed and clarity. A decision based on one voice can fail the other.
Over-reliance on secondhand data
Sales feedback, support tickets and survey scores are helpful signals, but they are filtered. They show what people complain about, not always why or how they work around problems.
The Real Cost of the Proxy Customer Problem
When real users are missing from the process, the symptoms appear late and cost more. Features go unused. Staff create workarounds, often in spreadsheets, to avoid the “official” system. Training takes longer than planned. Rework piles up after launch, when changes are slowest and most expensive.
As an illustration, imagine a state government agency introducing a new case management tool designed from manager feedback. Managers wanted detailed reporting, so the form grew long. Frontline officers, who use it all day, find it slow and start keeping notes elsewhere. The reports now rely on incomplete data, and everyone is unhappy. Nobody was careless; the proxy customer problem simply hid the real workflow.
Signs Your Project Has a Proxy Customer Problem
- Requirements come only from managers, never from the people doing the work.
- Nobody on the team has watched a real user complete a task.
- Personas were written in a workshop rather than from interviews or data.
- “The customer wants…” appears in meetings with no evidence attached.
- User testing is planned for “after launch”.
- Adoption is lower than expected and staff keep using old methods.
How Business Analysts Fix the Proxy Customer Problem
Business analysts sit between stakeholders, users and delivery teams, so they are well placed to spot proxy decisions and replace them with evidence. The table below shows common proxy habits, what they tend to miss and the techniques that fill the gap.
| Proxy habit | What it tends to miss | Technique that fills the gap | Explore |
| Executive says “customers want X” | Real behaviour and priorities | User interviews and evidence checks | BA Techniques |
| Product owner is the only voice | Frontline pain points | Stakeholder mapping and sprint reviews with users | AgileBA Foundation |
| Sales feedback drives features | Needs of people who use, not buy | Journey mapping and buyer vs user analysis | AgileBA Practitioner |
| Support tickets only | Why problems happen and silent workarounds | Observation and contextual inquiry | ISQI Agile BA |
| Requirements written in a workshop | Gaps, conflicts and untested assumptions | Requirements validation and traceability | IREB CPRE-FL |
| New system rolled out to staff | Adoption barriers and resistance | Change impact analysis and pilots | BCS Business Change |
The goal is not to ignore proxies. They hold valuable context. The goal is to test their assumptions against what users actually do and say.
A Practical 8-Step Approach to Avoid the Proxy Customer Problem
1. Map every stakeholder and user group
List who uses, pays for, approves, supports and is affected by the solution. Mark who you have actually spoken to. The blanks show where proxies are filling in.
2. Separate the buyer from the user
Record the needs of each group separately. Conflicts between them are not problems to hide; they are decisions to make deliberately.
3. Interview real users early
Even five or six short conversations can reveal surprises. Ask about their last time doing the task, not what they think they want. Stories give richer detail than opinions.
4. Observe the work
Spend time watching people use current tools. Contextual observation exposes workarounds, interruptions and unwritten steps that interviews miss.
5. Use data to cross-check opinions
Combine support tickets, usage analytics, call logs and survey comments with what you hear. Where proxy opinion and data disagree, investigate.
6. Prototype and test with users
Show simple wireframes or mock-ups before building. Users react more honestly to something they can click than to a requirements document.
7. Write user stories with real acceptance criteria
A good story names the actual user, the goal and how success is checked. Review them with users, not just with the product owner.
8. Keep the feedback loop open after launch
Include users in sprint reviews, pilots and post-implementation reviews. Standards such as the Australian Government’s Digital Transformation Agency guidance on designing services around user needs show how seriously public agencies now treat this.
Proxy Customer Problem Examples Across Australian Cities
The same pattern shows up in every major centre. Banks and insurers in Sydney and Melbourne often design customer tools from internal feedback. Agencies in Canberra build citizen-facing services where policy owners speak for users. Health, resources and utilities organisations in Perth and Adelaide roll out operational systems that frontline staff must live with, and Brisbane teams modernising legacy platforms face the same risk. Business analysts in each city can help bring users back into the room.
To build these skills locally or online, explore business analysis courses in Sydney, Melbourne, Brisbane, Perth, Adelaide and Canberra.
Business Analysis Courses That Teach User-Focused Skills
If you are new to the field, start with the Business Analysis Techniques course, which covers elicitation and analysis methods. For agile environments, the Agile Business Analysis (AgileBA) Foundation and AgileBA Practitioner courses show how to keep users involved in short delivery cycles. The ISQI Agile Business Analysis certification adds another recognised pathway.
If requirements quality is your focus, look at the IREB Requirements Engineering Foundation (CPRE-FL). For organisational change, see the BCS Business Change Foundation and BCS Business Finance Certificate. You can compare everything on the courses page, browse the business analysis courses hub, read about us or visit our blog.
For wider reading, the International Institute of Business Analysis maintains the BABOK Guide, the IREB publishes requirements engineering resources, and Nielsen Norman Group shares user research articles. Logitrain also lists business analysis training courses for those comparing options.
Frequently Asked Questions About the Proxy Customer Problem
What is the proxy customer problem?
It is when organisations design solutions based on the opinions of stand-ins, such as managers or product owners, instead of speaking directly to the people who will use the solution.
Why is it a problem to design without talking to users?
Proxies filter and simplify user needs, so important details get lost. The result is often low adoption, workarounds and expensive rework after launch.
How do business analysts involve real users?
They use interviews, observation, workshops, journey mapping, prototype testing and data analysis, then check requirements back with users before development.
Is a product owner a proxy customer?
Often yes. A good product owner represents users well by staying in close contact with them, but they should not be the only source of user insight.
Which course helps with gathering requirements from users?
Business analysis techniques, agile business analysis and requirements engineering courses all cover elicitation and validation. The best fit depends on your experience and the environment you work in.
Final Thoughts: Put Real Users Back in the Room
The proxy customer problem is easy to fall into and fixable with simple habits. Talk to real users early, observe actual work, test with prototypes and treat proxy opinions as hypotheses rather than facts. Projects built this way tend to launch with fewer surprises and stronger adoption.
If you want to learn these techniques professionally, contact our team or call 1300 649 299. An adviser can help you choose a business analysis course that suits your background.