Customer involvement to reduce time to satisfaction

In my previous post, I discussed time to customer satisfaction. Much has been written elsewhere about customer involvement as part of a user experience program.  Prototypes, wireframes, and other techniques are well documented. As such, I'll avoid these topics. There are, however, two items that don't receive the same level of attention (or at least I haven't seen them frequently). They are the focus of this post.

Early involvement via sprint demos

Agile advocates that stakeholders (or proxies in the form of product owners) be part of the team.  This is an admirable goal, but I've yet to see it occur in practice.  This may be due to my experience in product development companies, where the "customer" is a market, not specific people.  While I've not had the opportunity to embed customers in my teams, there are ways to integrate them in your process.

Make each product owner responsible for cultivating a cadre of users.  These users are people heavily involved in the operational workflows for which the product is intended to be used.  Beginning with the first storyboards, this collection of users participates in sprint demonstrations.  They are made aware of the user stories delivered and the user stories being considered for the next iteration.  As the product is demonstrated, they can immediately confirm or correct workflow and visual designs.  I've even witnessed users helping each other understand how to use the product, thereby eliminating feature requests entirely.

This group also is a sounding board for questions or ideas that come up during the development process.  It is not unusual for product owners to have multiple user contacts through an iteration.

Advisory boards

While iteration demonstrations are tactical, advisory boards are strategic.  Look for people with industry breadth and understanding of operations within their organizations.  Advisory boards are critical to ensuring appropriate major product features and workflows.  Instead of focusing on iteration deliverables, this group guides you to determine priorities of competing major features, high level workflows across features, and your standing relative to competitors (within ethical and legal constraints).  

You will want 8-12 people representing multiple dimensions of your product. For example, a product for physicians would have an advisory board comprised of multiple specialties, geographies, and EHR usage. I encourage you to have non-customers represented, as well. They are highly likely to provide you completely new ways of thinking about problems, since they don't "know" your product or its workflows.

Most importantly, you want this group to tell you where your strategic mistakes are - before the market does.


These two groups can tremendously impact your ability to deliver a highly acceptable product to the market. They help refine workflows and visual designs, thereby decreasing the time to customer satisfaction. Equally important, the people involved throughout take a high degree of ownership. They become product advocates, since it is their product design.

Bad idea filtering

Some teams seem to consistently end up with better decisions.

While not downplaying individual contributions, I believe the way the team brings ideas to life (or kills them) matters most. It isn't about starting with more good ideas.  It's about creating a culture where good ideas are refined and bad ones are eliminated quickly.  In other words, they have a better Bad Idea Filter, and the means to make mediocre ideas good (or great).

I've found two factors to influence idea quality: challenge and collaborate.  They are blended; so much that my team coined the phrase Challaboration.

We challenge practically everything.  If you propose an idea, you will defend it against technical, business, workflow, and visual design critiques.   One person is unable to consider a variety of consequences, barriers, and alternative solutions.  A team of people with varied experiences can. If the idea cannot be defended, then it doesn't survive - even if it is mine.

With multiple solution paths explored, the resulting decision is more resilient.  It draws from improvements to address previously unforeseen aspects of the problem, while minimizing weaknesses (or at least making them known).

If challenging is behavior, then collaboration is motivation. Team members receive and provide critiques to the idea, not the person.  This isn't about scoring points; the desire must be to reach the best decision the team can make.  When I challenge a design, I do so to make it excellent. I want the other person and the team to be successful.  Thus, I challenge.

The motivation for the critique matters.  If the motivation is to increase quality results, better ideas emerge.  If the motivation is to show personal intelligence or to score points, bad decisions slip through.  Worse yet, idea generation itself shuts down. 

Your team gains confidence as they struggle with criticisms and pursue alternatives.  When external groups and customers provide input, frequently it has been considered in depth.  Your team is prepared to acknowledge inputs and explain how they were considered, enhanced, or rejected.   In turn, your team's confidence provides confidence to the customer.

Challaboration is a core value of our team.  Each person has a responsibility to assist in crafting a better solution.  They also have an obligation to identify weak ideas and prevent them from harming the team, product, and customers.  These are key, since our team doesn't start with more good ideas than most teams.  It just has a pretty darn good Bad Idea Filter.