The Potential Cost of … Zugzwang?

---

Comparisons have long been made between chess and business. Kasparov (2007) wrote a whole book about it. Here I’d like to apply an old chess concept specifically to product work. In doing so, this is not to suggest that product work is a “game,” no more than discussing product strategy should imply it’s “war.”

I’ll present this as a sort of vignette. Let’s say your PO has been asking customers/users what they need, adding ideas to the backlog, prioritizing what users insist is urgent, and yet their response is…less than enthusiastic. And so you continue to “iterate.”

The word is in quotations. This is because agilists can’t seem to agree what it means. We’ll go with Jeffries’ definition. You rinse and repeat your timebox (iterate) and add increments to what you’ve built. Unfortunately, as your PO asks users what is needed and tasks you with addressing these “urgent” matters, user satisfaction does not increase.

If anything, users seem to get increasingly annoyed. They are losing patience. You step out on a limb. “Perhaps,” you posit in the retrospective, “customers and users cannot simply TELL US what is really needed. Perhaps—wild thoughts here—if we’re already building the wrong thing, iteratively adding to it may not solve the underlying issue.”

Perhaps this is something the customer often can’t voice in the first place. The PO poo-poos you (or PO-POs you), and yet users ARE fed up. You think of your hobby, chess, and realize the team is in zugzwang. It’s a German concept. Sounds like “tsoog tsvahng.”

The PO has made a series of tactical errors and now, no matter what the team does next, its position WILL get worse. You’ve worked yourself into a corner. Below is an example. It’s Black’s turn. Black has moves left she can make, but it doesn’t matter. Whatever she does, it’s basically game over.  

---

---

---

And so it is with your Agile team. You eschewed your opening game, dismissing design research, strategy, and problem framing as horrendous “BDUF.” “We’ll just iterate our way forward,” the PO continually insists, and yet the result is a gallimaufry of kludged responses—and users have lost patience.

They’re now largely just humoring you. “I’m sorry,” you tell your PO, “I disagree. I don’t think you can just bank on winning back user patience and trust once it’s lost. Frankly, it’s of limited supply as it is.” He looks at you like you’ve grown a second head.

As your team continues to iterate, past a point the users increasingly turn to their own workarounds, building idiosyncratic solutions, generating “shadow IT.” There is a sense in which your iterating is now driving up costs. But it’s not your PO’s problem.

---

---

---

Your PO loves to quote Teichmann: “Chess is 99% tactics.” You’re the only one on your team seemingly aware of Heisman’s reply: “No…tactics just take up 99% of your time.” That’s not the same thing—neglect strategy and the importance of the opening game, and you’ll lose.

You think of the “double diamond.” Wodtke says it’s more a “diamond necklace.” Of course, it’s a loop, but the chess analogy is weak here—product work has even more strategy. Here the middle game is also strategy. The PO just wants to ignore it. He only cares about the end game, execution, tactics. That’s still most of the work, of course. After all, the x axis isn’t time.

---

---

---

A strong opening game would add some time and cost up front, your PO kvetches. Yeah, and you were sick last night and didn’t want to take any NyQuil. Instead you spent hours lying awake with aches, trying to sleep well. The NyQuil is like the oft-maligned “BDUF.”

You think of the graph below. Where did all that opportunity cost go? It’s gone. Your PO doesn’t care. “It’s 99% tactics,” he says. Story points for strategy? For upfront design research? For problem framing? Heresy! Customers order pizza and we DELIVER!

---

---

---

And yet your PO is wrong. The possible number of moves in a single chess match is so staggering that a googol (a one with 100 zeroes) is small in comparison (Chernev & Rienfeld, 1948). And so it is with product work. If asking users what moves to make doesn’t cut it, what can one do?

From this notion of zugzwang you arrive at an epiphany. No wonder Agile and User Experience Design (UxD) have long been at loggerheads. Most Agile teams are selling a SERVICE. Duh! Agile itself comes from the assumption that the customer knows what he needs.

As the cliché goes, “The customer is always right.”

UxD comes from the assumption that what the customer says is the problem IS SELDOM THE PROBLEM. What the customer says is the issue, says she needs, is seldom where you should focus. UxD isn’t selling a service at all then, it’s selling EXPERTISE. It’s an oft-overlooked difference.

---

---

---

If the customer was usually right, then they wouldn’t need your expertise. They could just place a drive thru order with the appropriate Agile team. In fact, you consider, Agile teams that build whatever users say they need are sort of like doctors that prescribe whatever meds their patients ask for.

These are not just conflicting ROLES then, which is often how this issue is framed. They’re based on different assumptions which suggest entirely different engagements and MODELS OF WORK.

So how can one avoid this zugzwang?

This is another key difference. Agile bets the farm on iterating through it. UxD disagrees. One must improve one’s opening theory.

It’s not BDUF—it’s only the most important part of the match.

---

---

---

References

Chernev, I. & Reinfeld, F. (1948). Winning chess: How to see three moves ahead. New York: Simon & Schuster.

Kasparov, G. (2007). Life imitates chess: Making the right moves—from the board to the boardroom. New York: Bloomsbury.