Main menu:

Site search




The Off-site Customer

Vidoe conference Most of the original agile methods have an explicit or implicit assumption that there is an on-site customer; a customer working in close proximity with the team.  Having the dedicated attention of customers who can write or help write user stories and provide continual feedback is a great idea.

I confess however that I’ve never been on a project where we had an on-site customer, yet we’ve been able to cope. The reality that I’m more used to is attempting to build a product for a diverse group of end-users, most of whom are off-site (or far enough away that they might as well be) and too involved in their daily work to pay much attention to what my team is doing.  This “degree of separation” from users mostly limits feedback to bug reports and feature requests; users are typically good at pointing out problems and are rarely able to see beyond their immediate work. And this means you can’t count on consistent priorities or even requests; that even if more than one user requests a feature you can bet they have a different idea of how it should work.

A worst-case outcome when dealing with a diverse customer base is a frustrated team and users. One symptom of this type of environment is silent users, who put up with poor workflows and stop speaking up because they feel their input isn’t being heard.  And your team will complain about users who are never satisfied, constantly changing requirements even with upfront definitions, and who don’t give feedback until it is too late.  Water-cooler grumbling conversations rule.

Here’s a paragraph that my friend Kevin Tureski from Alias sent me which speaks to the heart of this problem: “A fundamental premise of agile development is that by adapting to feedback on working software at each iteration you can spiral inwards to a solution that provides better value than is possible by holding a detailed upfront definition constant. But what do you do when your end users (or end user representatives) don’t provide a clear consensus on what they want or change their minds each time their input is needed or aren’t very accessible? How can we ensure that the project doesn’t spiral outwards due to conflicting or changing requirements? How can we find the right balance between ‘barely essential’ requirements while preventing feature creep?”

What to do? Here are a few things that have worked for me.

Start with your Mind-set

Start with your mind-set about the kind of relationship your team has with end-users.  Instead of referring to end users automatically as customers, see if you can think of them as partners instead.   The reason is that if you think of them as customers you are re-inforcing a degree of separation that might work in the restaraunt business but rarely works in the high-tech industry. 

You don’t decide what a successful product is, the end-users do.  You need to engage them and involve them in novel ways and build an environment where everyone is working together to create the best possible solution, where ideally there’s a joint sense of ownership.


If you want users to be engaged with your team you have to give them as much visibility as possible into your work.  Hold regular status updates and show them your priorities.  If you’re dealing with a number of teams or companies try and get them all in the same room for the status updates and give every single person the chance to give you feedback on your progress and plans.  This is a great way to bring out discussions on conflicting and overlapping requirements.  And don’t hold back: if a project isn’t going well say so, why, and what you’re doing about it.  This kind of transparency helps to inspire confidence in your team.

User Representatives on your Team

The Scrum agile development method has the role of a product owner.   It’s a great idea.  You need someone who owns the problem of speaking to end users, watching them work, and bringing all the feedback with clear priorities to the team. 

In my experience a role that is just as critical as a product owner is someone who uses your product in realistic ways.  E.g. if your product is used by 2d artists hire one or two and seat them in the middle of your team.   They will speak a different language sometimes but encourage and treasure that because they can speak to end users in terms they understand and will learn to translate what is required to your team.  And if at all possible, try to keep your user representatives working on a realistic project just as users would use the product.   You can use their work for demos but their work will help push the product and find problems faster.  It’s critical that you orient your testing towards more realistic scenarios as opposed to doing mindless sweeps through the product looking for bugs.

Feedback, Feedback, Feedback!!!

You can never get enough feedback.  Be creative and use as many different ways to get feedback as you can.  Do demos at the end of every development cycle.  Hold user focus groups.  Do usability testing with paper prototypes and working code.  Write user stories and run through them with end users.  Get them involved in planning of features they care about.  Do surveys, especially if you can get anonymous feedback.  Make it super easy for end users to report problems to you; anything you can do to lower barriers to providing feedback.  Be creative and find the people who give the best feedback and work closely with them.

Have a Vision

If you don’t know what your future is chances are you won’t have one.

Have a vision and longer-term goals.  Unless you’re on a one-off project, this is critical.  Very few end users can see beyond their immediate problems.  Find the people in your user community who think longer-term and involve them in regularly reviewing longer-term priorities and goals. 

Create the vision yourself if you have to.  If you don’t have an idea where you’re going you’ll spend all your time responding to requests, and in my experience what usually results is that users get more frustrated over time.  Your team will too; one of the strongest motivators for people is working on a project that is bigger than themselves, that is challenging, and that has a future. 

Ensure that the majority of the work you do is helping to build for that long term.  That doesn’t mean you avoid doing what users ask for, it means that you do that work in a way that helps build towards the future.  And yes, that means avoiding quick fixes.  If you have to slap a project together under high pressure, do a prototype and be prepared to largely start again if you have to. 

Clear Priorities

It’s critical that your team has a clear sense of what is important and what isn’t.  I use a project kanban board in a visible place.  It has three columns: highest priority (95% of the team’s effort goes here), next  (5% effort), and parking lot (0% effort).  I also keep a spreadsheet backlog where I keep good ideas and old parking lot items.  The key idea is to keep only the features the team is currently doing in the first column.   That sounds easy but it requires a lot of discipline because you need to use the board to have pointed conversations when a seemingly high priority feature comes in.  Have discussions like that in front of the kanban and if it really is higher priority figure out when and how to slot it in.  The kanban helps avoid making decisions purely on gut feel and constantly changing priorities which can impede a sense of progress.

Get the Facts

 Don’t rely on gut instincts to find out how your product is used.  Another post is coming on this topic shortly, but the idea here is to automate gathering of data on how your product is used, how often they use it, and the problems they have.  Think about all the data that Google has on you; why can’t you gather the same kind of information?

Give them a Sense of Ownership

Find as many ways as you can to get end users involved in the project.  One idea I like is to form a guiding council, where you get representatives from different companies or teams together to give you input on direction, priorities, and focus.  Great conversations will result and the increased transparency is good for everyone.

Another way to give a sense of ownership is if you can open source your project, especially if your end users are in the same company.  This is another form of transparency, but it also allows you to create workflows where they contribute to the project too.


The end goal in everything you do is to make sure your end users understand how critical they are to the success of the project.  You have to work extra hard to get them involved, but in the end it’s worth it!


Comment from Valery Slemmons
Time November 8, 2010 at 12:18 pm

I’d have to consent with you on this. Which is not something I usually do! I love reading a post that will make people think. Also, thanks for allowing me to speak my mind!

Write a comment