The title of today’s screed isn’t a question – it’s a recommendation. It’s been my experience that we spend an awful lot of time paying attention to and arguing about the “how” and in the process we often lose sight of the “what.” Let me explain what I mean and then you guys can straighten me out.
When my clients are working on a tech solution to a problem, they often get the engineers involved early on. This is a good, important thing. However, often the discussions rapidly morph into how something is going to get built rather than what is going to get built and why. The “what” is about the problem we’re solving or the reason why we’re developing a product feature. “How” involves weighing the different options we have to make that solution possible (and often we figure out that there’s no way to get to what we want). People will argue for extended period of time about a color – that’s a how – rather than if the page providing a solution to the problem – that’s a what. As an aside, usability testing is how we figure out if the “how” for our “what” is working and saves an awful lot of discussion. Bringing in the technical team after the business requirements are done can save a fair amount of wasted energy.
It’s the same in a contract discussion. I’ve had lawyers get both parties tied up in the “how” and I always try to bring the discussion back to what we’re trying to achieve. After all, if you’re going out to dinner, it’s less important which road you take to get to the restaurant as long as everyone is clear as to where and when we’re meeting, right? There are infinite ways to write a clause as long as everyone is in agreement as to what it’s doing in the agreement in the first place. The lawyers can help with the “how” but the business people need to figure out the “what” of a deal and define it clearly before the lawyers document it. You might be surprised how quickly things can get sorted out with a “what” focus.
I’d encourage you to keep things on track and simple by asking, answering, and constantly restating the “what” questions with your team. Screen layouts, design elements, language, etc. aren’t business requirements (those real “what” issues) yet we tend to get bogged down in their minutia. Great managers keep an open mind about the “how” while being laser-focused on the “what”.
Thoughts?
Consult Keith 