Everybody fears being wrong. They fear that they’ll be embarrassed, or that people will look down on them. They fear that they will be given less respect and people won’t want to be their friend. We are generally told that if we aren’t sure we’re right, we should keep our mouth shut.
But in most endeavors, those who risk being wrong are the ones that come out ahead. They realize that nobody has all the answers, and that the quicker the discussion starts about what the right answers are, the quicker they’ll arrive at the right answers.
Seilevel’s approach uses this logic to drive the requirements process forward. We don’t hesitate to draw up a straw man model, a model that we know is incorrect, of any system, even if we don’t know very much about it. We use that model as a starting point, and the act of correcting it is how we arrive at the right answers. Even if everything in our initial model is wrong, it will push us down the path of getting the model right.
Certainly, when you use this approach, you must explain what you are doing. Tell your stakeholders that the point of the straw man model is to arrive at the correct model. Explain that you did not expect the straw man model to be correct. Setting expectations is critical throughout the requirements gathering process. The stakeholders need to know that once you hear their feedback, the next model they see will be much more accurate.
Being wrong is effective because it starts the discussion. Nobody likes staring at a blank page. They don’t know what to start with and in which direction to go. Seeing something wrong capitalizes on our natural urge to correct things. It is easier to critique the work of others rather than create something ourselves from scratch. That’s why there are more critics than artists in the world. The faster the critique rolls in, the faster you go down the path of getting things right. Any delay in getting the conversation moving in the right direction is a delay in achieving the right results.
In the end, those who dare to be wrong will end up seeing better results than those who don’t do anything until they are sure they are right. In the long term, almost everything we have created will end up wrong. Those usability features we added may not end up increasing usability in practice. Those products that we designed may not be needed anymore due to organizational changes. And those corporate strategies that birthed our projects may fail and be reversed. You’ll see that the “right answer” always has an expiration date, and if you don’t get started quickly, your time will have passed. Get started immediately by using what you already know to get momentum going, and then fill in the blanks as you go. That is the only way you’ll ensure that you get your product out into the world before the world changes, and then you can move on to your next attempt at getting things right.