They Don’t Know What They Want Until You Give Them Something Else

Steve Grandfield is a Blue Cross Blue Shield of Nebraska executive. (You might know the company as Nebraska Blue.) I heard him speak to Omaha Agile Development last week. Oh, my! How times have changed! Among other things, he said something very close to the title above, speaking about business customers.

I need to digress. (Sorry!) I want to send well-earned kudos to Steve, his company, and his company’s employees for the open house last week. It was an impressive display of talent, organizational change, and community interest. And as long as I’m throwing out kudos, Client Resources earned them for sponsoring and supporting the event. And Omaha Agile Development earned them for another in their continuing series of interesting and helpful presentations. (Can they possibly manage to do another good one next quarter? Join them to find out!) Well done, all around! And … back to the subject …

In prior days (“yesteryear”, in Garry-speak), the above title statement could well have been introduction to some boo-hoo about how tough it is to serve customers. “We toiling slaves in (fill in the blank with your favorite service organization; Steve talked last week about information technology, IT) have it so rough!”, the diatribe starts. “We’ll build anything our customers want. Wouldn’t it be nice if just once, they’d tell us what they want?! Well … they do … but they usually tell us late in the project when we’re panicked about meeting deadlines. And they tell us we have it all wrong. And they’re usually yelling at the time. Oh! Woe is us.”

Well … of course that boo-hoo-er spoke truth. They accurately described the environment from a partisan IT perspective (you picked up on the embedded “us vs. them” attitude, right?) They reflected IT frustration. Of course, there was similar frustration for the business folks. Many of them longed for the days when IT would be more affordable. (Funny thing, IT costs seem to be coming down faster than lots of people planned for … maybe that helps explain the timing of this subject. But I digress …) Many business folks saw IT as simultaneously skilled and inflexible; they wondered sometimes whether IT was more effort than its value.

Steve Grandfield’s message wasn’t the above; that would have been so … well … yesteryear. (Yes. It was fun expressing it that way!) His point was that none of us must feel trapped in the condition the boo-hoo-er describes. He points to market agility as a viable alternative goal. (Scrum, Lean, and Kanban are examples of advice to achieve agility. There are others.) He suggests the condition described as a prime motivation for changing.

Steve says that because the user cannot tell us what they want, we’ll do well to change our ways. I see him as suggesting pursuit of one of the common values among agile frameworks: get feedback early and often. That is, build a little working code. Then, inform the business user how the demonstration code is similar to the product you think they want (and how it’s different), and ask the business user what they think. Many business users, having described their ideal product, see this demonstration and can suddenly better describe the ideal. (That would be the subject title, right?!) The agile frameworks advocate using that condition to the service provider’s advantage. They argue that service providers would rather hear from business customers early than late that, “That’s good and I’d love it if you could also make it do …” And they argue that the earlier service providers hear that feedback, the more time they have time to adjust. The agile frameworks give service providers a better chance to deliver (really) the product that delights. “Delight” is not just an empty ideal any more.

I don’t recall that executives of yesteryear called for these processes. More and more of the market is adopting these ideas.