Dash to Discovery Before Delivery

World of Warcraft taught me about making better products.

“Leeroy Jenkins!” I shouted, as my avatar dashed towards the huge troll.

“Hold back!”, screamed Steve, “We’ve never fought this boss before!”

“Don’t worry, Steveo - I’m going to burn the sucker with my Hellfire spell.”

“But Hellfire takes 15 seconds and all your mana to cast!”

As the troll descended, I finished casting Hellfire. The game promptly notified me: “Troll is immune to fire damage”. The troll then eliminated my avatar in one blow.

“Oh man”, Steve sympathised, “I knew it wouldn’t be easy. Next time let’s try smaller spells before going ‘all in’ with Hellfire!”

Something in my head clicked.

When conceiving a new software product, it’s tempting for businesses to go ‘all in’ from the beginning.

Many people are assembled for many months to build software to serve many anticipated customers. But, once launched, we find customers are immune to our beautiful new product. Why?

The world is often more uncertain than we believe. Our brain injects assumptions so we can make progress. Unless we recognise and check those assumptions early and often, we can “do with great efficiency, something that should not be done at all”, as Drucker reminded us.

So, in an uncertain world, we must have “the confidence to act whilst being prepared to be wrong” as Teresa Torres eloquently suggests.

Humble, Moleskin and O’Reilly warn us of leaving assumptions unrecognised and unchecked for too long: “Whenever you hear of a new IT project starting up with a large budget, teams of tens or hundreds of people, and a timeline of many months before something actually gets shipped, you can expect the project will go over time and budget and not deliver the expected value.”

Torres clarifies how businesses can further inhibit learning inadvertently: “In the early days of software, business leaders owned discovery — they decided what to build. Discovery happened once a year in an annual budgeting process, where projects with fixed timelines were assigned to specific engineering teams.

“When teams learned something wouldn’t work, they were still expected to deliver it on time and under budget.

“Teams continued to be measured by what they delivered, not whether anyone used it or if it created any value for the customer or the business.”

The takeaway? Uncertainty is inevitable, but learning is a choice. Don’t dash ‘all in’ without checking assumptions - you may find the problem troll is immune to your solution.

Image credit: Exprime