Do as I want, not as I say
A whopping myth of software development is that customers know what they want – and can explain it to you. If that were so, no one would have ‘unmet needs.’ Software forums wouldn’t be a digital hailstorm of hostility (“worst support EVER! F&$%…”). And, every rainbow would be a double rainbow.
Customers know what they like, not what they want. Agile makes that distinction, but it doesn’t make you a mind reader. The question is, how do you figure out what customers want?
For our new ebook, Contested Development, we interviewed Baldeep Sadhal, Asst. VP of Customer Experience at AT&T. Baldeep is ridiculously modest, so I’ll brag on his behalf. He dominates the tech and business sides of Agile the way Tony Dungy won Super Bowls as a player and coach.
Here’s what Baldeep said: “Agile recognizes that customers don’t know what they want. They may have a sense of their needs, but, try as they may to define them in one go, their wants will change and evolve. Trying to perfect the requirements and build the entire product at once is a failing proposition. Agile embraces this fundamental issue and focuses on quick iteration.”
When Dungy was still coaching, I’m sure he planned each football game. But, I bet he didn’t expect players to follow his plan dogmatically, regardless of what happened on the field. Likewise, as Baldeep points out, it’s absurd to believe that businesspeople can read minds, see the future, and perfect a product before developers build it.
Mike Tyson, the boxer and theoretician, said it best: “Everyone has a plan ’till they get punched in the mouth.” Waterfall plans have good intentions but bad track records of survival. Every software plan gets punched in the mouth.
If you can’t predetermine what customers want, and they can’t tell you, what do you do? “Quick iteration,” as Baldeep said. Deliver software to test your hypotheses about what customers want.
Each software release is an experiment. If you release once every two weeks, you experiment once every two weeks. If you release software daily or multiple times daily, you run trials that often. To be clear, not every company can or should release that frequently. Sure, change Facebook all day long, but don’t change a defense contractor’s ERP system every hour.
Regardless of how often you release, you get feedback. Customers and business clients use the new features, or they don’t. They spend more time in your app, or not. They say nothing in your forum, or, with all their misspelled might, try to hurt your brand’s feelings.
Underneath the anger, entitlement, bad days at work, life regrets, etc., forum trolls are trying to provide guidance. The message is, “Do as I want, not as I say.”
People don’t actually want your company to go fill-in-the-blank itself. They want you to try again. And again. And persist until, for a moment, you attain software nirvana. It won’t last because needs are ephemeral and always changing. But damn can that moment of nirvana be lucrative.
Experimentation beats planning. Listening beats mindreading. Agile beats Waterfall. And our new ebook, Contested Development, beats the jargon-filled Agile content you’re used to. Give it a read.
