I've been thinking about problem solving recently. I've gotten feedback a few times now from colleagues about how I'm particularly skilled at reasoning clearly about problems and breaking them down into workable plan. I worked really hard to get better at identifying product problems and leading people to solve them so I'm writing this essay to better internalize how this happened for myself (but who knows--it might be more useful to others than I think).
When I first joined Stripe, I was amazed at how 'smart' everyone was. They talked differently, precisely, and seemed to 'get it'. Then I started to read a lot of other people's writing and it was way beyond what I had ever seen in internal communications. Docs were clearly written with a lot of obvious care, but it also seemed to come so naturally like it wasn't a great effort at all.
How does this relate to thinking about important product problems and how to solve them?
Writing clearly is thinking clearly. All of the good parts of the docs I've read require a thorough understanding of the problem because it's very obvious while writing when you don't fully have your head around it. Statements that are assumptions stand out clear as day and the weak parts of the argument are apparent. You can have an internal monologue that provides feedback and makes your reasoning better.
I also think having better structure when describing problems helps. SCQA (situation, complication, question, answer) from Barbara Minto's Pyramid Principle is so simple, but effective. As a framework to hang your thoughts on, it reliably produces good writing and, consequently, good thinking.
Making space for describing the current situation with indisputable facts ensures that everyone has a shared understanding. There are many ideas that never make it off of my computer because it turns out my understanding of a situation was not correct. Above all, I find I need to be mindful that I am not fooling myself so objectivity and a healthy dose of skepticism is needed.
More time spent interpreting the situation leads to better problem identification. Often times I see people imagine a problem statement to fit their solution rather than deriving the problem statement from their interpretation of what they are seeing. The complication (the 'C' in SCQA) should naturally follow the situation. You can sniff out poor reasoning between how you describe the situation and what you interpret a the problem when it feels like a big leap between the two.
Turning over the problem in your head leads to new ways of thinking about it. Is it really a problem worth solving? What else does the problem reveal? Is there more to it--a symptom to a deeper problem? I have gotten much better at holding on to that moment of ambiguity longer until I feel it's a valuable problem to solve, it's tractable, and it's the right time (Richard Hamming articulates this well in You and Your Research).
I find picking the right approach and solution to a problem to be an iterative loop. Sometimes a good point solution becomes apparent, but doesn't fully address the problem. Sometimes I realize there isn't a good approach at all and I can solve a different, easier problem, that gets at the same thing. I try to be aware of when I am prematurely committing to a solution or approach. If it seems like there is only one solution, I probably haven't thought about this enough.
Finally, I learned that persistence and conviction is required to have a real impact. In previous leadership courses, I learned that meaningful change is often resisted and painful for people. It's not a bad heuristic to use 'how uncomfortable is this making the team/organization?' when determining if a particular problem and approach will cause change. While change doesn't always result in positive outcomes, if there is no change then there's little chance you are making progress. A useful mantra I repeat is 'if we are happy with the current result we should keep doing the same thing every day, otherwise we change is required'.