What’s your problem? Don’t answer so fast…

wrong-questionI want to give an example about the type of detail you need to strive for when starting a new project.  It might be more helpful than an analogy, which I’ve written about before.  I’ll try to keep the technical background to a minimum, and apologize in advance if you feel I’ve failed to do that!  So read on, at your own peril…

Years ago we were making a hi tech display that was really fantastic and had a large market share for a few specific applications.  We wanted to take it into new markets, but to do that we felt like we needed to fix (or at least improve) one of its performance limitations, which was not a problem in the current markets but would deter its adoption in the markets we were targeting.  Specifically, the display could not show the image more than 50% of the time or else that image would become persistent, meaning it would “stick” on the display.  Then, when the image changed to a new one, there would be a ghost of the old image still present. In the current market it was OK to turn the illumination off for 50% of the time, and so during that “dark” time would have the display “clean” itself so there would be no image sticking.  We refer to this as “duty cycle”, and so our display had only a 50% duty cycle.  In the new target markets, however, we needed to leave the lights on all the time, so this trick would not work.  So, we set up a program to try to improve this duty cycle, ideally to 100%.

I was not directly involved with the project, but we were not a huge company and I had been there many years, so I knew and directly interacted with most of the project members on a daily basis.  After about 6 months of hearing about no progress being made, I went to the program manager to talk to him about it.  As the discussion ensued, I could not seem to clearly understand the scope of the program, and so, as I always do, I tried to bring the conversation back to simple first principles.  I asked what we were trying to solve, and I was told “duty cycle”.  I said that actually, we could run with 100% duty cycle right away if we wanted, so that didn’t seem to me to be a problem we needed to solve.  The program manager said we could not do that, as then we would have image sticking.  I said “Aha!  Then the problem we are trying to solve is image sticking.”  I was told this was just semantics, but I disagreed.  I explained that with anything you are trying to improve, you need to know 2 things right at the start:  where am I now, and where do I need to get to.  So I asked, with this problem, had we defined (quantitatively, by whatever metrics we chose as appropriate) where we were now and where we needed to be with regard to image sticking?  The answer to both, sadly, was no.  However, since we were already over 6 months into the program, my input was too late to be implemented, and so the program continued along its same track.  Predictably, it failed utterly, and the new markets were never entered.

I have no idea if that problem was one we could have solved, but I do know we never defined the start and end points of the journey (in fact, we even mistakenly got on the wrong path entirely).  Thinking about it like that, I’m sure you’ll agree our odds of success were very, very low.  The Hitchhiker’s Guide to the Galaxy made this famous when they discovered the answer (42, as I’m sure you already know) was meaningless without knowing the question.  If you have experience with something similar, please let me know in the comments, as well as how it worked out.  I will write more in future posts about what to do if you find yourself in this situation.

Speak Your Mind