In software development even the smallest decisions can influence the outcome of a project. In an ideal world, clients would work side by side with their development teams and participate in daily discussions and decisions. But the reality is that most clients have their own day-to-day responsibilities and they can’t be available around the clock to weigh in on every question or detail.
So, what happens when developers hit a roadblock and aren’t sure which direction to take?
That’s where customer proxies step in.
In this article, we’ll explain what the role of customer proxies looks like in our teams and share some ways it has positively impacted our projects.
Who is a customer proxy?
While the customer proxy is not a formal role in either traditional or Agile development, our experience over the years has shown a growing need for the role within teams.
Our internal definition is:
“A customer proxy is a role a member of the development team takes. They represent the client’s (customer’s) perspective inside the team.”
In practice, this role requires a mix of specific knowledge and responsibilities often found in business analyst, product owner and project management roles. They work closely with the end-client to deeply understand the project and the business domain. This ensures they have the right insight and authority to accurately advocate for the client’s needs throughout the development process.
“Customer proxies– the bridgekeepers in software development”
Imagine a bridge connecting two separate shores: developers on one side, clients on the other. Midway along this bridge there is a small house, the home base of the bridgekeeper or in this case – the customer proxy. Just as the bridgekeeper asks questions before allowing passage, customer proxies often validate requirements, clarify priorities or test assumptions before they reach developers. They also guard information in the other direction communicating technical constraints, progress, and trade-offs back to the customers.
In practice, customer proxies:
- balance technical constraints with business demands
- elicit, gather and document requirements
- break down requirements into user stories
- help prioritize features and fixes
- support testing by verifying that features meet the documented requirements
- provide early feedback before formal client reviews
To sum up:
A customer proxy is not a job title; it’s a role someone takes on within the team to represent the client’s perspective.
The customer proxy’s role across project stages
To fully grasp the value of a customer proxy, we first need to break down their role in every stage of the development process.
No two projects are alike. They can range from legacy modernization to building custom software, and there are countless ways to define project stages. Yet, for the purpose of this article, we defined four stages: discovery, planning, execution and validation.
Let’s take a look:
Discovery – preventing requirement-related issues
Even if there are many ways a project can start, they all have one thing in common: some type of discovery. The discovery phase is when we gather requirements and set goals.
While this process can feel time-consuming, the cost of skipping it, or not having the right person dedicated to it, is far higher.
Requirement-related issues come from incomplete, unclear requirements and from frequent requirements changes.
If not dealt with in time, poorly defined requirements can cause:
- scope creep: incomplete requirements can expand the project beyond what was initially agreed
- wasted effort: the team builds features based on assumptions with the chance they have to redo them once requirements are clarified
- delays: teams pause development frequently while waiting for missing requirements to be defined
To prevent requirement-related issues the customer proxy goes beyond the initial requirements and tries to find the “why” behind them. Sometimes clients believe that they want some type of feature or solution when in reality, what they truly need is something different that addresses the underlying problem.
The customer proxy:
- asks targeted questions: they ask clients about specific workflows, exceptions and problems to uncover hidden requirements
- reviews client documents: they read policies, manuals and legacy system documentation to find relevant details
- runs clarification sessions: they schedule calls or workshops with clients to minimize uncertainties
Planning– preventing misalignment between business priorities and IT
During the planning and prioritisation phase, business goals and IT are aligned. The team decides which problems to tackle first and creates models, workflows and plans to guide development.
Misalignment happens when the team doesn’t fully understand business priorities, leading them to make poor decisions on how to structure solutions and which features to prioritize.
Misalignment between business priorities and IT can lead to:
- inefficient architecture: the team might design systems that create operational bottlenecks or limit the company’s ability to scale efficiently
- misallocated resources: the team assigns key people or time to lower-impact tasks leaving critical work under-resourced
- customer dissatisfaction: solutions don’t solve the most important problems and result in poor user experience
The customer proxy helps the team decide what to prioritize while preventing misalignment between business priorities and IT.
The customer proxy in the planning phase:
- translates business needs to developers: explains why certain items are critical so the team understands the context
- flags dependencies: identifies which items must be done first to unblock future work
- models business processes: creates flowcharts, diagrams and mockups to visualize how the system should work
Execution – preventing delays
The execution phase is when the team finally starts building and implementing the project plan. It involves turning requirements and design into working software and continuously addressing issues that arise during development.
Even small, non-blocking questions can pile up if every single one needs direct client involvement, creating delays that cause:
- slower progress: some tasks can’t move forward until client decisions are received
- team frustration: developers feel blocked and demotivated when they can’t move forward
- reduced predictability: project timelines become unreliable because progress depends on when clarifications arrive
During this phase the customer proxy role is centered around preventing delays by keeping development flowing.
The customer proxy:
- is available for daily clarifications: they provide clarifications on requirements, edge cases and business rules
- refines user stories: updates and breaks down stories as needed to keep the team moving
- makes informed decisions: gathers sufficient input from the client to have the knowledge needed for day-to-day decisions
Validation – preventing late discovery of mismatches
In the validation phase the team verifies what has been built by running final tests and gathering feedback from the client.
If issues are only spotted once the client reviews a feature, they are much harder to fix than if they had been caught earlier in development.
Late discovery of mismatches can cause:
- integration surprises: important details about how the solution should connect with external systems or workflows are found out too late
- costly reworks: project costs increase because major mismatches are only found after development is complete.
- missed deadlines: the right features arrive too late to support the client’s deadlines
As mentioned earlier, the customer proxy has sufficient insight and authority to accurately represent the client’s needs throughout the development process. This means that both the team and the client need to have enough trust in the proxy to act as the first line of validation. So, the customer proxy reviews progress continuously instead of waiting until the formal validation phase.
To prevent the late discovery of mismatches the customer proxy:
- reviews deliverables: checks work early to catch errors before formal validation
- documents issues: updates user stories and backlog items with needed fixes so the team can act on them quickly
- keeps the client in the loop: shares progress updates and potential issues regularly so the client stays informed throughout development
Proxy check at Tacta
In some of our teams we introduced the practice of a proxy check. When a user story is completed the customer proxy reviews it before it goes to testing. If the feature doesn’t align with the intended business logic, it is returned to the developer instead of moving on to testers. This approach helps prevent unnecessary testing effort and reduces costly rework later in the process.
Conclusion
If you can take away one thing from this blog is to think about customer proxies like your ambassadors inside the development team. It’s important to note that they don’t replace your involvement in the project. Instead, they complement it by ensuring your perspective is represented day-to-day while you still stay engaged at key milestones and decisions.
