Bring me solutions, not problems

Every now and then I will come across a post, encounter an image or product and sit back and go hmmm...

I know I am not alone in this, you do it too, I am sure.

A post I read earlier today talked about the rantings and ravings of managers who, out of frustration, might say something like "bring me solutions, not [more] problems" - to me the use of that credo is a knee-jerk reaction to the frustration of being bored down upon. Often by many competing priorities, and feeling there is no easy way to get out of all the pressure. It is also, perhaps, a glaring sign and red flag about leadership immaturity.

The most recent high-profile use of this that I am aware of was that this was one of the statements made by Billy McFarland, the disgraced entrepreneur behind the notorious Fyre Festival when presented with the latest in a long list of logistics and financing problems at the ill-fated event - there is a good documentary of this on Netflix - FYRE: The Greatest Party That Never Happened - if you are at all interested.

In the product management arena, it is easy to fall into the "solutions-oriented" trap. It is something that we'll use in a resume, a cover letter or as part of a job description but is it really the right thing to say, and what is it really saying? Solving problems, of all shapes and sizes, is satisfying after all. When you arrive at the solution or a solution that works, you have a feeling of accomplishment, a rush of endorphins. If you learned about the Archimedes "Eureka moment" in his bath-tub, you can imagine him jumping out of the tub and running excitedly to the treasury of the king barely clothed! Well that's as my sixth grade teacher described it at least.

We also know that we like to solve things because puzzles are incredibly popular, worldwide and they have provided entertainment for millennia. The love of a challenge. What we did as problem-solving before "civilization" was, of course, all in pursuit of innovative ways to ensure survival but it is something we have retained and it is a behaviour that has continued to serve us well, we do it for the euphoria.

Ok, so returning to the product manager role, there's the challenge amongst product managers to "solutioneer" as soon as a problem is spotted.

This might be, formulating a workaround, conjuring up a piece of scrappy code, doing a mockup or making a model, you could even argue that doing a prototype or experiment is solution building and I would say you aren't wrong.

If you look at many of the great product innovations, they were formulated through various kinds of partnerships.

John Logie Baird, a television pioneer, setup the Baird Television Development Company and worked with collaborators in Britain, Germany and France, including the BBC, the German post office and Télévision-Baird-Natan. As a result, his system was used for the first public television broadcasts.

Though Alexander Graham Bell is known for the telephone, he had broad interests and only 18 patents were granted in his name alone a further 12 he shared with collaborators.

Inventor Thomas Edison collaborated with Henry Ford and Harvey Firestone as well as others on several initiatives.

I would say though, that we all have to play to our strengths in what Martin Eriksson terms the team sport of product management and that means that while solution ideas are great, what's really needed on the product management side is a deep and elaborate understanding of the problem, the problem space, the impact and the cost of leaving the problem unsolved; only through understanding the problem can we really work toward finding the best possible solution. That's better than simply "a solution".

This leads me to conclude that when we say "solution-oriented" we're not saying we have the solution or we will provide the solution, what it is instead saying, is that we are committed to exploring all the facets of the problem(s) and drive toward resolving them by whatever means is appropriate or necessary. That means leaning on researchers, architects, designers and developers if it is a software product.

Frances Frei, an associate professor in the?Technology and Operations Management Unit?at?Harvard Business School states it well, as described by Christina Bielaszka-DuVernay in HBR , when saying: "Identifying problems can be a solo sport, but finding solutions rarely is" and rightly, it shouldn't be something you should consider as something you have to do alone.

In software development at least, mature organizations have many different characters playing different roles, some of them wearing multiple hats, but it is only through close collaboration and leveraging the strengths of one another that truly great ideas become great solutions and products.

As product managers, we need to have that mixture of inputs from multiple contributors. If you choose not to do this, then you leave the door wide open for someone else to come up with something even better and probably sooner rather than later. Or worse, you find that two or more of you are working on the same problem but in isolation.

You might say that our personal capabilities actually define our disabilities, an openness and willingness to collaborate has to ultimately be regarded as a strength.

#productmanagement #productmanager #product