Solving the Right problem

We were working on a warehouse automation solution. The main requirement was Asset tracking. The solution proposed was an integrated RFID tagging with automation applications. The solution seemed to be acceptable to the middle level management in the customer company, but when we took it to their leadership, it was shot down.

Eh?

We ended up concluding that their leadership was very “myopic in vision” and that they didn’t understand or empathize with “people close to the actual problem” (in this case, the middle level management) etc etc.

It wasn’t a fault of the solution per se. It wasn’t bloated, very specific to the requirement. And I don’t think we were charging them too much. I was one of the disappointed folks, as I had worked on VoC, features and prototype development (and a whole lot of awesomely colored ppts).

It wasn’t until I had a discussion with one of my peers in the company that I realized where could this have gone wrong. He spoke about companies trying to build products to “solve the wrong problem”. He quoted an example – A product was built to monitor the health of equipments on the field. Using the product, a maintenance worker could remotely check the equipment health and once a defined threshold was crossed, he created a workflow to address it. This enabled preventive maintenance on the equipment which used to frequently break down. The product had a few successful pilots and was launched. And it didn’t sell as well as expected!

My colleague explained that the actual problem for the company was to improve the health of the equipment. The need to monitor its health came out due to faulty equipment manufacturing. What happened was the particular equipment manufacturers adopted some standards which reduced the maintenance effort by a large margin. These reduced the need to remote monitor the equipment or invest in newer systems or train people in new ways etc. Which meant, the product was no longer relevant!!

I could see a parallel with the RFID automation solution we had proposed. The main problem for leadership was an inefficient workforce which was not keeping track of their inventory properly. They had 6 – 10 people who, with appropriate bookkeeping could do the asset tracking with a basic VB application. The middle management, instead of focusing on process streamlining was bent on supporting the existing methodology by adding a layer of new systems over it. Guess what happens if the system was implemented. Not only would it have added extra overhead to their existing IT infrastructure, but it would have reinforced the inefficient practices of the workforce.

My takeaway was this:

  1. When trying to think of a new product, don’t think of the problems we are trying to solve. Think also about the situation that is leading to the problem.
  2. Once the situations have been identified, think on how difficult is it for the situation to change? If a situation can be changed by a simple technological breakthrough, the problem can entirely vanish away or be reduced to a negligible expense on the income statement, which implies our product is not that relevant anymore.
  3. If a situation has been identified to continue to linger for a long time to come, there are larger opportunities that can be addressed rather than building a small pointed solution.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s