Problems are Gold, Ideas are meh!

“Hey, I've got this killer idea, can we meet to go over the details?”

As a product owner, I get this a lot. People love thinking about problems and coming up with ideas and solutions. I can’t fault them, it’s what I do all day as well! However, as the person tasked with ensuring the successful implementation of the company’s projects, working only off of ideas proves to be really tough. I believe this is due to a fundamental misunderstanding between those who are closely connected to the customer and their problems and the teams that ultimately solve those problems.

“I thought about it a lot and we can kill two birds with one stone if we do it!”

Whether conscious or not, coming up with an idea is a process that starts with working through the details of a given problem. The more familiar you are with the “problem space”, the faster this process is. As your awareness of the details grows, you naturally start making connections you never made before (“If only I had this <piece of data> available <here>, I could trigger <result>!”). It’s these connections that you make that ultimately lead to “Eureka!”.

…and this is where the trouble starts. By the time you’re presenting your idea to others, you have already gone through this important process. The people you’re presenting to, though, haven’t. If they happen to have the same familiarity with the problem space that you do, then they will likely be able to catch on quick, but usually that is not the case.

“I’m really excited about it. I think it’s going to be great!”

People also, naturally, get very attached to their ideas. These are inexorably tied to their sense of self-worth. This produces two results:

• the conversation inevitably turns personal. Turning the idea around — even if you’re only doing it to get a better understanding of all the details— can easily feel like an attack to the person who came up with it.
• the conversation inevitably becomes defensive. That’s the only position that the person who came up with the idea can take. The natural reaction to any concern that is voiced against the idea is to defend it.

At that point, the idea is no longer a lump of clay, ready to be molded into something of worth. It’s just the rope in a tug of war that can only end with half the team falling hard and everyone getting muddy.

“Wait, what is this? This is not what I asked for!”

As product owner, even if I already had an idea of how to solve a given problem, I always start by talking to my team about the problem’s details. This allows everyone to understand the importance of fixing it. It allows them to ask clarifying questions that can expose misconceptions or details others haven’t seen before. Ultimately, it gives everyone the chance to apply their own professional expertise to the problem solving process. This either validates the original idea, or produces a far superior one.

This is the source of most conflicts though. If we only have an idea to work with, then both my team and I will be forced to make a few assumptions about the original problem. Our understanding though will be subjective and our perspective limited, so chances are some of these assumptions will be wrong. Others will be correct, but they will be things that the person who suggested the original idea hadn't considered. Thus, when we present our initial implementation, the morphed solution will likely be far from what they had envisioned, leading to anger and disappointment.

Hey, I've been thinking about this problem a lot, and I’d like to show you the details of what’s going on. I also have a few ideas about how to fix it but before we move forward let’s gather the team and make sure we all understand it.

What if we took a step back from any idea, and first tried to understand what problem it was trying to solve in the first place? This has tremendous advantages both for the team tasked with solving the problem and for the person or team bringing it up.

At the highest level, making a decision about whether to proceed with solving a problem is far easier than whether to proceed with implementing an idea. Most of the time you can quantify the effect of solving the problem, while predicting the result of an idea is hard. Besides, an idea comes with the extra weight of: “is this the best solution we have, or should we keep looking?” — which tends to be an impossible question.

When the discussion around the problem’s details begins, the main focus should be on making sure that all the relevant aspects are covered, and that everyone understands them equally before any solution is even considered. In a way, your idea about fixing a problem can be seen as the winning hand that you want to keep close to your chest until everyone else is primed to grasp its brilliance.

Finally, if everyone is focused on solving the problem, having an idea fail is no disaster. It’s just part of the journey. Everyone can go back to the drawing board and cook up a new idea. On the other hand, if the focus is the idea itself, then failure is much harder to stomach and can leave people feeling frustrated and without direction.

So, if you work with software product teams and you’re considering submitting a feature request, try to separate yourself from the idea, and instead ask: what problem is the feature trying to solve? What are the most relevant details you can share with the team? Are there any concrete examples of the problem you can give them? Is there any data that can indicate the size or reach of the problem (even if you don’t have it)?

I guarantee they will appreciate it.