26. Straw Man

Team members feel comfortable offering a straw-man solution in order to elicit early feedback and insight.

A straw man is not an abstract model. It is a solution. It may be an incomplete and/or incorrect solution, but you intentionally offer it up to solicit client criticism. Your purpose goes back to the world’s oldest systems joke:

Clients don’t know what they want until they see it . . . and that’s not it.

Any really funny joke has a grain of truth in it, and this one is no exception. Clients simply do not know what they want because they have no idea what they can get. The best analysts do not try to analyze their way to a solution. They analyze for some insight, make a minimal commitment to a solution or part of a solution, and quickly offer it up for reaction.

Straw-man models are a form of requirements bait, to borrow a phrase from Steve McMenamin. You present clients with idea triggers to draw out their likes and dislikes. The models are quickly done, and they’re cheap because they’re wrong. The client reviews a mock-up, prototype, or storyboard of the solution—say, of the “Homes for Sale in the Selected Area” screen. It’s a simulation of what the world will see in the future; in exchange, the client leads you to the real requirements.

The best analysts try to avoid asking, “What do you want?” They recognize that this is often an uncomfortable question. People hate to create an answer from a blank piece of paper, but they do not mind critiquing what is already on paper. Consider this test:

Which task would you be happier taking on?

1. writing a report for your executives, on the pros and cons of building a new data center

2. reviewing a report on the pros and cons of building a new data center, before the report is sent up to the executives

Most of the world is much more comfortable with number 2. Humans are effective improvers, naturally, and few of us are naturally comfortable creating from whole cloth.

At the start of a new project, I was at a meeting in which an executive said, “I don’t answer questions.” This struck me as odd at the time, but in context, he was really saying, “Don’t spring on me any open-ended questions that I haven’t had a chance to think through. Don’t put me on the spot.” He was absolutely right. He preferred to have a straw man to point at, to help him decide yes or no.

—TRL

The very best straw-man models may even contain intentional errors. Analysts mar the models to keep the client alert and to signal that unfettered criticism of the model is completely acceptable. This takes a tough-skinned analyst, one who can accept “playing the fool” as an advanced practice, to accelerate convergence on a solution. It is the highest form of the straw-man art.

Straw-man modeling is useful whenever people iterate their way to a solution. In addition to straw-man requirements analysis, consider straw-man software design. Offering the design team the first design that comes into your head has three possible outcomes. All are winners:

• After some review, the strategy behind this particular design is outright rejected, and another straw-man design, based on a different design strategy, rises to replace the first.

• During inspection, designers make incremental improvements to the design and eventually agree on a preferred design.

• A miracle occurs, and the straw man is found to be the chosen design. (We have never seen this happen, but it could happen someday, somewhere—just don’t count on it.)

The philosophy of the straw man is that by being wrong early and wrong often, you’ll get to right as soon as you can. The problems we all face and the solutions we derive are too complex to spring fully formed from the mind of any one person. Get tough and ask, “How’s this for an idea?”—even when you know you are flat-out wrong.

Many of you may think that you use straw-man strategy already, but have you ever had someone point at your mock-up and laugh out loud? That is straw man.