There are times that your customer will ask you to do something so you do it. But did you stop to ask them about why they need that done? The story here is an old one that you might have heard but recently someone gave me an addition to the story and it blew my mind.
If someone comes to you in the hardware store and asks for a quarter inch drill bit, what do they actually want? Quarter inch holes. A drill bit is just a tool and if there’s a better way to give them the quarter inch hole, give it to them.
The addition was, now ask why they want quarter inch holes… Turns out they are hanging a ceiling fan. Ask them why they are hanging a ceiling fan. Turns out they are trying to sell their house and they were told that a ceiling fan in the bedroom would help. Ask if you could come take a look… Turns out that the paint outside is faded and cracked so the reality is that when they asked for a quarter inch drill bit, really they needed 5 gallons of paint and a ladder and in all honesty, they should slap you for selling them the drill bit.
I’ve been reflecting on this a while and I’ve come to the following…
I’ve long had a philosophy that I’d like to
“Do something, anything, even the wrong thing, learn from it and iterate.”
This has been my guiding light and has helped me keep from getting stuck in analysis paralysis and drives the analytical people around me absolutely nuts (Looking at you Gary Sweeting…) 🙂
That said, I was talking to my new friend that I met at Collision Conf this week, Bas Wouterse (CTO at http://telm.nl), and I realized that I’m slightly off there. It was an aha moment for me as I realized that I’ve been voicing my actual process wrong for years.
Here’s my new motto
“I’d rather do the wrong thing than solve the wrong problem”
The original motto still applies once I figure out what the problem is that I’m solving but it’s not enough to just start doing stuff. I was out with a young developer who asked what’s the difference between an architect and a developer. My answer was “An architect is an experienced developer who cares about the requirements phase of the project.” And that’s the case. I care about the requirements. I’ll investigate until I get a grasp of the problem. Then I’ll start doing stuff in that direction. I’m normally wrong in my approach the first several times. However, as I get more experience, I have gotten better about being less wrong about my direction even in those early phases. The trick is to quickly realize that I’ve made a mistake and fix it. I don’t try to make mistakes, however I’m not scared to make them.
The biggest mistake though, as I’m learning from my previous mistakes, is to solve the wrong problem. It doesn’t matter how correct your solution is if it’s the wrong problem. This goes from macro to micro.
At the macro level, I’ve met a ton of startups who are solving the wrong problem. Normally this means that they are solving a problem that their users have but not solving a problem that their potential customers have. Noodle on that a bit… 🙂
On a micro level, customers always tell me that X is not responsive enough or something very generic and sweeping like that. Rather than digging into the speed testing and all that, I ask them what they mean and start unpacking “responsive” means to them specifically. Often it turns out that you and your customer have very different definitions of responsive. Once you figure out what responsive means, anything that you do to solve the responsiveness issue has a much higher probability of being a step in the right direction.
Summing up, spend the time to ask that next question that will get you closer to solving the right problem.