Product management can be a frustratingly broad field. There are a seemingly endless number of mental "muscles" to train at any given time. From strategy to research to prioritization to execution. Any one of those could be a full semester at a university, and you still would have lots to learn. There's a blog post to be written for each, but in this post I'll focus on a specific part of the role that has given me trouble over the last 1.5 years: shaping ambiguous projects.

Defining Ambiguous

Not all PM work is tough. There's always the easy stuff. Customer X says “Hey, buddy, we're going to churn if we don’t get Feature Y” and sometimes the aforementioned feature is straightforward. There's not a lot of wiggle room in terms of what the thing will look like, it's well-contained, and it fits well within the overall product strategy. Define the thing and ship it. Full speed ahead.

But not all projects fit this mold. Some projects have a greater degree of variance in how you might achieve the desired result. The best initial approach isn't obvious, and when something does come to mind, it doesn't exactly inspire confidence. In my current gig at Metabase, this is around 25% of the projects that I work on. There's plenty of low-hanging fruit out there still, but often the most valuable stuff comes with ambiguity. It's not the micro design decisions that make these projects tough. It's the fundamental decision points that will define the project and set you down a certain path if continued.

The Journey

You can start shaping these ambiguous projects like you would any other, but eventually you hit a point where your internal monologue goes "I don't know what we should do to solve this," and that's where things get interesting.

Most recently, I was tasked with figuring out how to provide companies with a way to curate and and display the most important dashboards, charts, external links, etc. on their homepage. Sounds simple enough. But when you get into it, there are a dozen ways to tackle the problem, and each of them sets us down an explicit path. Should we provide a sandbox-like experience? Should we do something more structured and simple with links alone? Should we do the "dumbest thing" and just provide a Markdown box? Or should we try to be more prescriptive and help customers build out their homepage with a wizard-like experience? I walked through the implications of each of these options and mapped them to customer use cases, but I still didn't know.

When you hit this point, at least personally, my default state is paralysis. I’m a very analytical person by nature. I like working alone. So sometimes I struggle to lean on others. My instincts say to take this problem, go into a deep, dark cave for several days to weeks, and deconstruct it until I’m happy with a decision.

Practically, this often doesn’t lead to the best outcome because in truly ambiguous projects, there is rarely a piece of the puzzle just waiting to be picked up and make the choice for you. It can be incredibly hard to reason through these questions alone. And we're about making things easier. So here's the playbook that I've been using lately.

A Playbook

🧭 Map out the territory

Start out in analysis mode. Break down the problem you are trying to solve and segment it into sub-problems if it makes sense. Then map out the possible solution space. What are all the ways you could address this problem? Decompose each one. Think about the pros and cons of each. Think about the open questions that come with each. Make sure you write it down. You may still not have an answer, and that's perfectly okay, but you should have a clearer idea of the territory that you are working with, and the ability to better communicate that territory with others.

🤝 Lean on internal partners

Ask others for help! You don’t have to figure it all out on your own. Pull in engineers and designers with different viewpoints to help you reason through the problem, solution space, and outstanding open questions. Through these conversations, you should be able to resolve some open questions and narrow in on a smaller set of viable solutions. Take notes and feed any adjustments back into your mental model. Think through things, and make a call. It may not be the right one, and that's okay. Which brings us to the next point...

🔄 Try it out and iterate

The problem isn't "solved" when you come to a decision. You'll have to try it out to achieve a significant degree of confidence. Keep implementation cheap and structure the project in a way that you don't expend too many resources. Go with a prototype, or break out a slice of the project that can give you enough clarity. Once that is ready to play with, go back into analysis mode. Revisit the initial problem and open questions.

Is it solving the core problem that you set out to solve in the first place? Or have you gotten too in the weeds trying to solve specific open questions? Are things coherent? Is your story about how this works clear enough? Reassess. Then iterate some more. And do it over and over again. Until you have something you’re mildly proud of. It's not clean, and it's not perfect, but this is what I've found to work.

Thanks for reading! If you enjoyed this post, you can subscribe to get future ones like it delivered straight to your inbox. If Twitter is more your speed, you can follow me there as well.