Our team is trying to understand and adapt Scrum and other agile practices, but we can not figure out how to deal with customer feedback when there is no customer. Every document about the subject emphasizes how important is having the customer involved in every sprint and how having early feedback helps correcting problems fast and maximizes satisfaction to both sides. I understand clearly this point.

In our case, we have no single customer. We develop a website and a smartphone app for an already established and growing audience. I am sure this is a fairly common case so I would like to know some real world experience about how to apply and manage Scrum in this case. Do you just decide all features by yourselves or do incorporate user testing in the sprint? Any other solution?


8 Answers 8


We have an internal person represent the customers. This person talks to tech support to see what customers are requesting or having problems with. She also deals with our high-profile, mission critical customers directly. She talks to sales as well to see what potential customers are looking for. Based on all this feedback, she is the 'product owner' and puts forth the priorities from the backlog.


You need to be very clear about the difference of a Product Company, and a IT department of a company. The former is your case. We often see Scrum practices applied on the context on the second one; when you have the customer inside the company. But the first one is a totally different beast.

I have been reading about your concern and find two mayor sources having their own method but in essentially they teach the same principle: put the customer first.

  1. Steve Blank: Customer Development, see his book The Four Steps to the Epiphany

  2. The Silicon Valley Product Group (SVPG): and their book Inspired: How to Create Products Customers Love

I believe you will find all your answers on their work.


The customer is your audience. Now obviously that poses a problem, and to solve that you need to let yourselves represent the customer.

The difficulty here is being able to stand back from your work and make sure that you know what the audience really wants.

To help with this you can get user feedback, perhaps recruit some people from your audience to try out your work before you release it.

Most importantly you need data. Make sure that the changes you make are really working towards the happiness of your customers, this means statistics. Watch your numbers carefully whenever you make changes, and use that to inform how you progress.


The Product Owner hopefully understands the domain, users, application and can use different techniques to gather information from your current and future users.

This isn't that different from working with a large organization/enterprise. Just because there is only one entity paying the bill doesn't mean you won't be dealing with multiple managers, users and conflicting requirements. This can be worse because everyone thinks their requirements are absolute must have deal-killers.


Yes, in that situation someone needs to proxy the user's requirements. You can use tools to collect user feedback like Getsatisfaction.com but someone will need to decide the requirements. You may want to involve individual users for testing and validation but understand their requirements will vary.


Other answers have indicated the need for data, and for a customer proxy.

To facilitate both these, you are likely to have two potential resources available. Firstly any feedback you have received from your existing customer base - whether directly or via your platform provider. Error logs, faqs, feature requests, and the like. I appreciate that for a smartphone app these may not be accessible to you.

The second resource is the team member who is a professional pessimist - most teams have one of these. The guy who is always full of good logical reasons why what is being proposed won't work; why what is already available is all wrong; etc. Ask them what is wrong with the app, and then winnow the answers to identify improvements you can make, that can be incorporated. Your only problem may be getting the pessimist to turn off the list of flaws.


Look at what other web companies do to collect iterative feedback. This site uses a voting method to move good answers up. Google uses the concept of "Labs" to try out new ideas.

Establish "incentives" for repeat web users to meet with you. It can be as simple as inviting some users to talk with the lead developers. Humanize your site with a blog from the developers. The point here is that if you can't move the customers closer to the developers, then move the developers closer to the customer.

Having a knowledgeable product owner that meets with customers regularly is also valuable.


Depending on who your customer base is, and how much information you have about them (or can derive about them using companies like Lexis Nexis), one common way of addressing this dilemma is the use of "personas". Basically you build representatives of your customers (some places actually create big cardboard mock-ups) based on data you have. You name these personas. You keep collecting information about their likes and wants. Divide your customer base up into groups/tranches, and have a persona for each tranche. If possible, you locate the real customers who most closely match each tranche and interview them. Then, a person on the team tries to represent each persona.

It's imperfect, and it works better for information architecture (UI and stuff) than for deeper things, but it's at least an approach that has some value. It's been around for at least 10 years now.