Fall in love with the problem

Time and again, the question arises — how do I solve this problem? Pause. Before knowing whether the solution is worth pursuing, you want to answer whether the problem is worth solving. For this level of introspection to happen, a product manager has to delve into all the angles of the problem. So, catch yourself on an ongoing basis when you're jumping into the mode of "this is how we're going to build it."

Distinguishing the problem space from the solution one helps your internal mental model how much time to spend and how deep to go into a topic. Time Herbig has a nice depiction that's useful in this context. Is it an alignment or research vs. ideation, creation, validation, and refinement?

I love this Reddit post which talks about Product learning in general. The first point is Always separate the problem from the solution:

- It's natural for us to jump to how to solve something before understanding that "something" really well. It may work for evolutionary survival but not so much for product management. Most users, clients, stakeholders, developers and even product managers often fall into this trap. It will happen on all levels - from discussing a startup idea to a portfolio strategy and even at a small feature level.

- Assumptions are the cancer of product management. It's really hard to avoid them because our brains are hard-wired to do so. Question everything and get hold of the data when you can.

- Talk to your customers and end-users. Talk to everyone involved in the subject you're researching. If you're not talking to your customers / end-users very often something's definitely wrong. It may be very tricky to do so in your particular situation but try to figure it out. Bonus: your life will probably become a lot more interesting.

- Ask "dumb" and obvious questions, all the time. Don't stop asking until you know enough so that you can explain it back to a 10 year old kid. This is important for all phases and not just research.

- Write things down - or better yet - draw them. It's much harder to bullshit yourself when things exist outside of your head.

- For solution - define the desired outcome ahead and decide on how you will measure it (then measure it). This is SO MUCH harder IRL than you'd think. "Outcomes over features/solutions" is luckily a pretty big theme in PM these days so I decided not to expand it here. Study this if you're not already familiar to it.

- One thing you can do today: pick something you're working on, small or large, and break it down (write or draw!) into defining the problem from the user's perspective (why is this making their task harder, e.g. need to look at two reports to make a decision) and what the outcome (not solution!) would look like (e.g. being notified with all these required data pieces at the time when I need to make the decision). Only once you're happy with this start thinking about the actual solution (e.g. new report generated in the BI portal).