Current Articles | RSS Feed RSS Feed

The customer is always right, but he can't design your product

Posted by Andy Singleton on Mon, Nov 10, 2008 @ 01:13 AM
 

We recently added a customer request page - feedback.assembla.com  - from the folks at Uservoice.  Although we have so far only received votes from a tiny fraction of our user base, we have already learned a lot.  The top two requests - a customer login with special permissions, and the ability to tune permissions inside a space - are really two views of the same request.  "Customer login" is a clear statement of the request.  The requester wants to invite his customers as users, but show them a special customer view.  "Custom permission for tools" is a suggested implementation. Our blog comments contain a third closely related request - lower charges for customer roles.

So, we have learned what users want.  Users are experts in what they want - the ultimate authority.  However, they are far less expert in figuring out how to get what they want.  They are perfectly happy to suggest an implementation, but if we follow that suggestion directly, we are likely to get a bad result.  That makes sense.  Designing our product is not their area of expertise.  It should be ours.

Customer implementation suggestions, so readily offered, will typically pose two problems.  First, they may be impossible, because the customer doesn't know all of the constraints.  Second, they are almost always purely incremental, rather than innovative, because the customer hasn't studied all of the options.

For example, a customer might come to you and say "I want to travel from New York to Los Angeles in less than seven hours."  Great idea.

But, if you ask the customer how to design the product, he will probably say something like: "I use my car to travel to other cities.  I want you to boost the car to 2000 horsepower, streamline it, and build a very, very straight road.  Then I will drive to Los Angeles quickly."

This customer is making a series of logical and incremental extrapolations from the current product.

The engineer assigned to build this product quickly sees that the customer's design won't work.  He comes back and says "We can build a jet airplane that will fly through the air at 600 miles per hour, and we can build an airport in New York, and an airport in Los Angeles."  That would work.  But, it's a non-incremental solution, a completely different approach.  It requires expertise about the available options and constraints that the customer does not have.

So, now we have the following request, which I will paraphrase as "I want to be able to invite customers and give them a special and controlled view of tickets, documentation, and status."

The suggested implementation - a special set of permissions for someone with a customer role - poses a few problems.  If a customer has permission to see one tool, but not a linked tool, he will get "Permission denied" from some links.  We will need to assign a new user role for customers, and the team owner will have to manage those roles, without getting confused.  If it's not completely simple and clear what is included in the customer permissions, there might be security leaks where the owner inadvertently reveals more than he wanted to reveal.  The product is already complicated. We want to make it look simple for the user.

Time to put our thinking caps on and get to work.

 

Tags: ,

COMMENTS

http://freelanceswitch.com/clients/12-breeds-of-client-and-how-to-work-with-them/ 
http://www.wakeuplater.com/freelance-lessons/10-absolute-nos-for-freelancers.aspx 
 
Have a great time reading those!  
:-) :-)

posted @ Thursday, November 13, 2008 7:16 AM by Ted


This is a wonderful post. Good stuff. I wish more start-ups and web shops would embrace this a little more.

posted @ Tuesday, November 18, 2008 4:54 AM by Arik Jones


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: