Fall in love with the problem, not the solution

Focus on addressing customer issues rather than being attached to your idea of a solution.

Written by Den Delimarsky

You talk to customers, you collect data, you got buy-in from your internal stakeholders. You lined everything up for a successful feature launch. And then you run an experiment, and the reality showed you that the implementation that you expected to be the winning one is actually not what moves the needle for the larger product. Now you have a dilemma - you have the option to launch as is (after all, you did the due diligence - maybe the experiment timing was bad and in the real world, people will love what you did) or go back to the drawing board.

You spent weeks in meetings, meeting with a group of peers over and over again, where you talk to engineering managers, PMs and partner teams. Every time you have a meeting, you are coming in trying to sell others on your solution - you present PowerPoint slides, you send over whitepapers with all the technical details. You did your due diligence (again), and you just want the feature to be implemented the way you outlined it. Every single meeting that goes on, you get feedback, but you still don’t get full buy-in, so you schedule another meeting, and propose the same solution (again).

Notice the trend? In both cases, you are running the risk that good PMs ultimately learn to avoid - you fall in love with the solution, instead of focusing on the problem. This trap is surprisingly common. I was a PM like this as well when I was starting up - I was always trying to push for a solution. I’ve heard this often - “You get paid to have an opinion”, and to me that sounded like I get paid to come up with an answer to everything. I wanted to be right. It took me a couple of tries to understand that I am actually paid to figure out which of the ideas solve the problem in the best way possible (rather than be dead-set on a specific approach that one came up with).

So what do you do to counter this pitfall?

  1. Be prepared to be wrong. Going into any meeting with stakeholders, and writing any spec - assume that there are “unknown unknowns” that will change the course of action you need to take on a feature. That doesn’t mean that you need to come up with a half-baked solution, but rather focus on addressing the core problem instead of zeroing in on one specific answer to it.
  2. Assess the situation often. As you work on coming up with various proposals, make sure that you have the most accurate information at hand for that time. You don’t need to re-think the proposal over and over again just because you want to come up with the best option to move forward (you don’t want to fall into another trap - decision paralysis), but you do want to be confident that you are operating with the right information at the time of the decision.
  3. Experiment often. The easiest way to validate your hypotheses around the feature or product you are building is through experimentation. Once you start shipping experiments before you start shipping features, you will dramatically increase the velocity at which you can ship the right solutions and learn what your customers truly want.
  4. Don’t rely on just your ideas. Incorporate feedback and try to collect the best ideas instead of trying to come up with your own. You work with people who are just as smart, and in most cases - smarter - than you.
  5. Be grounded in data. I personally really like numbers - they speak volumes about things that other markers rarely will. When you have data, bad solutions become really obvious.

All this being said, when you are really passionate about a problem, you also must understand that there is probably more than one solution that you can apply to solve it - it all just becomes a function of your ability to detach yourself from one idea and focus instead on truly improving the situation for your customers. This might not be as easy as it seems, as it often will seem like one never knows the right path - but that’s OK. Because the same customer scenario that is addressed in one way today might need to be addressed differently tomorrow - you will be back at the drawing board before you know it, working on an even better solution.