This is the third post in my Starting Products series. You can read the first post here.
Product managers live in ambiguity: which initiative will move the needle towards a success metric the most? What should you de-prioritize? Should you bet on a risky, unproven, but potentially huge technology or stay with a safer but less rewarding one? Ambiguity is such a part of life that a common PM interview question is “how do you make decisions in ambiguous situations?” But most PMs don’t appreciate how unambiguous their situation actually is — they have customers, whether they’re working on a shipping product or a new initiative at a company with existing customers. Having customers gives you data — you have customers you can talk to, you have customers you can A/B test ideas with, and you have usage data.
Early stage startups are a whole different level of ambiguity. You don’t have a product or customers, only a vision the company was founded on and people’s opinions. But you’re expected to make good product decisions. Ambiguity comes when you’re trying to determine what features to prioritize, tradeoffs to make, and philosophical stances (like privacy policies) to take while building. This is what I’ve learned building technology products from scratch at places like Magic Leap building AR, Lytro building computational cameras, and many other startups: identify the knowns, define what drives decisions, prototype anything possible, and write a story.
Identify the Knowns
I’ve never seen a situation that’s 100% blue sky ambiguous in an early-stage startup where you’re starting from first principles. Even though you’re pre-product, there are a set of fixed knowns. Identifying these known elements will help frame every other step. And it’s mentally reassuring to start with what you know, before dealing with what you don’t.
So what’s known? At the very least, your company has a product vision. You’re using a technology to do something. Great — the technology and pain point are known. (Whether the technology is right for the pain point is a different discussion: generally, you have to take this for an unchangeable given.)
You have a very rough idea of who your customer is. What are they doing now around this pain point? If you look more broadly, do they have a behavioral precedent for aspects of your product? E.g., if your product is a subscription product, what other subscriptions does the customer have? How does your target price compare to other things they buy? If you’re making a B2B product, what’s the sales process like for this type of product? Who is the decision maker to buy? If you don’t know that much, go find out because otherwise, you won’t be able to make informed decisions.
As you start assembling a list of these known elements, you’ll find your overall situation is less ambiguous than it might seem. Next, how do you use these knowns?
Define What Drives Decisions
One of the poorest decision-making techniques I’ve seen is when a founder told me that we have to do something, so we’re just going to do what he wants. It wasn’t a pleasant place to work. All too often, decision-making in startups is dominated by subjective opinions. Defining an objective-as-possible set of criteria and principles to guide your decision making helps create clarity towards achieving that goal.
Once you define your decision-making criteria, you’ll find you’ve disambiguated some situations enough that you can make good decisions with just a short meeting. Create a table to look at the pros and cons of the decision relative to each of these criteria. Sometimes, you can be more analytical and assign scores to each category — or at least relative high/medium/low scores — which lets you make reasonable decisions. Be sure that you weight impact to customers appropriately, though, because otherwise high-impact and high-effort things might never happen.
The criteria and principles that guide decisions at early-stage startups fall into three categories: customer satisfaction, product vision, and reality.
Unlike later-stage companies that focus on metrics like engagement, growth, and revenue, the only metric that will matter when you first ship is if your customers like your product, often measured by Net Promoter Score (do people recommend your product). As such, how a decision impacts customer satisfaction is the first criteria.
When considering a feature or making a tradeoff, ask if X will make the product more useful or delightful to a customer in a meaningful way? Will X reduce the complexity a user faces when using the product? What will be the time and cost impact of X and how will those affect customer satisfaction? If a feature is slightly delightful but doubles the cost, is it worth it to a customer? As a product manager representing the voice of the customer, assessing whatever decision through this criteria will dominate your thinking.
At Magic Leap, as we worked on an augmented reality system, we knew that asking customers to put on a headset was a barrier to entry. On the product team, we focused on prioritizing decisions that would showcase the benefits of spatial computing/mixed reality to a user. We strove to make product decisions that resulted in the value of what you could do with the headset outweighing the tradeoffs to using the system — and looking for opportunities to reduce those tradeoffs — and we’d use that criteria to prioritize everything from what apps to build to what features the apps should have to tradeoffs in what to build when resources got tight. Of course the company didn’t always follow those recommendations, but our decision-making criteria was focused on customer satisfaction.
The second assessment criteria is the uncompromising product principles in the product vision that will drive decisions. For example, I wrote an early iPhone app called FlipBook, that let you animate with your fingertips. One of my driving principles was that you should be able to draw anywhere on the screen. Since the iPhone removed a fixed keyboard, it let UIs adapt to the task, and it made sense you’d want to draw on the whole screen. The default API didn’t let you hide certain UI elements, and I chose to implement an identical version from scratch that could be hidden because I wasn’t willing to compromise on that product principle. And why was this a core, uncompromising part of the vision? Because I believed it’d make for a better experience for customers.
Finally, the reality of needing to ship within a certain time/budget and with a constrained scope is the third assessment category to look at. You can’t push for everything. What are the tradeoffs you can make that matter less for the overall customer experience and aren’t part of the product principles, which will let you spend more time/effort on the things that matter? Remember, no product — especially no v1 — is ever perfect.
Here’s an example of how I used assessment criteria to make a quick decision with imperfect information. Charging was briefly a hot topic for a product I worked on. We thought we could build a wireless charging base in a cost-effective way, but in a prototype build, we found it didn’t work. We were left to choose between building a more complex base or using a wired charger. From a customer satisfaction perspective, I wanted the wireless charger because I knew it was easiest to use and would encourage the always-on usage we wanted, would be an easy accessory to sell, and would enhance our premium positioning (it was an expensive product). However, the time and potential bill-of-materials price impact of building our own wireless charger was too high with the schedule and target price we wanted, and it wasn’t worth delaying the schedule and increasing the cost because wireless charging wasn’t critical to the product vision or experience. We chose to use a wired charger, and while not ideal, it was fine.
Even with a solid decision-making framework, there are times when talking something over will still just result in conflicting opinions where the loudest (or most important) voice gets their way. In that case, you have two more tools available to help make better decisions, with the first being prototyping.
Prototype Anything Possible
Especially for decisions that will be hard to change, the best thing you can do to make an informed decision is push for the time to mockup a prototype as fast as possible and give it a try. Finding ways to de-risk options removes ambiguity, and building anything representative de-risks an option by moving it from abstract to real.
These prototypes don’t have to be complex. You could make a wizard-of-oz one where you give the appearance that something’s automated and working but you’re manually processing to make it work. Or you could use a proxy to prototype — we used VR a lot to prototype AR ideas at Magic Leap while we were developing our system. We were trying to figure out what AR apps could be like before we had the software to make them — to say nothing of the hardware — so teams frequently used existing VR platforms with a model of a living room to quickly explore what the AR app could be like. Similarly, I’ve made intentionally-sketchy but tappable mockups of what apps could be like in UI prototyping tools like Balsamiq so that rather than trying to describe the app, I had something I could hand people and that we could point to and discuss: I made the mockups sketchy so that people focused on the concept and not the design execution.
Fast prototypes disambiguate decisions because they’ve made things real. But sometimes you can’t make a prototype, and in that case, we come to our final tool to help deal with ambiguity, storytelling.
Tell a Story
Storytelling is a PM’s most powerful tool for turning ambiguity into clarity for three reasons:
- A story gives context to how your product will fit into a customer’s life.
- A story provides a glimpse of a world you could be living in as a result of a specific decision and people can choose if they want to live in that world or not.
- A story addresses the emotional impact of your decision in a way a pro/con table or prototype can’t.
Even if objective criteria shows a clear path or even if a prototype reveals compelling information, I’ve seen many situations where a well-written story about how someone uses your product — a user narrative — can completely sway a decision, for good or bad, because our brains are wired for storytelling, not analysis tables. Unfortunately this means the storyteller can manipulate the story to promote their perspective. For that reason, if you’re using story to make a decision, it can be useful to write two stories, one where you go one way and the other where you do the opposite.
There are multiple books and articles written about how to tell a good story, so we won’t go into details here. But I want to share a few things I’ve found you must do when using a story to bring clarity to an ambiguous situation.
Write Honestly
Writing honestly, even if it hurts, is the most important tip I can give you. It’s easy to drink the kool-aid and forget about all the asks your product makes of a customer. Make sure you step back and include not just the good but also the bad/weak about your product. Including the weak parts also provides insight into what you might need to work more on before customers will adopt your product.
I worked with a PM who ended all his user narratives with “and then the person tells all their friends about our product and we all become millionaires.” It’s a happy ending, but having that mental framing caused him to never write honest stories that called out the friction a customer faced using our product with the decisions we’d made. Not being honest caused him to miss user pain points that we could’ve addressed had we started working on them earlier.
Write Empathetically
In order to write useful, honest stories, you also must be empathetic to what a customer’s life is like, what they’re feeling, what they get frustrated with vs what they tolerate, and more. You must get into your customer’s head to write user narratives that help you fully assess how a product fits into a customer’s life. Let me give you a fictional example. We’ll write it multiple ways to see which feels more empathetic and authentic so that you can see how empathy makes the narrative more useful.
Imagine if you were the first PM at Lyft before it launched, tasked with figuring out the MVP. How much effort should you put on trust and safety? I’m sure different stakeholders had different opinions — we likely wouldn’t decide this in a meeting nor is this easy to prototype. Let’s write a story to help make a decision:
Sally pulls out her iPhone, opens the Lyft app, and it uses GPS to immediately find where she’s at. She enters where she wants to go, taps to confirm and pay, and a few minutes later, a friendly Lyft driver shows up and takes her there.
I really doubt that’s what was going through Sally’s head back when Lyft was brand-new and we weren’t used to ride sharing. Everything is rosy. Let’s be more empathetic to what Sally’s likely thinking, creating a more honest story based on a world where we don’t spend much time on trust and safety features:
Sally pulls out her iPhone, opens the Lyft app, and it uses GPS to immediately find where she’s at. She enters where she wants to go, taps to confirm and pay, and a few minutes later, a stranger shows up at Sally’s location. Sally gets in the stranger’s car and prays she won’t be murdered before reaching her destination.
Well that’s scary! But it’s far more authentic than the first version. Empathizing with Sally and using emotionally-charged phrases tells a very different experience story. Now let’s write a version where we spent a lot of time on trust and safety features:
Sally pulls out her iPhone, opens the Lyft app, and it uses GPS to immediately find where she’s at. She enters where she wants to go, taps to confirm and pay, and a few minutes later, a background-checked-and-safety-verified driver with a 5-star rating shows up at Sally’s location. Sally gets in the stranger’s car, nervous for her first Lyft ride, but has a pleasant and safe ride to her destination.
I think we’d all agree that’s the story we want to tell!
Write Futuristically
You have to be aware of industry and customer trends in order to write a good story. Your product isn’t launching tomorrow. What do you believe is going to be happening when it does launch? How will those changes impact what customers do and how they feel?
One time, I was part of a discussion where we were determining our privacy and data policy: did we want to be more like Apple or Amazon? Legally, we’d have consent to record audio and video of our customers, and that data would be very valuable. I firmly believed we needed a stance more like Apple’s where we view privacy as a human right because customer trust was critical to our product’s success. But I knew that if we did an objective list looking at the value of the data vs. the risks, the true impact if we we were hacked wouldn’t be clear. As the voice of the customer, I needed a better way to make that risk clear.
So I wrote a story, using a Black Mirror-like approach. I wrote about a near-future world where we chose an Amazon-like approach, capturing and retaining a lot of data. We did everything legally and followed best practices, we were successfully leveraging the data to make the product better for customers, but then we were hacked. And one believable thing led to another, and finally customers stopped using our product because of customer fear and we went out of business.
This story was powerful because it was fully believable. It also was optimistic at first, setting up a world where we were successful and showing that yes, having this data does provide value, creating a world that the stakeholders wanted to exist. But it was authentic and had something quite plausible go wrong. Using a story rather than an analysis table made the risk we’d be exposing ourselves to with that data policy very clear and very personal, and it made a difficult decision clear.
Sometimes writing a story can feel overwhelming. If you’re struggling, another way to leverage story to make decisions is to ask yourself “what would Walt write?” Walt Mossberg is a (now-retired) tech journalist famous for his ability to write reviews focused on why a product matters or doesn’t for a customer. When you’re faced with a decision, thinking about what Walt would write about each path forces you to step back, gain a bit of perspective, and remember to put the customer first.
Finally, I hope this post added some tools to your PM toolbox to use when making product decisions in ambiguous situations. Early on in my PM career, I was frequently frustrated that a lot of what we were doing came down to opinion vs opinion, and I sometimes struggled to influnece discussions because my opinion was less meaningful since I was the low person on the totem pole. Using the techniques in this post, I’ve been more effective as a PM by adding objective reasoning to make my voice more meaningful, using prototypes to eliminate the opinion factor completely, and using storytelling to make my voice more impactful.
Remember that ambiguous situations often boil down to a battle of opinions, and even if you have a better-informed opinion, decision making isn’t always about who’s most “right.” I was in one situation where I disagreed with another stakeholder and finally said to my boss, “which do you want, a better product or smoother sailing?” Sometimes, the answer that’s right in an ambiguous situation is the one that allows you to remain effective so that you can help make the next decision.
