One of the great things that has come out of The Lean Startup movement is the focus on customer validation.
Too many organizations I work with either gloss over this step or skip it entirely.
The process usually looks something like this:
- Customer reports a bug/requests a feature.
- Bug gets “fixed”/feature gets built.
- Bug/feature gets deployed.
It all seems well and good and you might expect “profit?” to be “profit!”, but is it? Did that bug actually get fixed? Does that feature actually solve the problem your client is having?
Most organizations don’t follow up to confirm that the customer is actually happy with the new situation or if they are even using the new feature! To make things worse, if the customer does complain that the bug isn’t fixed or the feature doesn’t solve their problem the response is typically, “We did what you told us to do”.
These days, being an order taker is not enough. If your organization sells itself on its ability to follow orders, then the customer will either go for the cheapest option they can find, or they’ll just do it themselves.
When customers come to you, they pay you to think! They’re looking for you to solve a particular problem they have. And someone who never validates the results with their customer isn’t a very good problem solver!
In one organization I worked with, we had set up a large Kanban-like wall that showed the progression of a feature through the system from when it was received until it had been deployed.
Once this wall had been setup and was being used, I added a column to the board called “Validated?” after the deployment column.
At first, the response was, “Well, it’s deployed, of course it’s validated” or “[internal person in the company] saw it and is fine with it”, to which I would typically respond, “Well, have they checked with the actual customer?”
In the latter case, the next time I checked in, the person had followed up with the internal person and discovered that no one had told the customer that their issue had been fixed!
This was a frustrated customer who was working around the issue in the interim and was very close to no longer being a customer. And now, a month after the bug had been resolved, no one had told the customer!
I wonder how many customers the organization had lost over the years just because no one told them when their problems were solved?
The impact of not validating your results is not just limited to customers. There is nothing more demoralizing and demotivating than working on a feature that never get used.
While investigating a separate issue, a developer I once worked with discovered that a feature he had spent three months developing had not been used once. He was furious! Three months of his time wasted on something no one was using!
Every organization I visit has a business case for why the feature they want should be built, but so few actually check that what they built was worth the effort.
That’s why it’s always important to build the smallest thing you can and validate it as soon as possible.
Today’s image by joeltelling.