Doing More By Doing Less, and Having Options
The Rule of Three
Some threads on LinkedIn got me thinking about the value of problem analysis. Often, as software developers, we start solving problems — sometimes prioritizing effort over results — and forget that we add the most value by solving the right problem in a timely manner. (A fun book about finding the right problem that inspired me is Are Your Lights On.) I wrote about this in November 2009, and with some minor edits the approach here makes sense in many contexts that involve managing limited time,
Have you ever been in a situation where someone walks into the room and announces that they just got off the phone with a customer you need to add some functionality, described in very specific terms. As described, the feature could take a lot of work, so you bounce around some ideas about how to do what the customer asked for. Along the way, you realize that maybe, perhaps, there is another way that you can add a similar feature that meets the needs at a much lower cost. But no one asked the customer what problem they wanted to solve. So what do you do now?
Some options are:
Saying, sorry, we don’t really know what the requirement is, so come back when you have more to say.
Spend the next couple of hours discussing and planning how to implement all the options you consider.
List some options for what the customer might really mean, then delegate someone to investigate further, using your options as a basis for conversation.
Option 1 sounds appealing but doesn’t help you solve the problem of efficiently building (eventually) what the customer wants. While option 2 has you thinking about the problem and solutions, at some point, you’re making the solution more expensive than the customer probably wants it to be. This is an easy scenario to fall into since people in general, and engineers, in particular, want to solve problems. But a long conversation without data doesn’t solve this problem and keeps you away from making progress on other problems that you know enough to solve.
The third option is a good compromise. Spend some time discussing what problems the customer might want to solve, focusing on the problem, not the solution (implementation). Then, spend a few minutes figuring out how you might implement each proposed option so that you can attach a cost to each. Then, delegate someone to have a follow-up conversation with the customer using your options as a starting point. Three options is a good rule of thumb.
It’s very easy to get caught up in solving problems without asking if you’re solving the right problem. Whenever you’re asked to build something very specific, ask yourself if you really understand the problem. By taking a step back, you can save time and, in the end, have happier customers.
(For more on figuring out what the problem really is, see the appropriately named book Are Your Lights On?: How to Figure Out What the Problem Really Is.)