Too many teams think if they build it the customer will simply appear.  But listening to the customer first isn't just smart, it's critical.  Imagine the following scenarios…

A group of plucky college kids churn away in their dorm room creating the next website  that takes the world by storm. After months of hacking away, the site is unveiled to the world and instantly becomes a runaway success.

A pair of developers spend their evenings around their kitchen table working tirelessly on the next killer app. After weeks of work the app finally emerges from the dim light of the kitchen to become the latest app store hit.

We've all seen the movies and read the stories, a group of outsiders create something completely under the radar that when unleashed on the world becomes the next runaway success. It's sexy, it's exciting, and it's inspirational to millions of young entrepreneurs. However, there's one problem: it rarely happens that way.

Sure there are the exceptions, like the Facebooks and the Angry Birds of the world. But what makes these stories so sensational is not that they're the norm…it's that they're the outliers.

In reality, products that are built inside the vacuum of a dorm room or kitchen often emerge only to a different kind of vacuum: silence. More often than not these products that have been built without customer input tend to miss the mark in meeting, much less exceeding, the market's needs. They rarely provide that “a-ha” moment or “scratch the itch” the customer never knew they had. Instead, these products are met with a lack of interest or impact, if the customer even looks at them at all. The end result is that the product of all of that work in the vacuum becomes yet another casualty of missing the mark.

Getting customers involved

Most companies test their product with customers during beta phases, but this late in development many critical decisions have already been made. These decisions can make it difficult to correct the issues brought up by customers during the beta process. Rather than taking advantage of the opportunity to learn how their product can better serve the customer's needs, many teams insist on spending this time trying to sell the customer on why the decision they made without their involvement is actually better.

Other teams take the opposite of approach. They spend endless hours interviewing customers before a single line of code has been written, instead trying to divine the customer's every want and need. These sessions are incredibly valuable and yield a fountain of user information about the day to day struggles and pain points a customer faces as well as what could make their life better. While this is a great start, unfortunately many of these promising teams then take their new found information away and disappear for the remainder of the development process. By the time they reappear they're often dismayed to learn that the customer's initial vision and the reality of actually interacting with the end product are often nothing more than a study in stark contrasts.

Customer involvement throughout the entire life cycle

What's wrong with these scenarios? In both cases, the team is seeking customer feedback. In both cases the team seems genuinely willing to hear what the customer says. However, in neither case does the team does set themselves up to respond to the customer's feedback in an efficient way.

In the first case, the team can incorporate customer feedback at the beginning but will never have the opportunity to course correct since the customer doesn't see the product again until launch. In the latter case, the the entire product has been developed on assumptions of the customer's needs that were never even validated. The solution is to involve the customer from start to finish. Incorporate the customer in the early visioning of the product, and make the effort to understand their needs. Then, as development begins, continue to seek feedback from the customer throughout the entire process, evolving the product as the customer's needs evolve in light of realizations about what your product can deliver.

If I'd ask people what they wanted, they would have said a faster horse

This quote, often attributed to Henry Ford, is usually cited as an excuse for not asking customers what they want when building a product. But unfortunately the quote focuses on the wrong question to ask.

Asking what a customer wants will yield less than stellar results…instead ask the customer what they need. What one thing would give them the edge against their competition? If money were no object, what would they do for their business? Spend time with the customer learning how they do business. Learn the pain points that have become so routine and such a daily part of their lives and they don't even notice them anymore. And most importantly, encourage them to dream and to challenge you on what they want…not what you want them to have.

But we're disruptive

And I'm very happy for you. However, being disruptive is not an excuse for not talking to customers. Even disruptive ideas benefit from feedback. Don't flatter yourself to believe that your the first person who has ever thought of disrupting the healthcare/financial/education market. You're not. Others have come before you and they have failed. Talk to your customers and understand why those others have failed. There's a reason your customers did not buy from those others, you owe it to yourself…and your product…to understand why.

Take the opportunity

We all want to build great products. We all want to create things our customers want. However, many of us miss an easy opportunity to gain insight into what our customers want by simply involving them in the product development process. Talk to your customers, you'll be glad that you did.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.