In a list of the top things we don’t spend enough time doing, clearly defining the key problem a project must solve ranks right up there with flossing and hand washing.
“Users don’t trust us,” somebody will say.
“Yeh,” somebody else will agree, “We better be more transparent.”
“Hey, let’s launch a blog to talk about our decisions and let users be part of the conversation!” the dude in the corner might say.
“Oh, blogs are cooooool!” people around the room squeal and so you spend several weeks talking about your new blog.
Because of poor problem definition, the mission statement for the blog gets bloated, becoming a mosh pit of overly ambitious, even contradictory aspirations. Because of poor problem definition, there are no metrics to effectively measure the blog’s success or failure. Because of poor problem definition, development goes through revision after revision until finally the team realizes that a blog wasn’t the right answer.
This scenario probably sounds familiar: we all tend to intertwine the description of WHAT needs to get accomplished with our visions of HOW it needs to get accomplished and as soon as we start talking about The How, we stop making forward progress on defining The What.
When members of your team start to intertwine The What and The How, help them talk about the two separately. Record their comments about The How to prove that you’re listening, but then set the comments aside until you have a well-defined What.
Beware of upper management getting involved in the conversation. They will speak regularly, and with great authority, about The What and The How as a single thing (especially when they don’t actually understand either.)
You also need to keep an eye on your best problem-solvers (whether they are experts of The What or The How) because they might have a hard time not jumping to The How too early. Don’t let them.
