Product Management Webinar: Communication and Extreme Clarity

[00:00:00] Janna Bastow: Welcome to the Product Expert series of webinars that we run here, and welcome to today’s session. This is a webinar that we’ve been running here for quite some time here at ProdPad. It’s a series of webinars. The past ones have all been recorded, so you can go back and see those if you go to ProdPad.com/webinars. The past ones are a mix of presentations and fire sites like today’s gonna be. And it’s always with a focus on the content and the learning from amazing experts with insights that we bring in to learn from. So you will get a chance to ask questions and to understand as to how our expert of the day has been learning and adapting over their career career. I’m gonna introduce Simon in just a moment properly, but everybody just say quickly hi to Simon.

And before we jump into it, I do wanna say a quick hello about the ProdPad tool that we’ve built here. Now, a lot of you, I’m sure some of you are ProdPad users already. Say hello if you are, and I wanna say big thank you to you. As ProdPad is a tool that helps you extract value from your backlog to make sure that you are building the right stuff. Make sure that your dev team is working on the right stuff, and that everyone in your team knows why decisions are being made. So it helps you understand what your overall goals are, connect it back to your OKRs, helps you make a roadmap that the rest of your team can understand and get on board with and make sure that you’re actually building the right stuff. It’s a tool that was built by myself and my co-founder when we were both product managers ourselves. And it’s being used by thousands of teams around the world now. So jump on in, start a free trial. We even got a sandbox mode, which is preloaded with example data, so it’s dot example, lean roadmaps and OKRs and ideas and all that stuff. So it fits together in one place. You can play with it and see how it’s gonna work for you.

And you might also, if you’ve been using ProdPad lately, have seen some of the stuff we’ve been working on in the AI space. There’s a lot of interesting things happening in the generative AI space. We didn’t wanna just use it for generative stuff, right? We didn’t wanna just use it to generate ideas and user stories and key results. It can do that stuff, and people are loving it ’cause apparently that’s the grunt work and we’re taking some of that away. But we’re also using it to give smart feedback on things like your vision or whether you’ve got alignment between your ideas and your vision or your roadmap and everything else. So it’s acting like your coach and your sidekick. And one of the newest things that we’ve built in there is a bot that you can chat to, and you can use it for product advice in general, but we’ve also now connected it to your ProdPad accounts. You can ask it questions like, “Is this coming up on our roadmap, or could you summarize last week’s feedback?” Really fascinating stuff to see where it’s going. We’d love to get your feedback on it, try it out and let us know how you go.

And without further a- ado, I’d love to introduce you to Simon Cross. 

 Good evening, Simon. Thank you so much for joining us here today. So I know Simon through the Mind the Product Network. He was a speaker at the Mind the, on the Mind the Product conference in London in 2016. And he had a great talk and it just highlighted a bunch of stories from your life at that point in time when you were working at Facebook and how various product decisions were being made and how they were… How you came to those and how they were communicated. And it’s called Paving the Cow Path and other stories about how you listen to customer feedback and basically figured out what to build based on user behavior. Really fascinating stuff. And I think ahead of its time, some of the points that you made in there. So today, Simon is CPO at Native Instruments where he leads the product management, product design and sound design teams and the overall product strategy. And before that, he’d spent 12 years at Facebook or Meta where he worked on the developer platform workplace the enterprise communications part. 

[00:04:00] Simon Cross: Thanks everyone. Thanks you, Janna for inviting me, and it’s nice to be here.

[00:04:04] Janna Bastow: Yeah, absolutely. Great to have you here. So do you want to give a little bit, for people who aren’t familiar with you, do you wanna fill in some of your background and how you got into product management?

[00:04:15] Simon Cross: Yeah, I got into product management a lot of people did somewhat accidentally when I was coming up through tech and media. Product management isn’t a thing I knew existed. I my background is in engineering electronic engineering and kind of my first kind of love was radio, like commercial radio and, the BBC and like radio, that thing that you listen to. And that was where I really got started in, in, in my career. I got into radio just at the time we were moving from everything was analog, CD players and mixing desks and microphones?

 To everything being digital. Computers being play out systems radio stations, studios being mixing desks with computers inside. And I realized that to build things, you used to wire them together and now you code them together. And that was how I got into kind of coding. And from that, I got into building web and mobile experiences at the BBC and in commercial radio. And once you start doing that, it’s actually quite a clean jump from building things people are using to figuring out the things that people want. And so then that was my jump into product management. I did at the BBC back in kind of 2016 or yeah, 2009, 2006. Oh, yeah, God that long ago.

 Yeah. So I worked on kind of BBC Pride Player the BBC podcast service and a whole bunch of stuff like that. And that’s how I got to know the Facebook folks. So I joined Facebook in September, 2010. The company was less than 1,000 people. Everyone was still in one building at 1601 California Avenue. I started in London where the team was about 40 people above a chicken shop in Ganden Street. And by the time I left in November, 2022, the company was like 80,000 people. So it grew 80 X in the time I was there. And just to give you a sense of kind of the original starting point I went to see the movie with Mark and the whole company. When I say the movie, the Social Network movie in my fourth week [laughs].

[00:06:08] Janna Bastow: That’s something to look back on. That’s really cool.

[00:06:10] Simon Cross: Yeah, it was a hell of a journey. And I thought I at the BBC, I thought I knew product management, and I… It turns out I absolutely didn’t. Basically, everything I worked on there didn’t really fly.

 And that’s where I learned a bunch of mistakes. And then my journey through Facebook was really learning from the pros. There’s a lot of amazing people there, just there are a lot of the big tech companies. It’s got a really strong community around, learning and war stories and all that kind of stuff. And so I, I learned a lot from the people there.

 And by the end of my career at Facebook, I’m not finished in my career just yet. I guess people were looking up to me to tell them some of my experiences and that’s what the Mind and Product conference talk was about. And it’s what I try and do today, help and coach the product teams I support.

[00:06:55] Janna Bastow: Excellent. All right. A couple questions. So for people listening in, who here has seen the movie, the Social Network? For Simon, what did Facebook and Mark think of the movie? Bit of a segue. This isn’t what today’s about.

[00:07:07] Simon Cross: There’s a fun anecdote I won’t tell the full version of it, but before the movie came out, everyone knew that there was a movie coming out about your company, right? And I wouldn’t say there was worry, but there was some apprehension what’s it gonna mean for us? At the point, that company’s less than 1,000 people, it’s got kind of 500 million monthly active users. What’s, what does this potential movie mean to us, right? Is it, is everyone gonna wake up the next day and not wanna be on Facebook anymore? What’s it gonna do? Which is why it was so smart of Mark to this is a funny bit of the story. Everyone was in the office back in the day, and I was in bootcamp, this was my fourth week, so I was coding with a bunch of people.

We got an email from Mark saying, “Hey folks, early Q&A today. Please come to the cafe for 12 o’clock.” And Mark to this day does a Q&A at 4:00 PM on a Friday, and was doing them back then. And everyone was like, “Oh, shit. What’s, what does that mean?” [laughs] Everyone files up into the big cafe. It’s called, I think, called Cafe Epic in 1601. I remember it pretty clearly. And Mark just grabbed the mic and stood up standard at the front, stood at the front and was like, “Should we go see the movie?” And unbeknownst to us the company has rented 3D screens of the Century 21 in Mountain View. If you know that area. You’ll know the cinema. And outside the front of the building were like 25 massive coaches. And the whole company piled onto the coaches and went down to, down the freeway to the cinema, and th- the whole company watch the movie together. And then unbeknownst to us, we’ve rented out, the company had rented out eight of the big bars in downtown Palo Alto, and we all just went for drinks.

 And it was like… I remember being there being like, I need to remember this. This is like one of those moments that like, this is absolutely freaking crazy.

 [laughs].

 And it was. And I think if there’s a story behind that I think it’s a great example to take a lesson out of it of I think, so Johnson calls this eat the spike, which is it’s really easy for people to shy away from a thing that’s risky or might be bad. And I think like the learning I had from Mark’s approach to the movie was like let’s hit it head on. Let’s go watch this together.

[00:09:24] Janna Bastow: Everyone is going to watch it anyways, right? And you’d rather all see it together, get it out and have a great experience.

[00:09:29] Simon Cross: Yeah, it was great.

 [inaudible 00:12:53].

 Yeah, it was very smart. And yeah, there’s the parts of story I shouldn’t share here, but yeah, that was a hella day.

 [laughs] 

[00:09:36] Janna Bastow: I’d love to hear the full story someday. But we’d love to hear about how your role evolved while you were at Facebook. Over that period it changed names. You started working on Facebook work, which didn’t exist when you were there. How did things change while you were there?

[00:09:51] Simon Cross: It changed a bunch. And I think there’s a whole bunch of lessons in that as well. So was there for 12 years, people were like, “Wow, 12 years at one company in tech. That’s crazy.” But it wasn’t one company. It was-

 … A whole bunch of companies really over that period. And the different teams I worked on very different things, right? I started working in the partnerships organization, actually, ’cause it’s… I couldn’t… I was based in London at the time, in 2010, and couldn’t move to the US. And I had to… And there was no product organization in London at that time. So I went into partnerships moved to the US in 2013 to get into product. So my first five years was on developer platform stuff its own organization with its own culture and its own problems, its own ways of doing things.

Fast-forward to 2016, moved back to London helped found this thing called Workplace by Facebook which is now doing pretty well, part of the founding team. Completely different group of people, completely different product life cycle. The thing I’d come from was serving 3 trillion API hir- API hit a today, the thing I moved to had less than 100,000 monthly active users. So huge difference.

 Que 2018. And I go work on Integrity, which, other companies call it trust and safety, where I’m running the team in, not running, supporting the team in London which looks after fake accounts, abusive accounts, child safety, scams, bullying harassment, misrepresentation, identity verification, and a whole bunch of other… Oh, health misinformation, a whole bunch of other stuff.

 No small tasks then.

 Yeah, absolutely bonkers. Absolutely bonkers. That’s probably the most meaningful work I’ll ever do in my career. Just to give a sense of the scale at which those teams operate, and this is public information. Facebook disables about 270 fake accounts a second.

 Wow [laughs].

 Absolutely bonkers like the level of scale that we operate at. And that was a real masterclass in a few things. 

That must be done programmatically, 

[00:11:40] Janna Bastow: right?

[00:11:41] Simon Cross: Yeah. We don’t have people doing that.

 So that was a real, that was a real… I learned so much doing that, that many of my, many of the lessons I maybe we’ll talk about today in terms of extreme clarity and how to operate a product organization at scale, were just forged in that environment where like you are dealing with crazy new technology, how you apply machine learning to operate at that scale. And it’s at the intersection of not only technology, but society. What is it okay and not okay for people to say to each other on the internet?

 Discuss and also how to operate in a world where everybody thinks you’re doing a bad job, right? The people who want you to take down more stuff are annoyed at what you missed. And the people who took down the bad stuff they wanted to do are annoyed with you. And the people who are the false positives, whose accounts or content you impacted are annoyed at you. We have this phrase that 100% of the problems still remains. So many teams they want a goal, let’s hit the goal, right? We’re gonna make money, we’re gonna grow, whatever it is. And if you’re in Integrity and trust and safety and security, if you’re doing an amazing job, no one will ever know. It was like, just super interesting. There’s just a comment in it from David.

So the last thing I worked on before I left Facebook was I flipped over to a team trying to do a better job of fixing the false positives. And occasionally, some of this innocence accidentally get dele- acc- gets accidentally disabled. Good luck getting back in. I can talk about that in some detail too. These problems are extremely challenging, and much, much more complicated than people would think. There’s all kinds of crazy stuff going on. There are people, bad actors actually trying to get your account disabled often for various reasons. It’s it’s a whole world. I learned so much about how to run a product organization at scale, and how much clarity matters.

Like, when you are moving quickly and operating at scale and you need a record often of the decisions you made and why I think miscommunication is something that can cause teams great deals of harm, [laughs]. Anyway, so that was like my last four years at Facebook and Meta, it was amazing. The people that do that work are fricking awesome. And, while te- trust and safety teams all over our industry are doing tough work, and you might think that they’re all doing a crappy job. Almost certainly, I could tell you if they stopped doing what they were doing, then you’d see how good a job they really are doing.

[00:14:11] Janna Bastow: Yeah. I’m seeing some similarities with the conversation we had with Randeep to do last month’s webinar. He operates in the healthcare space, and was talking about how a decision you make in this space will kill someone. So how do you clear your conscience about that? And he’s talking about having to make decisions that, would affect one demographic over another. And how do you prioritize between different groups and decide who gets the better healthcare, for example, when you can only serve one particular group? No one ends up happy, you can’t save the world. So this sounds like another one of those high intensity, high risk spaces to be in.

[00:14:50] Simon Cross: It is. But yeah, high risk, high intensity hi- high reward as well. The amount of good work that gets done by trust and safety teams, but no one ever really knows.

 Its same thing. Yeah. How do you prioritize between child safety and scams? Both are bad [laughs], right?

 [laughs].

 Ah.

 Yeah.

 Again, I think, and somewhat the answer is extreme clarity, like coming up with a frame… It’s like any prioritization problem. It might be less savory because the things you’re having to prioritize have kind of impacts beyond opportunity cost.

 Like for example, if you’re in a regular product job, and you are trying to grow your, let’s say you are trying to grow your product by two X, right? If you choose to do A versus B, and if you choose A, and you grow 50%, and if you’ve chosen B, you would grow 100%. The only thing that you’ve lost is like the opportunity.

 But when you’re having to trade off, more on savory things, and there’s real downsides, yes, it gets tough. The answer is principles. Coming up with like defensible or at least relatively defensible frameworks that help you make those hardcore prioritization decisions. People can argue about the framework being wrong but as long as the teams are making decisions in accordance with the framework, like at least you set people up for success. I think that, that approach goes for basically any product management decision you have to make. It’s all about trade-offs and payoffs, as they say.

[00:16:18] Janna Bastow: And having principles allows different teams to make decisions under the same framework more autonomously than having to constantly badger for the right answer or sit there with their, twiddling their thumbs unsure as to how to act in tough situations.

[00:16:33] Simon Cross: Yeah. So let’s talk about that a little bit. What… The ideal trade-off framework is a single metric, which is why I think teams that work on ads, for example. And inside Facebook the teams that worked on ads had a thing that they, the same language, they could all talk about dollars, right? You can literally say, feature X versus feature Y estimate X dollars, Y dollars. X is great than Y. Let’s go for X, right? And I think one of the teams that one of the things teams struggle with is team A values thing denominated in monthly active users. Team B values something denoted in dollars.

 How do you trade off? It’s like trading euros versus dollars, or, or even happiness versus, I don’t know, hunger. It’s totally different concepts, right? And I think one framework, one, one thing that I’ve tried to do and we try to do in my old teams I’m trying to do more of now is either get multiple teams to actually care about the same thing. So everyone cares about Mao. Okay, great. Now we know what we’re trying to drive and we can trade this opportunity against MAU versus this opportunity against Mao. Another way of thinking about it is when there just isn’t, it isn’t possible to make those trades, is can you create an exchange rate, right? Is there a way you can figure out an exchange rate? And this isn’t always easy, and often people argue about it. But let me try and give you an example. Let’s say Team B caress about dollars because they like run ads. And team A caress about growth, right? Monthly active users.

So this team talks about MAU as their goal. This team talks about dollars as their goal. How do they work together? If you can, for example, make a an LTV calculation or an ARPU calculation for your Mao, then you can actually begin to get close to if we add 10 monthly active users making this up, then that’s worth this much over the lifetime of the company in dollars. Now we’re talking dollars.

 If you can try and find those trade-offs if you can try and find a common currency or a way to yeah, make it exchange rate between two different quantities that can often help a team yeah, extreme clarity, right? 

[00:19:06] Janna Bastow: It’s about finding a common language, right?

[00:19:09] Simon Cross: Yeah. It’s often much harder than the idealized situation I just came up with.

[00:19:13] Janna Bastow: I can imagine, because I was just thinking in the, stretching that metaphor of exchange rates using the metaphor of exchange rates I can imagine that exchange rate would change depending on the context and what’s important to the business. And, what a monthly active user is actually worth to the business at that point in time, depending on whether they’re actually gunning for growth or gunning for something else at that point.

[00:19:33] Simon Cross: These things aren’t easy.

 [laughs].

 Users that come in from different sources, let’s… You, again, hypothetical scenario, you acquire a user in North America, versus you are a user in South America, typically worth different LTVs over time just because of the GDP disparities between those countries.

 Yet, you get all those kinds of getting into those kinds of conversations. But I think if you can try and find a common currency you can literally, step one, common language, step two common currency. You can literally make like data-driven trade-offs because you’re able to translate one into the other. I think one of the things that the growth team at Facebook does really well, there’s a lot of things the growth team at Facebook do incredibly well. That’s why Facebook is Facebook-

 [laughs] Yeah.

 … is there are lots and lots of ways to drive growth, loads of ways to drive growth, right? Just think of a traditional growth funnel from like acquisition, activation, retention, and then all the way down to churn and resurrection at the end of the growth funnel, even in just the top end of the growth funnel. Just to just draw a regular growth funnel for a regular product, right? Add, click, landing page, sign up, activation experience to a place where you are like retained forever, ideally, right? Some form of asymptotic retention, classic growth funnel.

 If you were like, let’s imagine that each part of that growth funnel has a different set of teams on it, which at Facebook scale and Google scale and many other companies you do, you have 20 growth teams across different parts of growth funnel. How do you trade off how do you evaluate whether or not an improvement to new user retention, which you might be looking at AJ curve, how important is an idea there that let’s say improves new user retention from 20% to 23%, versus someone who might be looking about the top of the funnel, like ad clicks and stuff like that? The exchange rate they ended up working with was annualized monthly active users annualized mal. So each of these things you have a formula to turn it into what does that mean for annualized MAU impact? And that meant all of these teams could start to talk about the same thing, which was like, how much is this worth to annualized mal?

 And that really helped a lot of teams communicate and collaborate, ’cause they had an extremely clear common currency. 

[00:22:06] Janna Bastow: That’s a really good way of putting it. And so I get to see how large teams like this are using these these metrics to communicate across different teams like that. Because one of the things that I see teams really struggling with is matching their pace or matching their their aims across different areas and making sure that they’re actually communicating their shared goals. So can you share any anecdotes or any times when a lack of clear communication led to challenges?

[00:22:32] Simon Cross: Yeah, I’m gonna, I’m gonna use one that I… A fun anecdote that I that I used in a conference talk a while back, ’cause I just think it’s so powerful. And that is this idea of the Mars Mars Explorer, I think it’s called. It’s a NASA probe.

 That kind of NASA put into space and then they were waiting for it to arrive at Mars and then it disappeared off the radar, basically. And it turned out that when they looked into it, most of the probe was built by NASA, but they subcontracted the navigation system to another company, another big American aerospace company. And as a result, it was a miscommunication. NASA works in metric, and this other company works in imperial.

 And so I think that’s just a great example of where at an interface between two teams, and it’s often at the interfaces where things break down. Each side had made an assumption about the other. They’d made an assumption. And that assumption caused the loss of a hun- $350 million spacecraft. So that’s just a great example of where if you’re not super clear yeah, Mars Climate Orbiter, thanks David Nash. Great story. And just a great example, I think, of like where an inadvertent miscommunication, not even a miscommunication, just an assumption that resulted in a miscommunication caused like extremely valuable [laughs] extensive mistakes to be made.

[00:23:57] Janna Bastow: This story hurts me every time I hear it. ‘Cause it’s such a simple one as well when you look back, and yet when you look at how it happened, it’s exactly the sort of thing that our teams are guilty of, right? Everyone has teams who are guilty of making an assumption about something, and not clarifying it until the last minute. You’re like, “Wait, I thought you were doing that part, or I thought I was gonna be doing this.” 

[00:24:17] Simon Cross: Oh.

 And you see this all the time.

 [laughs].

 All the time. I literally, before this webinar I just came from a work call where like we were having a discussion about something, and someone said, “Oh oh yeah, we should really look into that.

 And two problems with the statement we should really look into that, is who’s we?

 And what do we mean by should-

 Yeah.

 … [laughs].

 I’m like, “Okay, cool.” Like you… Someone could go away and I think did go away from that conversation say, “Oh yeah, we should really look into that.” And I have no idea who’s doing what.

[00:24:55] Janna Bastow: That is the language of someone absolving themselves from doing it and just hoping someone else is gonna pick it up. And you were right to call it going what is actually going to happen here? What are the next steps? 

[00:25:09] Simon Cross: Yeah. And it goes down to this is gonna, this is gonna make me sound like a real pedant, but I tell you what, this kind of thinking has saved my ass 100 times, right?

 Just “Okay, I’ll…” Someone says, “Okay, I’ll take that action. I’ll take that away.” okay, great. So we’ve got a person doing a thing.

 Did we align on what the output or outcome is of the action they took and when they’re gonna deliver it?

 And you could say… I’ll just give you another crazy example. I work on… I- I’ve worked a lot on teams that span time zones. My team right now, a lot of them are in Berlin, and a lot of them are in Boston plus one hour minus five hours. Facebook obviously, minus eight often. So you say things like, “Oh yeah I’ll get that to you by by the end of the day.” Okay, great. End of the day. Cool. But like-

 Is that midnight [laughs]? Is that 5:00?

 That, is that midnight? Where?

 Which time zone?

 Which time zone? Yeah.

 Yeah.

 And it can sound a bit pedantic, like there, there are times where it’s not worth the kind of weirdness of going to that level of detail, but for a lot of things it really is.

 If I need something by the end of day today so that I can read it in time for a 9:00 AM meeting-

 Then you giving it to me at 10:00 AM tomorrow ain’t gonna fly, right?

 And I think often, when I pushed for kind of clarity on something, someone’s go, “Oh no, I… Oh, I can’t do it by then.” You’re like I thought that’s what you said.” [laughs].

 And like again, you can zoom right in to a 30 minute one-on-one and having those, or a small team meeting and those detailed action points, you zoom all the way out to a team that’s relying on another team to build them a thing that is required for their success.

I thought you wanted X.” no, we wanted Y.” okay we didn’t, we weren’t extremely clear with each other about what we were expecting from each other and by when.” I think the reason this is so important in large organizations or organizations where there’s a lot of moving pieces is the cost of getting it wrong can be serious, right? Let’s say this hypothetical example, team one, team A and team B need to collaborate on something over a quarter. They get to the end of the quarter, and like the thing doesn’t work because like they didn’t match up. Okay, now we’ve gotta plan and do it all again. So it’s three months late, right? Again, somewhat extremely, an extreme example, but there’s a cost to fixing these mistakes, right? Yeah. It’s a cost.

[00:27:36] Janna Bastow: Yeah. The quarterly thing is absolutely true. The fact is that teams start at the beginning of the quarter, they said, “This is what we’re gonna do,” and then they regroup at the end of the quarter saying, “Great, how did we deal on our OKRs?” And they all went off and they did different things [laughs] and they repeat every quarter. 

[00:27:51] Simon Cross: There’s a lot of kind of controlling for outcomes scenarios here, right?

 Someone’s just said in the chat, like a QA mindset. Yeah. The, the old Reagan doctrine of trust, but verify, check-ins along the way, all of that good stuff, right?

[00:28:05] Janna Bastow: Maybe someone could enlighten me. What do we mean by a QA mindset? So is that having a testing mindset, like thinking about, 

[00:28:14] Simon Cross: I’m assuming so from that, like you, you’re testing along the way. Yeah.

You know between now and, the thing that we agreed to meet on, what can we do to make sure that the thing that, the other team is doing is serving the needs as we go, right? There’s loads of classic, product management and project management techniques for that.

 I think an interesting approach to this in technical teams that I’ve seen work when think about extreme clarity which is the kind of the communication thing we’re talking about here. One thing I’ve worked well is things often break at the interfaces between teams, between people, between products, between technologies, the interfaces, which are often the thing. And when I’ve been working with more technical teams, one of the techniques that I’ve seen work well is define the interface first. Like, how is this thing gonna actually work? How it… How the interface… All of the stuff before and after, we’ll figure that out later. But the… Let’s design the interface which could be down to the specific where the API call works, or the URL format, wherever it is from a technical perspective, but let’s get that and then the teams can go off and figure out how to tunnel towards the outcome. But in terms of extreme clarity it works. You’ve got a document or something which clearly defines what was, what was expected. And so if team B provides something that doesn’t meet that kind of agreed spec, if you like, then we can say we agreed this here,” right?

 And I think extreme clarity is about… It’s about documenting or often it’s really often documenting documenting things, what’s gonna happen, when, who’s gonna do what is the artifact that, that is produced. I- I’ll give you another real quick example. One of the teams I used to work with used to say “Teams often have something their OKRs like Lambda a strategy around X,” right? Okay. What does that mean? You don’t land a, you don’t fly a strategy into Heathrow, right?

 [laughs]

 Are you able to land a strategy, right?

 I don’t know two people could have different opinions about whether or not a strategy was landed successfully, right?

 We presented it to the exec team. Okay has that strategy been landed? I don’t know. You’ve presented it to the exec team, sure. But they might have hated it.

 [inaudible 00:36:52].

[00:30:35] Janna Bastow: That sounds very output focused, right? Like presentation done [laughs].

[00:30:38] Simon Cross: So how do we, so how do you… Again, extreme clarity. How do we define that, like a thing has happened? Another quick example, teams would say I used to work with this, actually this happened pretty recently. A team said ship thing that did X, right? And like with my extreme clarity hat on, again, sounding like a pendant, I’m like what ship? Okay does that mean the code is on production? Does it mean it’s in the, is in the repo? What does it mean to ship?” So a much better extreme clarity version of that OKR was to say, greater than five users have X.

 Because boom for that actual outcome to be true, all of this other stuff has to happen. Yes, it has to be on production. Yes, it has to do something that’s visible so that enough people have done the thing. I think that’s just extremely… It’s much more extremely clear.

 I’ve seen… Yeah, I think that level of clarity might seem like pedantry, but actually it really helps.

[00:31:42] Janna Bastow: I think you’re right. A lot of good product management is about being pedantic about things. Look at the language that we use around experimentation. It’s about being highly specific about what the hypothesis is and what the outcomes are and how you’re gonna measure it. You’ve gotta be really specific about it. And you’ve got to communicate that upfront before you get started, before you even begin thinking about cracking code. And then at the end of it, you write it up and say, “Okay, this is what we expected it did, and this is what it did do.” it’s the art of pedantry and it works, right? And this is why teams who are very experimentation minded do because they’re able to communicate before they start what they’re planning on getting out of it.

 Yeah. In any association.

 So are there any rituals or favorite questions or tactics that you employ to get points across or pull points out of people in in your teams?

[00:32:32] Simon Cross: So I, there’s a bunch of like very general questions that I like to ask that kind of force the right discussion. One of them is like, how do you know if you’ve been successful?

 It’s just such a real basic question, but, like, how do you know if you’ve been successful? And they’ll often give you an answer which isn’t clear enough, or just asking the question makes people realize that there’s a definition of success that they haven’t thought about- yet, right? Something like that works. In terms of techniques for helping a team up, or a team or a person up level, their communication. So one of the things that I’ve done that’s worked successfully is again, this is gonna sound like a little bit of pedantry and some of the PMs that have worked with me before might remember these times. But again, back at Facebook, when we’re writing communications to senior leadership the quality of the writing is really important. You’ve gotta remember that your your execs or your senior people, your email is like 15 to 30 seconds of their day maybe. And the thing you are writing about is, writing to them a narrow part of this much bigger picture.

I think one of the things I learned by watching some of the best people, the most senior people at Facebook, is how good they were at that level of communication. And when I tried to think about what it was is they were really good at distilling something complicated down, to like its absolute essentials and leaving no room for maneuver in interpretation. And a bunch of the PMs I used to work with just weren’t good enough at that, a blog post about this that has an example on it.

And one of the things I used to do with the PMs of mine that needed some help is okay, number one, just put your email into a Google doc, and then we’ll sit through it together and a subedit or a newspaper and like literally go through it and read it with an out external mindset and just go through it line by line and be like, “What about… What did you mean there? What did you mean there? Did you mean this or that?” And that exercise, they begin to learn just as I did. I had to learn this stuff, right?

 They begin to learn what are the common things that they wrote down, which made sense to them because of their context that with that somebody outside of the contextual space, it just didn’t make any sense to. So going through that process a few times, those PMs like, the first time I found kind of 15 things that I didn’t understand, and the next time it would be one or two and boom after that they’re like, “Okay, I know how to write like this now.”

 I think again, communication like this, when you are communicating to people outside your contextual space, particularly across time zones, like when, if they have a question and you are asleep, that’s bad right?

 [laughs].

 Just think about it. If… Think about this in kind of internet latency terms. If there’s a 100 milliseconds between, the request and the response but if you may need to make 10 requests and 10 responses, 10 times 100 milliseconds. But if that is a second, and you have to make 10 of them, it’s a lot worse, right? A lot worse. And when you’re working across time zones or with, across asynchronous teams who may not be working at the same time, then if you’ve got a miscommunication or a mistake in communication, it can really hurt you, and if you can avoid that because you communicated clearly and crispy the first time, then you actually save yourself. Honestly, sometimes days weeks.

[00:36:23] Janna Bastow: That’s a good way of putting it, that, that thought about latency. And you mentioned a blog post a moment ago. Send us a link to that afterwards, and we’ll send it out to people and we’ll include it in the the show notes as well, so people get those. We do have some questions from the the audience here, so thanks for sending them in to the Q&A section. Taylor’s got one, which relates to what we were just talking about here, is just how do you balance extreme clarity without overwhelming developers with context content overload? 

[00:36:49] Simon Cross: Great question. It… I guess the answer is communication is about knowing your audience, and not everybody needs to know everything. And I guess like extreme clarity doesn’t necessarily mean content overload. You can be clear and being and concise. And often, thinking about audio as a signal processing kind of analogy here, it’s about which things do you need to communicate to that audience? If you communicated everything to every audience, everybody would be overloaded.

 But like, when you’re communicating up, you need to understand what your the receiver wants and needs to know. If you’re computing sideways, it might be a different set of things. So I think clarity, extreme clarity isn’t about trying to over- overload people. It’s about trying to reduce ambiguity, right? It’s about trying to communicate in a way that two people don’t have, have a different understanding of what’s being said. So yeah, I think it’s about your audience versus, yeah, knowing your audience and communicating what you think they need to know.

[00:37:56] Janna Bastow: Yeah. All right. Good stuff. There were a couple questions here that related back to the the currency that you were talking about. Tom asked, when you try to create a common currency, how do you stop people trying to game the system?

[00:38:09] Simon Cross: God dammit, yes.

 [laughs].

 Everybody games the system.

 Smart people their job yeah. You think about, man, especially in a large company or where you’ve got lots of teams with different incentives, they are gonna gain the system like that… In fact, that’s their job, right? Their job is to succeed within the constraints that by then it’s like a game. So the answer is like guardrails, is the short answer, right? Guardrails. So what is the set of things that you- you’re gonna do X. What is the set of things that will prevent you doing X without breaking Y?

 I can give a very clear example of this actually. So the, one of the teams I worked on at Facebook, their job was to reduce harm, right? But one of the challenges when you’re reducing harm is the scale of your false positives, right? At the limit you could take down every single piece of content on Facebook. Yay, no harm anymore.

 You’d have caught all of the scams, you’d have caught all of the, porn. But I don’t… I think we can all agree that’s a bad idea. So then your question is what’s your guardrail? What’s the thing that stops you doing that? And so teams like this often take goals or counter metrics on things like false positive rate. So for example, you can increase your recall as much, your goal as in Integrity teams, is increase your recall, take as down as much bad stuff as you can, but then you set a guardrail of your false positive rate must be no more than 1%, speaking the numbers out here. Then boom, you’ve got an operating parameter that you can’t break.

 So you can gain the system if you like, by doing as as well as you can, but the system has a counter metric in it to prevent you doing something inappropriate. So I think like gaming the system is that’s one answer to it.

 Yeah, let’s say that’s one answer to it. 

[00:39:59] Janna Bastow: That’s really good insight. And there’s another question that that was related to the the currency as well. Earl asks, how does annualized MAU monthly active users interact with must-do tech debt type projects? Does it work for that?

[00:40:14] Simon Cross: So first of all, I’m wrong. I’m not suggesting that annualized MAU should be a common currency for every project, right?

 It’s just an example.

 But the general question goes, which is I think, if a, if your team or your business or your product cares about X, whatever metric X is, then how do you handle things like tech debt projects? So there’s a couple of ways to cut this. The first is, I think, often tech debt projects are, have measurable business impact in ways that people don’t often realize.

 So for example one of the things I worked on a while back was like webpage performance for something. ’cause our webpages were slow. And initially, the team were framing that as, we just need to get just websites just too low too slow. We just need to speed it up. Like we have all this tech debt we need to do to speed it up.

 We need to get rid of all this stuff. We need to refactor this, that, and the other. Turns out that making your webpages faster is good for business.

 [laughs].

 It actually… They found a way to frame the impact in a way that laddered up to a business objective. And boom, what was originally a tech debt project actually became something that could be valued in a business sense. So a product or a business sense. Not every tech debt project is like that. And there are some that just need to be budgeted for.

 And in this case, you just need to align on what a reasonable kind of budget is for that kind of work. Facebook, they had this thing called better engineering.

 And they would reserve kind of 10 to 15 percent of every team’s roadmap for better engineering work. It just wasn’t a question it was just like, we’ve agreed that we’re gonna budget this amount for this kind of stuff, and we’re gonna go do it. Because not every- everything is accountable. Is translatable into kind of a, into a common currency like that.

[00:42:10] Janna Bastow: Although I would argue that there are ways of translating it into things that are important to the business. People often think that tech debt is just the domain of the CTO or the tech team is their problem and they’re left to it. But ultimately, it’s good for business in a lot of ways. Not only does a faster webpage mean that people can actually, get their jobs done faster and therefore you get more activity and more sales or whatever you’re trying to get. But also reducing tech debt means that your developers are able to work that much faster. They’re less likely to quit their jobs ’cause the code sucks, right? Like, how… You don’t have to refactor the whole thing in every two years like your competitors are. So you’re able to move faster.

 Half the things that companies aren’t paying attention to, they’re very shortsighted. But if you can make those arguments, then it can take you a long way.

[00:42:56] Simon Cross: Yeah. So actually, so let’s zoom in. Let- let’s imagine you’re a technical project or product manager, and you say, “Oh,” im- imagine this hypothetical thing. Our CEO, CTO says we have 20% of our budget time to spend on better engineering projects.

 Guess what you need to do? You need to prioritize them, right?

 So team A is doing… Wants to do… Person A comes up with better engineering project X team person B comes up with better engineering project Y. And like one might be refactor this spaghetti piece of code. This one might be upgrade to the latest API, whatever it is. And like, how do you trade off those things? Guess what? Maybe you need a common currency. So more technical common currencies. Might things be like CPU, load, or page load speed or latency, or some other kind of technical thing. And again, one of the things I worked on at Facebook was a period where we were working on efficiency efficiency of our systems, ’cause they were costing a lot of money to build and maintain and that was preventing us working on new things, ’cause there were real constraints when you’re operating at that scale.

 And we found a common currency for how to judge multiple types of efficiency work. And you could then just like in the annualized MAU example, you could trade off, and you could have a really simple framework for we’ve got these 20 ideas. What are the top five? Or do we think the impact would be on our common currency? Let’s go with those. So the common currency thing, I think is it’s fractal, right? It works at the company level, organization, team level, even project level.

[00:44:34] Janna Bastow: Yeah. And somebody actually has a great question here. Anonymous. This might be saying something here. Have you, do you have any tips for managing up as in how to coach those who sit above you on the corporate product manager ladder to communicate more clearly?

[00:44:49] Simon Cross: Ooh. So does that mean how to coach the people who sit above you to communicate more clearly down?

[00:44:56] Janna Bastow: I imagine it’s how do you coach the people who sit above you with their communication?

 Both ways, yeah.

[00:45:02] Simon Cross: Both ways. Okay.

 Yeah. Okay. So I gave you an example earlier of how I’ve coached people on their upward communication. It’s I like to, I, I was in a position here where my, one of the PMs on my team was pre- was presenting a strategy to a VP. And I’m their manager and the VP’s my manager, I don’t wanna be presenting, I want the folks in my team to, to have access to that level. And so going through their emails or their decks with a fine tooth comb, thinking through, with my experience or the experience around me of like, how to make this super tight. It, it just takes practice of going through, reviewing something with a level of detail to understand, what could be improved.

What I would often say to, someone is “Look, you know this. Just think about the difference. You are the PM for X,” right? And then you are presented to your VP who’s two levels above you who’s org, you might be PM for team of 12 people. They’re a VP of a team of 4,000. I would just say imagine their day. [laughs] Imagine what their day looks like. Imagine their calendar, right? And you’ve got 45 minutes with them on a Tuesday. What’s the rest of their calendar look like across the week and across the day? Think of the breadth that they have and how little context they’re gonna have in your space. And when you get into that frame of mind, you can start to, to read your own communications through the lens of someone who’s quite different to you.

 And then you start say, “Oh they’re not gonna know what that acronym means,” or, “Oh yeah, they probably aren’t gonna remember what we decided at the last meeting.” so as a result, what started to happen is my folks would, A, do things like unwrapping acronyms. B, we’d put often a glossary slide in a deck so that people had somewhere to go. And every deck or every doc we’d summarize a TLDR at the top. I think teams are really, people are often really bad at this. Let’s imagine you’ve got a 12 slide deck. Oh, people can read this 12 slide deck, can’t they? No.

 [laughs].

 What is the TLDR? What’s the TLDR slide for your 12 slide deck? And no, you are not allowed to use size 12 font, right? You’re only allowed to use size 20, right?

 At the most. Don’t shrink it down. Shrink down what you are trying to say, distill it. I really like presenting index as a form of communication, not ’cause I like to stand up in front of an audience and click click. But a document, a paragraph can be an arbitrary length in the document. A slide gives you a frame, right?

 You’re limited by how much you can get on it. And I think that often helps people tell a story by chunking their narrative up into multiple sections. That’s upward kind of communication. Like basically it’s just reviewing it.

 And explaining the con- context of who you are communicating to.

[00:48:03] Janna Bastow: That’s great.

 I’m conscious of time because we’re just about running outta time. But I did wanna finish with a final thought, and then a final question for you as well, Simon. I do recall a time that you said on the Mind the Product stage that the stories that product managers tell each other have had the most impact on honing your craft, the stories, the successes and failures, the surprises, the left the field, things that we find, the personalities that we encounter. And that one really stuck with me because this is what we’re doing here, right? It’s about learning from fellow product people and sharing intel sharing with each other as we go.

I thought it’s really cool to get you on here to talk about your experiences and have you share your insights, so thank you. And I do wanna finish with a final question because your advice when you closed out on the online product stage was that people should be reading more broadly than we ever thought possible. What are you reading these days? What sort of books do you recommend for product people?

[00:48:59] Simon Cross: Ooh, I’ve got… It’s a very long list, but there’s a few I keep coming back to, I think again and again. So like one is Good Strategy, Bad Strategy, Richard Rumelt. Holy shit. That’s good. [laughs]

[00:49:11] Janna Bastow: yes. I recommended that to somebody yesterday [inaudible 00:58:13].

[00:49:13] Simon Cross: Every time. Another one is like radical candor.

[00:49:17] Janna Bastow: That was the second of my list that I recommended. Somebody asked me how do I best connect planning to or strategy to planning? I put those two in. Cool. I’d love to hear if there’s any others. But those two, yeah, double down on

[00:49:29] Simon Cross: Another one that I’ve read recently that I just think is go back to that, the talk I gave. I think a lot of the books I like to read are the stories of, I don’t read all that much fiction. I like… I kind read the stories of people and the things they did. Because often, for them to write a… For a book to be written about the thing, it was interesting, right? One of the, recent ones I’ve met was read was American Prometheus, which is the kind of biography of Oppenheimer. And if you’re thinking about product management like it’s outcomes. It’s like what is the problem we are trying to solve? Who are we trying to solve it for? How do we solve it? And how do we know we’re successful?

And the story of leadership through that kind of a journey. And I think the Oppenheimer story and the Manhattan Project, just like Apollo, just like a whole bunch of things these are stories of people that did incredibly complicated things because they had a clear outcome they were trying to reach, but didn’t really know how they were gonna do it. And they needed the close cooperation of tens, hundreds, thousands of people. And I think I like reading those stories ’cause I think there are little lessons in them always that I can take back to my own team or help my own PMs understand, ’cause yes, we’re not building often things like that.

 But there’s always lessons for goal setting, communication and leadership in those stories.

[00:50:56] Janna Bastow: Excellent. That’s really good insight. Thank you so much for sharing. And thank you everybody for for joining in. So with that, once again, Simon, thank you very much. Everybody say a big thank you to Simon and a big thank you for me. Great to have you here.

[00:51:09] Simon Cross: Thanks Jenna. Thanks everyone for joining. I hope you found someone wise said useful.

[00:51:13] Janna Bastow: It absolutely was. All right, wonderful. Thank you. Take care. And bye for now everybody.