But a lot of the "it's unique per company" is actually "it's unique per founder".

This post does not offer recipe-like advice of how to deal with different founder types. Its purpose is to suggest a way of thinking that I’ve found to be more practical than my previous default. A way of thinking that leans more on empathy than resentment.

I'll share experiences from my past workplaces that contributed to this mindset change. And I’ll add excerpts I’ve collected through the years from public content that resonated with me. So this is not a short read.

Let’s start.

The product-oriented founder is the first product manager. Usually, the cofounder-CEO. That person determines what product management will look like in the company. Mostly in the way they implicitly evolve the decision making culture. And also in the way they delegate and create (or don't create) autonomy for others over time.

By autonomy, I don’t mean 100% autonomy. I mean that employees feel empowered to influence and execute decisions. 100% autonomy could actually be problematic in an org as there are dependencies. Unless you are the CEO, everyone is dependent on other team’s decisions and constraints.

I like the way Brian Chesky (Airbnb CEO) talks about empowerment from the CEO’s perspective. He starts off bluntly, but adds nuance as he goes (37:52-40:57 here):

I don’t believe that the way to empower people is to give them autonomy. I tried that for 10 years. I kept trying to give people more and more autonomy. And what happened was, control is not zero-sum. There's a way where everyone can be autonomous and no one can be empowered.

Because in an autonomous organization, you're only as good as the number of resources you have and the collaboration you have from other teams. So a team could be autonomous, but if they can't get on the payments roadmap, they can't ship anything.

And so what I decided is we are not going to have autonomous leaders. We’re going to be totally integrated. No one’s going to succeed at Airbnb without collaborating with other people.

There’s this age-old truism: “Great leadership is hiring people and giving them operating room and empowering them to do their jobs.” I don’t think that is good leadership at all.

Leadership number one: you have to audit the details. If I’m a CEO, my board empowers me, but they still audit me. How do you know your team is doing a good job if you’re not auditing them? If the board audits you, you should audit the team’s job. And that is, to me, the first expectation of a leader. More importantly, I think there’s another side of the coin. The micromanaging. Because I don’t think anyone wants to be micromanaged. I think of myself as partnering with my executives. I think of it as a creative organization where they’re not autonomous, but they’re in conversation with me. I don’t push decision-making down the organization. I pull decision-making in. I try to pull as many decisions into me as possible, like an orchestra conductor. I try to not have all the ideas or make all the decisions, but be in a constant conversation with my executive team about the decisions.

What I found is that my executives have felt more empowered than when they were more autonomous, because they’re not as much an island. Now they have the resources of the entire company behind them. There are certain personalities who want to do their own thing. They want to be CEOs and don’t want to be in an integrated collaborative organization, and that’s fine. Airbnb and a functional org might not be for them. But the notion that this way of working doesn’t empower people and doesn’t allow them to do as much is not true. Control is not zero sum. There is a scenario where everyone can have more control. There is also a scenario where everyone can be more powerless. I think that’s a very important thing to distinguish.

Side note - Above is Brian Chesky’s view before it was recently bastardized a bit by Paul Graham’s "Founder Mode" post. If interested you can see Brian distancing himself from Paul’s “Founder mode” in this interview with Scott Galloway at 18:16-22:10.

Not every founder-CEO is like Mr. Chesky. In my experience, most founders are less explicit about decision-making culture. They often don't see the specific moments where culture is shaped.

Product managers and department leads understand that decision quality (and buy-in) happens when you get the best decision out of a room. Most founders haven't experienced that at high frequency, so they default to micromanaging.

Yes, a good product hire can have an effect on this. The choice to bring in such a change agent and empower them requires a founder who has overcome their fear of delegation. However, product managers may have more influence than they realize in assisting founders to deal with this fear.

The fear

John Cutler nailed “the fear” in a now deleted tweet.

This fear continues to haunt the founder, even as their startup matures.

It's akin to a mother's perpetual worry for her children's well-being. My mother worried about me when I was a baby. She still worries about me well into adulthood. She’ll never stop. Even though that type of worrying habit is unnecessary now. Well, most of it 😅.

Sometimes founders get so used to obsessing over short term revenue that it becomes their worrying habit. Even when the company is healthy enough for some short term slack.

The quarterly board meetings don’t help the founder in breaking that habit. That’s the root of Elon’s “Funding secured” tweet in 2018 about taking Tesla private.

Same pressures apply to investor boards of non-public companies via end of quarter revenue goals. Below is Elon’s logic for SpaceX from 2013:

Here’s an example of the investor pressure dynamic in a non-public company.

Simon Sinek gets a question from a startup founder. The founder talks about the stressful relationship with his investors. How he's trying to think long term while they pressure him to think short term. Relevant bit is at 01:11:12-01:12:34

Founder: The shareholders are asking me when's my exit plan.
They have a finite game and because they hold the money streams, they think they can control the show. Trying to play a finite game against my infinite game. How do you handle it? Because every time they ask me “what’s your exit plan?”, I kind of say “well, it'll be the coffin and heart attack probably”.
But they don't take that seriously.
How do you handle that.. infinite versus finite players in the same project trying to control the strings?

Simon: Do you own the company?

Founder: Yes.

Simon: You took their money?

Founder: Yes.

Simon: {shrugs}

{Audience nod-laughs}

Simon: I got no problem with you looking for investors. But you took the number more than the investor. You took the one who offered you more money (and not) the person who aligned to your values. You took the person who was investing in the exit rather than who was investing in you and your vision.
Berkshire Hathaway does not sell the stocks it buys. Find money from somebody who believes in you and your vision, and will give you the might of their wealth, experience and the people who work there to advise you rather than force you into the exit.

Founder: Makes sense. Thanks {nod-laughs}

I felt this investor pressure for the first time when having a 1-on-1 conversation with my CEO. It was a good conversation about long term stuff. But I was too aggressive in pushing for long term thinking. The CEO felt this. He had a more balanced conception of long and short term than I did so he said something very short-term oriented. I told him he’s too focused on short term stuff. To which he said: “Yes Guy, but you can’t forget the short term. You can’t without it.”

To which I said: “Yes, but you can’t without the long term as well”. He smiled in a non-condescending way that conveyed “I already forgot the stuff you’ve yet to learn”. Made me realize I was under-indexing on short term much more than he was under-indexing on long term. I was drinking too much of the product influencers Kool-Aid. The real world is much more nuanced and layered.

Below is an excerpt from an excellent article that details these layers in the most succinct way. (The Two Laws Of Startup Physics by Eric Paley, Ex-CEO/Co-founder of 3M and now a VC managing partner):

Growth is the primary currency of the venture industry. VCs will upsell a startup’s growth to future investors and take a markup on their books. Markups help VCs raise money for their funds and grow their capital base over time. Most VCs want growth so badly that they’ve come to demand it regardless of the cost. This obsession is a short-term optimization with huge long-term implications for the startup, its founders, employees, and, ultimately, investors.

Investors value their startups based on how much money they raise and at what price, rather than thinking clearly about intrinsic value, which has only loose correlation to private valuations.

Entrepreneurs respond to this market demand by spending poorly on activities they know drive vanity metrics that aren’t sustainable to ensure their revenue continues to grow to meet their short-term goal of raising more money.

Many VCs don’t want to spend time engaging these laws of startup physics because they don’t align with the short-term VC incentive structure. Investors often lack the patience and incentives to make wise long-term decisions.

Conveying vision and strategy is hard

Even if the founder manages investor pressure well, there’s still a lot of anxiety around the main task of creating autonomy and a sense of ownership at scale.

That anxiety is dependent on their ability to convey the vision and strategy.

John Cutler writes about this challenge nicely here:

Then there is this this from Shreyas. The expert bias aspect.

Detailing a strategy is not a one-off write up.

Strategy is like culture. It needs to be reiterated via actions, not words on an office poster. It's about consistently making short term decisions that align with a long-term strategy and communicating that continuously.

I remember approaching one of the co-founder’s in my company and telling them that the vision is too high level. That it doesn’t help product managers decide what NOT to prioritize. It doesn’t create company alignment at a productive level. And perhaps one of the co-founders can write a monthly email to the company. An email with their specific thoughts around vision and strategy.

I could see the energy draining out of the co-founder’s body at the thought of writing an email like that. He said that it is generally a good idea, but once you write something, you can’t control how hundreds of people will interpret it. He didn’t trust the team to “get it”.

Thing is, no one knows how to write to hundreds of people. Take Elizabeth Gilberts’ advice (best selling author of “Eat, Pray, Love”). Elizabeth says that she doesn’t know how to write to a demographic. So she writes to herself or to a best friend.

It’s her #1 tip for writing (full list here):

Tell your story TO someone. Pick one person you love or admire or want to connect with, and write the whole thing directly to them —like you're writing a letter. This will bring forth your natural voice. Whatever you do, do NOT write to a demographic. Ugh.

But you are not going to teach the founder how to write. So we are left with the part about trusting the team.

Trust starts with replacing resentment with empathy

The above may be what your CEO/founder is dealing with. Understanding this is important. It helps you replace resentment with empathy towards your leaders. Empathy is your key for building trust.

Product managers' resentment towards leaders is what breeds memes like the three below:

Funny and relatable but not practical.

Even the “practical” product management content out there often fuels resentment towards leadership. Marty Cagan built a consulting company whose total addressable market is based on the premise that most companies do not have truly empowered product teams. I’d argue that the number of companies with truly empowered product teams is close to zero (though, of course, this depends on how you define “truly”).

That’s why this tweet resonates with most product managers:

Resentment could easily turn into contempt. Contempt is the biggest relationship killer (reason #1 in this random clickbait article that pops up when searching for contempt+divorce).

I know I’ve fallen down the resentment hole. I’ve surely unconsciously expressed it to leadership.

Here is how resentment towards leadership could develop in a product manager.

• I feel like doing discovery is not valued in this company. All that matters is delivering features, prioritized and handed over from above, with no business prioritization logic or strategy that I can understand. Sometimes it seems like the “strategy” is “do all the things”.

• The content interests me and I like my colleagues so I don’t want to leave, but I’m starting to feel like I’m not growing as a PM.

• I don’t understand how my work impacts the companies’ goals or what they are.

• I want to change the status quo to expand my autonomy in the problem space, but don’t have energy for pushing this change because of the above.

• I don’t have the hope that I can change anything as the issue has to do with culture coming from the top.

• When will they understand that something has got to give?

Who are these royal “they”?

The PM’s manager and the managers above them?

Sort of. But it’s really 1 or 2 people. The CEO or founders.

The founder’s message sometimes gets diluted, tapered and misinterpreted as it comes in via the managers.

Some of that message dilution has to do with managers confusing loyalty with agreeableness.

They are afraid that their discovery questions will seem like pushback so they don’t ask for clarity from the people above them, and just become a proxy of a diluted or misinterpreted message.

Loyalty is good but can become an issue if it dominates the culture, often at the cost of autonomy and empowerment.

Esther Perel, a clinical psychologist, has a question for her clients that cuts through this: Were you raised for autonomy, or were you raised for loyalty?

Here’s an excerpt from this written interview with Esther:

If a leader is very “loyalty” oriented they will hire like-minded people.

This creates a specific culture. New hires who are “autonomy” oriented will subconsciously adjust to fit into the “loyalty” culture. Ben Horowitz writes well about this in his book, What You Do Is Who You Are:

Many people believe that cultural elements are purely systematic, that employees only operate within a given corporate culture while they’re in the office. The truth is that what people do at the office, where they spend most of their waking hours, becomes who they are. Office culture is highly infectious. If the CEO has an affair with an employee, there will be many affairs throughout the company. If profanity is rampant, most employees will take that home, too.

So trying to screen for “good people” or screen out “bad people” doesn’t necessarily get you a high-integrity culture. A person may come in with high integrity but have to compromise it to succeed in your environment. Just as Africans in Saint-Domingue became the products of slave culture and then transformed into elite soldiers under Toussaint Louverture, people become the culture they live in and do what they have to do to survive and thrive.

Having said this, I do not believe in “types” of people. Yes, there are people that lean towards autonomy, but that doesn’t mean they can’t be loyal. And when a leader’s fear is triggered then they default to their factory settings as a person. Could be loyalty at the expense of autonomy.

That resentment you are carrying towards the royal “they” as they deprive you of autonomy is legit, but it’s mostly towards a dynamic and probably less so towards a person in the org.

I once worked at a company where the decision-making culture felt like a 9 out of 10 in difficulty. I stayed because I was growing professionally, but it wasn’t easy. What kept me going was this mindset: navigating a 9/10 difficulty now would build the resilience and soft skills I’d need if my next company’s culture was a 6/10.

I treated the experience as a personal growth lab. Whenever frustration arose, I reminded myself, “This is a lab for my personal and professional growth.”

There’s a great quote by Marcus Aurelius that touches on this:

Be tolerant with others and strict with yourself

I also love the way Morgan Housel writes about tolerance for culture difficulties. There’s value in “practicing” to increase that tolerance, whatever level it currently is. Here’s the relevant point from this excellent piece:

The inability to accept hassle, nonsense, and inefficiency frustrates people who can’t accept how the world works.

...If you recognize that BS is ubiquitous, then the question is not “How can I avoid all of it?” but, “What is the optimal amount to put up with so I can still function in a messy and imperfect world?”

If your tolerance is zero – if you are allergic to differences in opinion, personal incentives, emotions, inefficiencies, miscommunication and such – your odds of succeeding in anything that requires other people rounds to zero. You can’t function in the world.

I’ll tell you: So many people don’t have enough tolerance for BS. There’s a gap between their expectations and the reality of how the world works.

Yes. It demands a lot of energy to navigate culture, and it’s easier not to take responsibility. Heck, part of the reason I’m writing this post is for self therapy 😅.

You may be in a place in your career and life where you don’t have energy to go through that type of adversity. But if you do, there is a lot of value in taking on the responsibility.

Jordan Peterson has a great first principal take on resentment and responsibility.

Jordan Peterson is a clinical psychologist. Some of his stuff and ways of conveying messages are very controversial and I realize I’m going to lose some people’s attention when quoting him. I love some of his stuff, but I agree he can sometimes be very aggressive in his ways at the expense of whole demographics, and that recently he has gone off the rails. Below quote is not one of those cases.

Relevant bit is at 00:59:26-01:05:43.

People are often resentful if they see that responsibility has been abdicated. “Why isn't that person doing their job?”

It's like [I want to tell them] “hey man step in. At your workplace. In your family”. And you think, “I shouldn't have to do that extra work”. Well, you shouldn't be a slave. You shouldn't allow yourself to be tyrannized. But if something bugs you, because a responsibility is going unfulfilled, then there's a great opportunity for you.

And this is something I don't think we teach young people well. And one of the things that was so striking about the tour [Jordan did a book tour where he lectured in front of audiences] was that I made a case fairly consistently that most people find the meaning that sustains them through the vicissitudes of life not in happiness but in responsibility. And that would bring everyone to a halt. It would always make the whole theater silent. It's like “oh, I never thought of that connection”. Because maybe you want to avoid responsibility. And you can understand why. You hide from it.

Like one of the biblical stories - Abraham stays in his father's tent until he's 80, and then God gets fed up and tells him to get the hell out and grow up. And everything that he encounters is catastrophic. He encounters tyranny. The Egyptians conspire to steal his wife. He encounters starvation and war. That is what you encounter if you go out in the world. And you think “who the hell wants that? I don't want the responsibility”. It's like well, yes you do. There's nothing better than responsibility.

Now, I say that with some caution. I've been overwhelmed by my apparent responsibility. But I think it's also kept me alive and I mean that literally.

One of the chapters [in my book] is “Be grateful in spite of your suffering”. You need a meaning to sustain you through suffering. And it is the case that you find that meaning in responsibility. And it's good advice for anyone who's at work. You're resentful about this and that, because people aren't pulling their weight.

Pull it!

See what happens.

You'll become indispensable, instantly. You'll know everything. And maybe that job won't be for you, or maybe that relationship won't be for you, but you'll take your hard acquired wisdom and go elsewhere and flourish there.

This kid stopped me in a restaurant one day when I was walking in. He had an undergraduate degree and he was working as a waiter in a chain steak place. He said "about six months ago, I was watching one of your lectures and I decided to stop being resentful about my job”. He was resentful because he had a university degree and is working as a waiter. He said “well I decided I'd start trying at my job. Like really trying as if it was worthwhile”. Said he got three promotions in six months. He's just rocketing up the power hierarchy. Well, it's not power, it's competence. If it's well run then places are full of opportunity.

And that doesn't mean social structures aren't sometimes corrupt. But you can discover that too. If you start to take responsibility and that goes sideways, and you're not being credited with that. Well then that's an indication that you need to restructure the situation. Something's corrupt about it. Or if you can't do that, then you should go somewhere else where that is valued. It's a sign that things aren't right. If you bring your best to the table, and that isn't appreciated then there's something wrong with the table.

I’d go beyond this and say that if you see an opportunity for your growth and for business impact then appreciation can wait.

Yes, lack of appreciation can lead to burnout and the weight of its importance is different per person, and per phase in their lives. But lack of appreciation could be deceiving.

Sometimes, what you think is lack of appreciation is actually a matter of broken communication across hierarchies.

I love this from John Cutler about the telephone game:

First step of taking responsibility is to bypass that broken communication and have a 1-on-1 with the founder/CEO.

Have an open conversation outside of an urgent event.

Ask them what their goals are, and what are the current challenges and friction points preventing them from reaching those goals. More on that type of conversation in another post.

Below is a Tweet thread version of this post. Let’s continue the discussion there 😊‍

Further resources

High agency by Shreyas:

Office politics by Julie Zhuo:

244 pages that go by fast. Paused to highlight often. Can't recommend it enough. Should be mandatory reading for every product manager.

A lot of product books and blog posts I read stay high level. With some, you feel like you've read a content marketing piece that's meant to sell a workshop. This book feels like it IS the workshop. Teresa doesn't hold back.

If you are a fan of her Opportunity Solution Tree then this book goes deep and across. I feel like I want this book embedded in my brain Neo-style so that I can easily access Continuous Discovery Kong Fu. Guess I'll have to embed the content by finding opportunities to practice her methods as I go. Continuously.

When I was done reading, I read through my highlights. Wrote my thoughts for 21 of them. Specified why they resonated with me. Then tried to make that consumable for my future self and others :)

Here they are in no particular order.

1/

Every time we mix up the team or change the outcome, we take a learning tax as the team gets up to speed.

If you are changing what you are building then you may be implicitly changing the team’s outcome goal. Do it frequently and the team will never have the opportunity to rack up enough learning to build trust and autonomy. This is often why it’s hard to escape the feature factory.

2/

The more diverse your interviewing team, the more value you will get from each interview. What we hear in an interview will be influenced by our prior knowledge and experience. A product manager will hear things that an engineer might not pick up on, and vice versa.

I’m ashamed to say that in my 10-year product career I’ve <f-strikethrough>rarely<f-strikethrough> never pushed for an engineer to run a customer interview.

Surely, I have read about the value of it in different articles. But Teresa made me think about it in a way I haven’t until now. Big part of it is that I wasn’t interviewing continuously. So getting dev buy-in for joining a call became content-oriented instead of process-oriented.

3/

Nigel Cross, Emeritus Professor of Design Studies at the Open University in the United Kingdom, compared the knowledge, skills, and abilities of expert designers to novice designers (across a variety of disciplines) and found that the best designers evolve the problem space and the solution space together. As they explore potential solutions, they learn more about the problem, and, as they learn more about the problem, new solutions become possible. These two activities are intrinsically intertwined. The problem space and the solution space evolve together.

I like to think of discovery as 2 google docs (semi-metaphorically).
One for problem discovery.
One for solution discovery.

Doesn't matter which doc you start with. You simultaneously populate and edit both as they feed off each other while you raise their maturity.

4/

Research shows that while we are better at generating ideas individually, we are better at evaluating ideas as a group.

Teresa recommends giving people time to ideate alone before sharing with the group. Do this both within meetings and between meetings.

I remember an instance where the best idea came between meetings and as a result of the meetings. The lead designer, lead developer, and I had many brainstorm sessions about drag & drop logic for complex scenarios. No good solution arose from those. After one of the more frustrating sessions where I didn’t feel comfortable driving for a decision in the meeting, my design lead took the train home. He was still consumed by the meeting and had time to think. While on the train he left me an audio WhatsApp message with the most elegant solution to the problem.

Your job as a PM is to get the best idea out of the room. Even if that means ideas outside of the room 😊

‍
5/

Instead of jumping straight to why an idea won’t work, use your discovery framework to help the stakeholder see where their idea does fit. For example, is the stakeholder focused on a different outcome from you? If yes, then don’t shoot down their idea. Even if you don’t like the idea (remember, our preferences don’t matter), you can remind your stakeholder that, while their idea might be a good fit for their outcome, it doesn’t support your outcome right now. You can follow this same strategy if their solution addresses a different opportunity. You can always say something like, “That idea has promise. We’ll consider it when we address that opportunity.” You can even capture it on your tree or in your idea backlog (not your development backlog) so that you remember to return to it later.

If you can see that it is based on a faulty assumption, don’t just call that out. Help your stakeholder reach that conclusion on their own. You can do this by story mapping their idea together. Generate assumptions together. When your stakeholder sees what assumptions their idea is based upon, you can now share what you’ve learned about those assumptions in your past assumption tests. This helps your stakeholder reach their own conclusions about their own ideas.

I’ve had an exec come to me with an idea saying if we built feature X it will help with churn. But really what they wanted was a better demo. They wanted to get new logos as they were short-term-revenue oriented. By the time I realized this, the feature was already delivered.

Nothing wrong with short-term revenue and developing features for getting new logos. But if I knew that the intent was a better demo for prospects, then I would’ve made different nuanced decisions within the feature. E.g. I would’ve covered fewer edge cases.

It’s important to understand the outcome that drives the stakeholder. Especially if it’s unsaid.

‍
6/

Because product managers, designers, and software engineers typically report up, to their respective departments, it’s not uncommon for a product trio to get pulled in three different directions, with each member tasked with a different goal. Perhaps the product manager is tasked with a business outcome, the designer is tasked with a usability outcome, and the engineer is tasked with a technical-performance outcome. This is most common at companies that tie outcomes to compensation. However, it has a detrimental effect. The goal is for the product trio to collaborate to achieve product outcomes that drive business outcomes. This isn’t possible if each member is focused on their own goal. Instead of setting individual outcomes, set team outcomes.

I’ve had an R&D exec ask me “how do you measure your product managers?”. Said he knows how to measure his developers so can’t see why I wouldn’t. I was stumped. I didn’t know how to answer in a way that doesn’t perpetuate the throw-it-over-the-wall culture. Wish I would’ve thought to suggest setting team outcomes, instead of playing the individual outcome game.

‍
7/

Most companies have teams who are on the phone with customers day in and day out. This includes sales teams, account managers, customer-success teams, and customer-support teams. You can work with these teams to help you recruit interview participants. The easiest place to start is to ask a customer-facing colleague if you can join one of their existing meetings. Start by asking for five minutes at the end of a call. You want to make it as easy as possible for both your colleague and your customer to say “Yes.” Use the last few minutes of an existing call to collect a specific story about the customer. Once your customer-facing teams are comfortable with you joining their meetings, ask your customer-facing colleagues to help you schedule an interview with one of their customers. To make this work, you’ll want to define triggers to help your customer-facing colleagues identify who to reach out to. Triggers might include: If a customer calls to cancel their subscription, schedule an interview. If a customer has a question about feature x, schedule an interview. If a customer requests a customization, schedule an interview.

Build trust with your customer-facing team gradually so that they feel comfortable having you on a call with their clients. Then make them active agents to recruit clients for interviews.

Talk to enough clients and you’ll flesh out a shortlist of your favorite design partners. I.e. clients whose context best represents your target audience AND have high communication skills.

‍
8/

In the opening quote of this chapter, Marty Cagan, author of INSPIRED, highlights that the best product teams complete a dozen or more discovery iterations every week. This pace is possible only when we step away from the concept of testing ideas and instead focus on testing the assumptions that need to be true in order for our ideas to succeed.

...The biggest barrier to testing assumptions is becoming aware of the assumptions we are making.

...It’s common for ideas to share assumptions. It’s one of the reasons why assumption testing is faster than idea testing. Assumption tests don’t merely give us a go/no-go decision for an individual idea; they help us evaluate sets of ideas.

Fleshing out assumptions about why something will succeed or fail is the core of product work. Testing the riskier assumptions is where good product work happens. There is value in "testing" them by just discussing with experts within the company. With no mockup or dev effort. This is one of the best tips in the book. Teresa expands on how to go about it.

‍
9/

The key to bringing stakeholders along is to show your work. You want to summarize what you are learning in a way that is easy to understand, that highlights your key decision points and the options that you considered, and creates space for them to give constructive feedback.

...when it’s your turn to share, don’t advocate [for your idea]. Simply share your point of view, answer questions, and clarify your thinking.

...When you frame the conversation in the solution space, you are framing the conversation to be about your opinion about what to build versus your stakeholders’ opinion about what to build. If your stakeholders are more senior to you, odds are their opinion is going to win. This is why we have the dreaded HiPPO acronym (the Highest Paid Person’s Opinions) and the saying “The HiPPO always wins.” Many product trios [PM, design lead & dev lead] complain about the HiPPO but miss the role they play in creating this situation. When we present our conclusions, we aren’t sharing the journey we took to reach those conclusions. Instead, we are inviting our stakeholders to an opinion battle— a battle we have no chance of winning.

...Ask your stakeholders to add to your assumption lists. This is where their unique knowledge and expertise can be invaluable for helping us catch our own blind spots.

...a good product trio knows to continuously manage stakeholders. Share your work along the way, rather than all at the end. Be thoughtful about when and how to share your work. Some stakeholders will want all the details week over week; others might want the highlights monthly. Adapt to what your stakeholders need. But even if they ask for outputs, take the time to show the work that helped you conclude those were the right outputs.

...Give them space to follow your logic, and, most importantly, give them time to reach the same conclusion.

Stakeholder communication should be like an engaging documentary. Don’t advocate. Simulate for them the experience you went through that made you reach your conclusions.

Decide the best level of granularity when showing. Tailor it to the specific stakeholder. Don’t be afraid to show them more granularity than what they asked for.

Don’t make the mistake of one-off sharing right before point of decision. Share continuously. Bring them along for the ride.

10/

If you are reading this book and feel like these methods won’t work at your company, here’s what I’ll tell you: I rarely had the support of senior leadership to do product discovery well.

...I knew that I could impact how I did my own work. I didn’t worry about what other people were doing. I didn’t try to change the way these companies worked. I simply did my work my way, and I got results— so much so that, by the age of 32, I was the CEO of someone else’s company. I don’t share that to brag; I share that to show that you have more agency than you think you do.

Some people, instead of adopting a “That will never work here” mindset, swing the pendulum too far in the other direction. They want to work using the “one right way” to do discovery. I have news for you. There is no “one right way” to do discovery. All of the habits in this book can and should be adopted to match your team’s preferences and needs. This book isn’t designed to be recipes that should be followed to the T, but rather templates that should help you get started.

Don’t wait to get buy-in to do discovery work. Show how good looks like and build trust while not hurting delivery.

Move your work one notch at a time towards more discovery. Acknowledge where you and the company are now. Don’t go for a one-off 180 change.

“You have more agency than you think you do”. So true.

‍
11/

You might be tempted to score each opportunity based on the different factors (e.g., 2 out of 3 for sizing, 1 out of 3 for market factors, and so on) and then stack- rank your opportunities, much like you might do with features. Don’t do this. This is a messy, subjective decision, and you want to keep it that way. Remember, you aren’t making absolute judgments. You are making relative judgments by comparing and contrasting sibling opportunities against each other. You don’t need to score each opportunity. This will take a lot of work, will be rife with assumptions, and won’t lead to a better decision. Instead, make a data-informed, subjective comparison for each set of factors.

There may not be a clear winner, and that’s okay. One opportunity might look like the winner based on sizing, and another might look like the winner based on company factors. Yet another might look like the winner based on customer factors. Your job as a team is to have a healthy debate. Consider the different dimensions, and make the best decision that you can for this moment in time. Think about each set of criteria as a different lens through which to view impact. Use the lenses to fuel your conversation.

When we turn a subjective, messy decision into a quantitative math formula, we are treating an ill-structured problem as if it were a well-structured problem. The problem with this strategy is that it will lead us to believe that there is one true, right answer. And there isn’t. Once we mathematize this process, we’ll stop thinking and go strictly by the numbers. We don’t want to do this. Instead, we want to leave room for doubt. As Karl Weick, an educational psychologist at the University of Michigan, advises in the second opening quote, wisdom is finding the right balance between having confidence in what you know and leaving enough room for doubt in case you are wrong. That’s the balance we are looking for here. When we treat this like the messy, subjective decision that it is, we are leaving room for doubt, so that, down the road, if we learn we are addressing the wrong opportunity, we will be far more likely to course- correct.

Prioritization frameworks like RICE are subjective. Don’t try to automate any part of the decision-making process with a spreadsheet and a sort button.

There is no issue with spreadsheets as long as they are not the goal. The goal should be the conversation that the spreadsheet facilitates.

‍
12/

You’ll want to do the best you can to capture the value the participant is willing to share, but don’t force it. You always want to respect what the participant cares about most. Remember, with continuous interviewing, you’ll be interviewing another customer soon enough. When we rarely interview, a disappointing interview can feel painful. When we interview continuously, a disappointing interview is easily forgotten.

...We don’t want to think about interviewing as a step in a linear process. Instead, our goal is to interview continuously.

I am guilty of this. Forcing my agenda because:

• I finally have a customer on the line

• I was going about the process in a linear way

13/

You start by prioritizing your business need— creating value for your business is what ensures that your team can serve your customer over time. Next, the team should explore the customer needs, pain points, and desires that, if addressed, would drive that outcome.

...As you build a history of driving a product outcome, you need to remember to evaluate if driving the product outcome is, in turn, driving the business outcome.

I sometimes get obsessed about existing customers’ pain points to a point where I forget the business aspect.

E.g. if getting new clients is the company’s bigger challenge (as opposed to retention/expansion of existing clients), then acting on the most frequent support tickets may not be first priority now.

This doesn't necessarily mean trying to estimate the ROI of a feature. Just means picking the business parameter that is in line with the company strategy. And using it as a guide.

Tami Reiss has the most useful table I've seen for business parameters vs. product strategy. She wrote an article and shared a presentation about it here. It has a tighter table. But I prefer the one below.‍

‍
14/

When a customer expresses emotion in an interview, it’s usually a strong signal that an opportunity is lurking nearby. However, don’t capture the feeling itself as the opportunity. Instead, look for the cause of the feeling. When we capture opportunities like “I’m frustrated” or “I’m overwhelmed,” we limit how we can help. We can’t fix feelings. But if we capture the cause of those feelings we can often identify solutions that address the underlying cause.

I used to stop when someone expressed emotion. The unconscious fear was that questioning the emotion would come off as judgment. I’ve learned to see it as an opportunity. I now approach it with curiosity and empathy. I do this both in my personal life and with clients & colleagues.

When a client expresses emotion try to get them to talk about the end-to-end effect. Go beyond the product. Especially relevant in B2B, where the “job to be done” is sometimes a job that was handed over to be done.

‍
15/

A product trio should share what they are learning with the rest of their team, their product peers, and with key stakeholders. However, when we share pages of notes that make sense only to us and/ or a video of the full interview, we are expecting our colleagues to put as much effort into our discovery work as we do. This isn’t feasible. They have their own jobs to do. Instead, use your interview snapshots to share what you are learning with the rest of the organization.

I remember an instance where a design lead sent the product team a link to a 1-hour customer interview saying:

“I just had the best customer interview ever. The client identified all of our product’s flaws and communicated them with a crazy amount of insight. I won’t do it justice if I tried to summarize. It's a must-listen!”

I had it on my to-do list. I really intended to listen to it. Never did.

Share the learning in a consumable way. Assume no one will consume the full raw artifact.

16/

I believe continuous interviewing is a keystone habit for continuous discovery. Of all the habits in this book, if you are looking for one place to get started, this is it.

I don’t believe I’ve met a PM that truly believed they are talking to enough clients.

I do believe that in B2B there is a lot of value in talking to customer-facing teams. They talk to more clients in a week than you’ll be able to talk to in 3 months. But you’re still getting someone’s interpretation of a conversation. Gives a false sense of checking the customer interview box.

I’m always “not getting to it” because of delivery tasks. I’m going to shoot for finding a way to continuously interview without hurting delivery.

‍
17/

Company factors help us evaluate the strategic impact of each opportunity for our company, business group, or team. Each organizational context is unique. Google might choose to address an opportunity that Apple would never touch. We need to consider our organizational context when assessing and prioritizing opportunities. We want to prioritize opportunities that support our company vision, mission, and strategic objectives over opportunities that don’t. We want to de-prioritize opportunities that conflict with our company values. We also want to consider the company’s political climate. We might need to spend a lot of political capital to gain support for a more controversial opportunity. If we aren’t willing to do that, we’ll want to choose another opportunity. Company factors also apply at the business-group and team level. A business group might be your business unit, your department, your tribe, or even your product line. Your business group’s vision, mission, and strategic objectives might add additional constraints on what you may or may not choose. These same factors might apply at your team or squad level as well.

Company factors are rarely talked about as explicit input for prioritizing opportunities. Political climate was definitely a factor in the companies I’ve worked at (200-1000 employees).

If your team or the company won't have the appetite to set up the initiative for success, then work to increase that appetite. Or if you don’t have the appetite to do that then choose another initiative.

‍
18/

When you get stuck, start with your competition. But then look wider. Ask yourself: What other industries have solved similar problems? They don’t need to be similar or even be in an adjacent industry. You are looking for similarities in the target opportunity. For example, if you work for a job board and you are helping recruiters evaluate job candidates, you can look at other job boards, but you can also look at how online shopping sites help shoppers evaluate products, you can look at how travel aggregators help travelers choose hotels, and you can look at how insurance companies present different policies. These industries are unrelated to each other, but they are each solving analogous problems. Additionally, when you are stuck, you can start to consider what your extreme users might need. What would a power user want? What does the first- time user need? What about people with different disabilities? How about people who live in remote locations or bustling cities? Young people? Senior citizens? Your extreme users will vary by product, but thinking about the needs of different types of users as they relate to your target opportunity can help you generate more ideas that may work for everyone. And finally, don’t be afraid to consider wild ideas. Some people don’t like this suggestion, because wild ideas are rarely pursued. But wild ideas can improve more feasible ideas. This is where the power of mixing and matching different solutions to identify even-better ideas comes into play. So, when ideating, pretend you have a magic wand— anything is possible.

Great tips for how to jump-start creative thinking. Examples from my experience:

• Similar problems - When I was a PM of an editor for building walkthroughs on digital products, I took UX and functionality “inspiration” from editors of email marketing products. They had an editor for building no-code flows.

• Extreme buyer stakeholder - When I created our security roadmap I thought of the strictest security person in mind. A person that would have the most objections about embedding our product into their internal systems. It differentiated us from the competition for enterprise deals.

‍
19/

Product teams often have to do some discovery work to identify the connections between product outcomes (the metrics they can influence) and business outcomes (the metrics that drive the business).

...S.M.A.R.T. goals play a role and are common for trios that have experience with their product outcomes. But it’s not one-size-fits-all. It’s perfectly fine to start with a learning goal and work your way toward a S.M.A.R.T. performance goal.

I like the idea of setting non-measurable “learning goals”. You can’t just sit in a room and figure out how your OKRs/KPIs cascade. Discovery work is often needed to flesh out performance goals.

20/

It’s important that we frame our discovery decisions as two-way door, reversible decisions. Lottie Bullens and colleagues, social psychologists at the University of Amsterdam, found in a series of studies that, when people viewed a decision as reversible, they continued to critically evaluate their decision after making it.

This innocent text is the toughest environment to create.

As an individual contributor PM I’ve always felt pressure to make “send and forget” decisions. Pressure comes from leadership implicitly. Revisiting a decision is perceived as “pausing” or “going backward”.

Very hard to create a reversible decision environment as an IC PM. Leadership should drive this attitude via leading by example. Make your PMs revisit past decisions. Make it part of the process. Do this once or twice outside of an emergency to jumpstart the habit.

The alternative creates a culture where PMs are afraid to move forward without high certainty. Decision cadence slows down as the fallback is “death by committee”. Then delivery time stretches out. And that feeds the cycle of pressure to not "pause and revisit".

‍
21/

While many teams work top-down, starting by defining a clear desired outcome, then mapping out the opportunity space, then considering solutions, and finally running assumption tests to evaluate those solutions, the best teams also work bottom-up. They use their assumption tests to help them evaluate their solutions and evolve the opportunity space. As they learn more about the opportunity space, their understanding of how they might reach their outcome (and how to best measure that outcome) will evolve. These teams work continuously, evolving the entire tree at once.

They interview week over week, continuing to explore the opportunity space, even after they’ve selected a target opportunity.

Bottom-up discovery is a good place to start fleshing out the middle and top. If you’re part of a HIPPO/feature factory culture, start fleshing out the assumptions of what you were asked to build. Start building ammo for future autonomy.

‍

Below is a Tweet thread version of this post. Let’s continue the discussion there 😊‍

If you liked this post, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now