(2022-01-16) Product Lessons Learned A Conversation With Shreyas Doshi John Cutler

Product Management Lessons Learned: A Conversation with Shreyas Doshi & John Cutler. At some point, the major realization for me was that the key to understanding the other person is going to be to make sure that they know that I understand them

I need to make sure that the other person understands that I understand what they are saying

But then, the next big realization, and the quantum change I was able to make, was when I realized that when you listen just to what is being said (active listening), and you’re fully present, the responses craft themselves. Right? So I don’t actually have to think while you are speaking... I just want to be a hundred percent present. And I want to be curious. That was the change

Three out of those four companies, I joined as an individual contributor, including my most recent employer Stripe.com. I joined as an individual contributor and then started managing people.

There are other cultures, where a certain amount of uncertainty is viewed as just part of what we do which is, yeah, we won’t know how this is going to work out and that’s Okay. That doesn’t mean the second category of culture is less rigorous. I would argue that it’s more rigorous. Because it’s not based on illusions about strict mathematical outcomes based on certain inputs. (Thinking in Bets)

It works within that kind of real world understanding of these things. Versus some idealized, you know, oh yeah, we should be able to prove this on a spreadsheet kind of approach (model)

Let us understand what the customer feedback is. Let us understand what the market context is. And then based on that, we will make the best decision under the circumstances. But, you know, we don’t have to be certain that this will work out

there’s also the classic one way door, two way door, that I really saw practiced at Stripe. This is a decision that we can undo. Right?

you and I have discussed this topic of certainty theater. And, and I think that has a lot to do with the psychological safety that the culture creates for middle management in particular.

The way I view middle management, is they are the organization’s way of ensuring that you are able to get to the real truth.

So I think it’s really important for middle management to feel free to express the truths they’re seeing on both sides.

My observation is that most such product leaders with, you know, tremendous experience, great resumes. If you ask them, what is your role? Like, what is your real role? They will struggle

Once you understand the role, it becomes clear what you need to do, right?

And in order to sort of enable that product success through others, and I talk about it in terms of, and create self managing teams, right?. So creating self managing teams is so vital.

One thing that comes to mind too, is that often product managers seem to relish this nebulous nature of their role, starting even from the IC PM. They almost self-identify as the shapeshifter.

And I could imagine that that person, when they become a director, they move up. Maybe sometimes they can’t let go of that.

Shreyas Doshi: Oh, you know, John, what you just said resonates so strongly

this was me many, many years ago.

What you need to do is to enable product success through others, right?

I was still building out and developing my core product management skill set. It wasn’t fully built out, but I was asked to manage, which is fine, that happens in many other functions as well. But the challenge is that I wasn’t mentally there either, right? Like I knew that I had these gaps, and somewhere within me, I still had that drive to prove that I am a really great product manager. Not a manager of product managers, but a really great product manager.

The manager’s role in helping people adopt non-default behaviors

let’s take a hypothetical kind of blog post about what product managers are supposed to do

And say I’m a product manager, or a new product manager, and say like, okay, all of this makes sense. And I’m going to start doing this. And, guess what happens? Like I started doing it, and it works great.

If I’m the product manager I make this my default behavior. Because this is my first year doing the job. I don’t know anything about product management in various different contexts.

Now, transport me to a different team. Or a different company. Okay. Now, in this company, or on this team, let’s just say on this team, well the engineers are very independent. They are already talking to customers directly, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas.

I don’t think the failure is at the level of the PM. It’s not Alice’s failure. It’s the manager’s failure, right? It’s the manager’s responsibility to help a PM understand the context within which they are operating and then nudge them towards non-default behaviors.

you actually made the point where you said most people just want to get ahead.

There are three things that one needs to understand and use in order to get really good at something. There’s mindset, there’s principles, and tactics, right?

People often will start with tactics... for many people, they get stuck at tactics for the majority, if not the entirety, of their career

once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. Right. And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you’ll know which tactic to employ

even more amazingly, once you start understanding these principles, you can create your own tactics

And then mindset is the most important thing

All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD?

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it’s, we’re talking about you know, like Marty Cagan calls it empowered teams. (Cagan Empowered)

I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don’t know what it’s like, and what success is like, in environments where teams are not empowered

A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

part of me says, okay, yeah, maybe this should work. But the other part I’m not quite sure about is just like is it possible in every environment where teams are disempowered? (Change your Organization)

The basics/foundations for a high-performance team

what are some examples of basics that you have the right people in the right roles as an example

You might even put a certain bar of empowerment

Now that these basics are covered, what’s next?

I’m trying to answer the following question in many different ways

Why do teams with the basics met produce poor products?

Intentionality and stubbornness (with the company you want to be)

John Cutler: What I’ve observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they’re stubborn about connecting with customers.

One of the questions I will often ask is what type of company do you want to create? Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company? Do you want to be a sales focused company… (product-led)

I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I’m connecting to your stubbornness– about what I want to create. Because what happens is you, you can’t have it all

Google, as an example, and certainly during the time I was there, which was like 10, 10 ish years ago, was very much an infrastructure focused company.

Which is like, you know, you have Facebook, which is a very, at least certainly seems to me from the outside and from people I’ve talked to, it’s a very metrics focused company.

The easy choice to make is oh, we want to be customer focused. And then I have to remind people that, okay, if you’re, if you’re saying you want to be a customer focused company, but you are selling enterprise software, know that over time, what you’ll actually become is a sales focused company. And again, there are examples of tremendously successful companies that are sales focused.

this is how we do things. I know it sounds more negative than it should be, or this works for us, right? This works with the culture that we have. This works with the people and the skills that we’ve hired and so on. And that can be quite powerful, especially if you’re intentional about it.

Analytical and creative intelligence

What’s the difference between analytical intelligence and creative intelligence in your mind? Shreyas Doshi: At the root they build on each other.

However, that’s not how most of the industry views that.

we tend to view analytical reasons as being extremely important and correct. We tend to discount product creative, and we tend to discount instinct and judgment and various other kind of aspects

So that’s an interesting kind of issue that I think, again, it goes back to that core question of like, why do smart teams with adequate resources, still produce mediocre or poor products. What we forget is that many teams and many company cultures make it really hard for people to come up with creative ideas

typical product meeting at like any level. You are going to come across, in most such companies, you’re going to come across as a lot more competent if you show five different charts. You show a couple of tables

But what happens with that approach, and that mindset, is that you’re therefore the, the conclusions or the recommendations are actually quite constrained. They’re in this box.

Now, if you allowed for creative intelligence in the same way, what would happen is the conclusions would contain some wacky ideas, right?

likely get feedback afterwards from the manager of like– and the way it would be framed as not so much, don’t bring creative ideas, because nobody wants to say that– it’d be like, you need to back up your proposal with data.

Someone recently said we have too much hippo decision-making in my company. We have to use data, right? We have to use data to make the hippos go away. And then I said, well, what’s going to happen when you’ve got a gut idea?

your problem is not hippos. Because eventually you’re going to want to have creative ideas.

If you only have one idea, that’s terrible. If you have 50 ideas, that’s paralyzing. Do you have maybe three? And my friend Dan North said, no, you want seven. Because the first, the first one is your idea, the second two, three or four ideas basically support your idea. So you want seven because at the fourth one, the fifth, sixth, and seventh are when you’re getting out of your comfort zone. (idea generation)

Impact level, execution level, and the optics level

Oftentimes you find that one person on the team is operating and thinking at the impact level. And another person is thinking at the execution level. But they’re not talking about that. They’re litigating the minutia of the situation

say, a PM operating at the execution level works really hard against all odds.

the product is a reality. They are happy. The team is happy. Engineering, product management, design, data science, all of them are, people working on the core product, are very excited that they built something.

the product executive looks at the product, and the basic message is this isn’t good enough

people start immediately talking about fixes

but it’s first important to recognize that mismatch

So the way executives can operate better, and this applies to people at all levels, is to recognize why the team is proud of what they’ve done, they’ve actually executed against great odds.

this is great at the execution level, this falls short at the impact level, how might we achieve you know, a better outcome here?

you find that in many places, people are optimizing the optics level when they’re doing product work.

you do need to manage a certain amount of optics, just so you can faithfully express the impact of your work and the quality of your execution. The optics level should help the other two levels. And so you need to do sufficient work there. But there are many teams that primarily optimize for optics.

I don’t use the incentive language. I think a more fundamental issue here is like, how much is your culture and your organization compelling people to manage towards optics, versus managing towards execution, or managing towards impact.

Cognitive biases and shared vocabulary

I don’t talk about individual cognitive biases. I usually talk about our cognitive biases at the level of teams

as a leader– the onus for what I’m about to say is entirely on the leader– is to say, look, I’m going to fall prey to this. And as a group, we may fall prey to this. I just want to set the expectation that we will talk about this. And we will flag this when we see this happening.

so I think the shared vocabulary, and then what I just said is then shared accountability

I generally hate the word accountability, but that’s a separate topic altogether. But I do like it in this context, which is a kind of shared accountability as a team around reminding each other

there’s this project I was doing recently, which was an extremely ambitious project with a lot of unknowns. I shared with the team upfront, actually in that case, I shared two things. One was related to the cognitive bias

I shared with them that one of the main things that’s going to get in our way here, is that we are going to not be direct and open with each other, especially across these team boundaries

What’s going to determine our successes is whether we are willing to have the hard conversations with each other about this stuff? And are we willing to listen to each other and each other’s perspectives?

I also want to say that maybe you’re thinking this is a silly conversation to have cause it’s very fluffy, right?

I had not worked with some of the team members that we were going to work with, is I then set up you know, one-on-ones with some of the key team members, just to emphasize this again

And generally to get to know them enough such that they would feel the ability, and agency, to kind of open up and share when things are not working out. So, you know, this is an example of going against defaults

Generally, I avoid these kinds of regular one-on-one check-ins, right? We just keep adding and at some scope, it kind of takes over your calendar.

Treating dashboards as a product

Show me a bulleted list, right? Like here are the metrics we are going to track to understand the usage metrics, which is like, how is this feature being used? What are users doing with this? And, the second one being the impact.

most teams have the other category of metrics, which is the health metric.

That’s the first observation is like, we don’t adequately spec that out.

The second observation I made is that nobody is looking at that dashboard.

And track the usage metrics of your dashboard. Like a simple counter, for instance. How many people have viewed this dashboard that we spent a ton of time creating in the past week.

Once you start thinking about the dashboard as the product, of course, you’re going to then create requirements for the dashboard, and make it part of the original PRD.

I don’t think it’s because people are incompetent that these things happen. I think it’s because it’s hard. I think it’s actually just as simple as friction, right? This is yet another thing that you have to think about doing during your busy day

people love email metrics

people look much more closely at metrics that get emailed, than, sort of, metrics that they have to proactively seek out.

Filled calendars, reactivity, self-identity, and positive/ negative habits

you see these PMs who are in reactive mode all the time.

these early years, our formative years as product managers, we get into certain habits

it’s two things. It’s it’s habit and identity

Look at my calendar

whose calendar is worse. And like, that person is more of a PM, right?

this cannot be solved until you accept that there is actually a better way.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. Right. Well, what happens when you actually build self managing teams? You have to do less management, right?

Improving the current situation (and gap vs. present thinking)

common sort of argument I hear is yeah, yeah, things are horrible right now, but it’s because I don’t have a full team.

oh, you know the problem is we are not organized properly

What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I’m in.

My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking

consulting is all about the gap

And then he presents this other idea that present thinking is not adverse to thinking ahead. It’s like, what’s going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now?

LNO: Leverage, Neutral, and Overhead Tasks

during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I’m going to try to do an awesome job

means spending more time and exerting more energy on certain things.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what’s our 24 month projection for how the product is going to– like how much headcount do you need or whatever

And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what’s going to happen.

but usually when I get these requests, I get them done in five, 10 minutes

I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O

that’s where I think context also plays a pretty large role.