Building Products in Ambiguity

As Sonia Kedzierski, Director of Product Management at Etsy, shares in her presentation, the only certainty in product management is the presence of uncertainty. It’s not the job of a PM to have all the answers. It’s their job to act even when all of the answers aren’t available and to understand how to get them. You can watch Sonia’s full presentation above. Otherwise, you can catch the highlights below.

On ambiguity in building products

The straightforward products built with complete certainty and all of the answers are few and far between.

“I really wanted to talk about ambiguity because I’ve always felt like it’s kind of the dirty little word in product. Because your job, quite literally is to know you’re supposed to be this all-knowing, ever-seeing creature who has a full grasp on past, present, and future. At any given point in time, you’re supposed to have a really clear point of view on what are the biggest opportunities, what is the customer need, how you’re going to meet those needs, and how that’s going to change over time. 

Here’s the truth about product management: most of the time, it’s totally vague, really unclear, or just totally unknown. And when I talk about ambiguous situations in products, what I’m really referring to is a situation where the causal relationship is unclear, no precedent exists, or the team is facing unknown unknowns.”

On why it’s important to learn how to build products in ambiguity

Our human instincts might actually hinder the pursuit of building great products.

“Humans really hate uncertainty. Our brains are wired that way and uncertainty brewing leads to anxiety. And I think this is really amplified for product managers, because we really, really hate not knowing. We despise not having the answers. We levy that anxiety with this need for closure. It’s ultimately that need for closure that hurts our ability to explore bolder solutions and build better products.” 

The first step for building products in ambiguity is acknowledging it

It’s helpful to be clear and transparent with your team when you don’t have all the answers.

“Be upfront about what you know, but also what you don’t know. Of course, you want to give your team all the facts, reassure them, make sure that there’s a shared understanding. However, focusing on what you don’t know can actually be a really powerful tool for your team. 

Call it like it is. I mean, this literally. If it’s going to be a roller-coaster, use that language. This starts to mentally prepare your team for the twists, turns, potential queasiness, and maybe some thrills ahead. Be empathetic. Empathy is really key when you’re communicating change and uncertainty.”

Set the direction for your product team

“Set the direction. Remember, your job is not to come up with the best solution, your job is to identify the best way forward. So set some guardrails. You want to really define the problem space, the opportunity, and the challenge. You can’t lead your team to success if you don’t have a super good grasp on that. 

Focus on customer outcomes and not features. Once you know what the issue or opportunity is, I think it’s a great idea to frame it as one sentence from the customer’s point of view and make that your team mantra.”

Defining success makes things less ambiguous

Great product managers know that it’s important to know what you’re trying to do when building products in ambiguity, but it’s also necessary to know what you’re not trying to do.

“Deconstructing success and making it really measurable is helpful. The tricky part about ambiguous situations is that it makes the unknown future a really, really scary place. So, if you can paint the picture of what success looks and feels like you can bring your team along on that journey. They can start to visualize a positive future state. 

It’ll alleviate some of the short-term anxiety. And outline non-goals. This is actually a really favorite exercise of mine. You may think that the goals you outlined in your doc are super crystal clear. But it’s not until you define what the non-goals are and what you’re not trying to do that really starts to create the parameters for your team so they understand where can they explore and when and where can they build.”