(gentle upbeat music) - Good morning, everyone.
Thank you very much, John, for inviting me to speak here.
And let's get started.
So, as John said, Hi, I'm David.
And I'm based in New York City.
I live in New Jersey, but I work out of the Google office in New York City. I was gonna do a whole joke about working for, I work for a small company, you might have used our products, but I think the cat is out of the bag on that one, and I'm a Product Manager.
And what it means to be a Product Manager and especially to move between companies is I just have and move between teams is really the theme or the topic of this talk.
So I think, I ask a real softball question. Who here is pretty sure they understand what a Product Manager is and does? Oh, that's great.
I was really hoping it wouldn't be all hands up. 'Cause I was thinking a lot of people in here are gonna be all, Yes, I understand.
But by and large, when I ask this question to people is including, or maybe especially other Product Managers, the answer is a little more like the shrug. And this is something that's been very much on my mind for a few reasons.
One, having just moved from Adobe to Google, which has a very different product culture, having to re-establish myself on a new team. I've actually already been in two different product roles at Google since I started for reasons you can ask me about later.
It's all positive.
But those two teams also had very different product cultures.
And so every time you change from team to team from role to role, even if your role escalates from a mid-level or like entry-level to a more senior role, the circumstances of the job can change dramatically. So really, begs the question, what does a Product Manager do, anyway? This is really an existential crisis.
Because if you think about career development, you have to understand what it is that you do, what it is that you have done, and will do, and be able to put all those things into a narrative and it's always easier to do that if people have a frame of reference.
If you're an engineer, you can say I worked on projects of this scale, and then of this scale, and then I lead teams, and so on and so forth. With product, it gets a lot more complicated. Not at least the fact that, at least at Google, I don't know about your companies, but we generally don't have Product Managers manage other Product Managers until they are quite senior. So that very shortcut path to demonstrating growth and development is not really available.
One of my Google colleagues, Ganesh Shankar kind of posed this question and talked about it in a medium post.
I didn't put any like Go Links or Bitly Links or anything on these slides.
You can Google it.
This is my way of getting you to use my product, or one of my company's products.
And he put it, framed it really nicely.
It's something I can relate to a lot.
The questions you might get at your child's birthday party or a dinner party, or I actually got this at a rental car place where someone looked on the receipt saw that it worked at Google.
They actually asked the question that is more embarrassing for a Product Manager than what do you do, which is, are you an engineer? Which gives me a chance to say, no, I'm a Product Manager.
Oh, what's a Product Manager? I don't know.
So Ganesha offered a few of the answers that one might give or that he has given.
One, "I figure out what we should build next." This sounds really impressive.
This sounds like a role with a lot of power. We know that it's more complicated than that. But if you had to give something that's just really glib to someone at a rental car place or at a party, this one is probably fine.
There may be follow up questions.
"I'm a meeting and email shield for the team." (laughter) I have problems with this one.
Not least because I like to work on teams where there is nothing so scary in a meeting or email, or where people are able to manage their email well enough that I don't have to shield them from anything that this is work that I don't have to do.
I have worked on teams where it probably would have been helpful to shield some meetings and emails so this is really highly contextual.
"I represent the user's needs for the team." This one is great.
This one's great.
It makes me feel like Tron, I fight for the users. Here too, it's a little more complicated than that. And especially it's one of the things that works or plays a little bit better outside of the technology space than inside because once you're inside people can point out, "What, are you user researcher now?" At one point I was talking to someone who was doing a lot of programme management and user research work for adoption of Chromebooks in the enterprise space. And I described what I was trying to do to study adoption of Chromebooks in the enterprise space.
And her answer was like a dead eyed, "Your job is duplicative of mine.
"Why are you here?" I didn't have a good answer.
"When times get tough, you bring the food or worse." I won't dwell on this one too much.
But I think we've all heard stories where people, you'll ask someone maybe a more senior PM, what it is that you should be doing.
And the answer is, whatever it takes to ship the product. If someone needs network cables strong, that's what you do. If someone needs you to pack a suitcase for the engineers that they can spend more time coding, that's what you do. My take on this is, one I'm not somebody parent. These are all paid grown professionals.
And also I really like to be more on top of projects such that people don't need me to go around and bring them food or pack up their suitcases. But I'm sure I've worked in situations where this was warranted.
And then the real answer, "It depends." Okay, so this is the one that really is, the existential crisis 'cause PM roles are very often defined by the relationship to other people's jobs or maybe not defined so much as, this is one of the easiest ways we have to talk about them. I'm sure we've all seen...
Who here has seen some version of this Venn diagram? I expect a lot more hands.
Okay, not all the hands though, so I get to explain it. So, it is for probably the whole history of software product management, it has been said that the role exists at the intersection of this Venn diagram between these disciplines UX, which may be called design tech, which may be called engineering and business which is usually called business. First of all, PM is often a business-y role. So it's a little bit disingenuous to say this is other thing, but I think what they're referring to are marketing, they're referring to sales, they're referring to the kinds of very prosaic customer contact not the exciting Tron-like customer contact that PMs have, which is actually no different. But anyway, so this Venn diagram gets a few things right. So before I spend however many minutes shitting on this Venn diagram, I want to acknowledge the things that it gets right. First, it does illustrate something very important about successful PMs, which is that we need to be generalists.
Engineers, designers, especially the various subtypes of designers or researchers have the luxury of being able to specialise and become extremely masterful in their particular chosen discipline.
PMs often come into it with the baggage of having mastered one of those disciplines. I for one, I'm a very accomplished web developer. And it is often very tempting when we're saying we need an engineer to work on something for the web, for me to come in and say, Oh, I can do it. Wrong answer.
A PM should not be in a position where they have to do any code because there's usually no time to actually commit to that and provide the same level of focus that an engineer would.
Whereas the ability to not only interface with people who are writing code and doing design but to interface with all of it and have a good sense of everything that is going on is a perspective that many on the team would lack. Second, it does show that PMs are in the middle of a cross functional team, which as we'll get to later really implies their value, that not only being people who can speak to all the points on the graph, but being in the middle of it creates an opportunity for facilitating.
But at the same time, it doesn't say anything about what the PM does.
It just really says where they are.
And that gets more complicated by the fact that, teams are not shaped all the same way.
This graph, these may seem like I'm just trying to, make the spheres bigger to make this seem more complicated but you might be able to relate to some of these types of organisations.
In particular, I'd say this one describes Google quite well. We have something like a...
I'm just doing my little gut check, are these numbers public? Let's just say we have a very large number of engineers, and a much smaller number of designers and Product Managers and everyone else.
We are very technically focused company.
And that's actually one reason why one of the quirks of Product Management at Google and one reason why it can be difficult for us to hire people who have a design background, or any backgrounds that are not highly technical, is that because so many of the engineers are doing very highly technical work where the stakes are, or the technical environment may be unlike any other company is, if you bring someone in who has no technical background, they might have difficulty communicating and being successful.
So we tend to hire very technical Product Managers, or art school weirdos who also really love computers. This one is the one that I think might seem like a magical unicorn that doesn't really exist. I actually think it describes agencies quite well, where, especially if you look, take the whole thing and make it smaller, I worked in environments where there were several designers, and maybe only one or a very small number of engineers who are responsible for doing all of the implementation of that work.
So you had very happy designers, and very stressed and overworked engineers, and maybe one or two business and sales people in there who were just like, "What the heck is going on?" This one is more common and I think we all would like to admit.
This is, I'd say the organisation where you have a lot of business people going around making deals, crafting marketing campaigns, deciding what's the most business advantageous promise you can make to the market, and then just like foisting it on the technical and design team to make it reality.
With PM, you'll notice I left some daylight here between the UX and tech spheres and business, with PM is kind of the bridging layer between the two. Yeah, those are fun PM jobs.
So to make matters even worse, (chuckles) PMs are often not right at the centre of the space. This is probably describes me very well as like a technologist with UX background.
And I think a lot of PMs come into the discipline in this way where they either start as designers and move more towards technical or start more engineering and move towards design and are really focused with the ideal crafting of the product, but maybe are weaker in some of the other aspects. Here you would see like Uxers who have a business background, or business people who are very concerned with design and user experience.
For likewise, you might have technical people like engineers or engineering managers who go and get their MBA and this is their pathway into senior management. A lot of people, including I think, the current CEO of Adobe, started from an engineering background, went to business school.
Their first job after that would have been a Director of Product Management, even though they're not coming from the design background, but mainly being focused with the technology and engineering and then rise up through the ranks.
I'd say actually, of executives, this is probably the people you're gonna find most in tech companies are ones who are more familiar with the business and tech aspects and less so with design.
Not unaware of design, but just less so.
And all of these points in the space are valid. So what is it the PMS do? How do we describe, what is our function and what are some of our tasks and what should we be doing? This too becomes a complicated question because there are so many things that people who are titled as Product Managers find themselves doing.
And it is unreasonable to expect that any one of them is doing all of it.
It's also I'd say, unreasonable to expect that every PM role needs all of these things. But because people have different experiences and understandings of the role, you can have a real mismatch of expectations, which leads back to the existential crisis. Expectations of PMs, roles and the individuals that can vary from team to team or even person to person. And this leads to awkward situations where someone will be wondering, where, for example, is our vision statement, and expecting the pm to work on that, and someone else thinking that they should be organising the backlog. And both of these things need to get done, and someone needs to do them.
But is there a shared understanding that one particular Product Manager is responsible for both of those things? And is that person the person for that job? People have experiences with bad PMs, which can make it hard for new PMs to establish themselves.
I've heard of people in organisations, I won't name names who basically PM has gotten a bad name in that organisation. So even though they keep hiring and staffing Product Managers, no one listens to them, because they think Product Managers do a bad job. And I think this really does stem from these mismatched expectations.
But these fester, 'cause no one really has the conversation, like, do we understand what we want out of product? And are we getting the best value out of having these people around? Are we just sending them off into a corner to make plans that we will then ignore? Lastly, the reason why this is a problem, I think, what makes this a really practical problem and not just like, no one understands me, I feel disaffected.
Like, Grunge in the 90s.
This makes moving between jobs and building a career out of Product Management a lot harder.
As I said earlier, I've moved already between two jobs at Google, I just moved from Adobe to Google, and I've had to adapt and re-establish myself each time. If I move to another role, or if I move to a more senior level in my current team, I will probably again, go through a period of at least six months where I'm having to re-establish myself and six months out of a career, especially when you have like your prime time of trying to, get up the corporate ladder before you turn like 40 or 50 and people stop listening to you, I generally like to make the best use of my time. So that's not a very comfortable thing to have happen. So in addition to the slower onboarding, slow job satisfaction and stalled career growth, there's a lot of negative things in your mental and career health that can come out of this. So what do we do about Product Managers not knowing what Product Managers do? Maybe framed a little more positively.
How might we better understand and explain the craft of Product Management? What's the things about the job that we can take with us from job to job and explain better about what it is that we do, so that we can have more productive conversations about what people expect of the product role.
So, a little background.
So a few months ago, there's a American website called 538 that mainly covers politics, but usually through a very nerdy infographics and statistical lens, I love this website.
And they did a post a few months ago where they took all the different attributes of, I don't know if you're following the US presidential election, but on the Democratic side, we have something like 20 candidates, and several of them, in terms of their appeal to different groups or some of their policy attributes really overlap. But it's hard to really understand like, where is a Elizabeth Warren versus a Beto O'Rourke versus a Marianne Williamson.
So they've made this graph.
It was a Pentagon where each corner represented some key facet of a candidate's appeal.
And they made little shapes that were, give you a sense of how the candidates were similar and different. So it was really nice graphic and I look at that, and being very self absorbed, I immediately thought this could be a really good model for explaining my job.
So this is the infamous product polygon.
It's probably more of a product pentagon, and it has four corners, each of which I think is a key facet of the product role. First one is strategy, and I'm gonna go in depth on each of these. That's basically the content of a talk.
Execution, storytelling, domain knowledge, and leadership. And to illustrate what I was talking about earlier with the different shapes of Product Managers, I would say like the ideal associate PM, someone who's perfectly balanced and fairly early in their career, you can look at each of these corners, like the closer you are to the centre is less skilled or less experienced, closer to the edges is more experienced, maybe even masterful, you might even say getting all the way to one of the corners or the edges should be uncommon, maybe even impossible.
And you could really just rank yourself on each of these dimensions to say, Where are you relative to the corners or the centre? And come up with your own, the shape of your own aptitudes of product, which gives you a nice framework, I think for also understanding where you need to develop where I think if you wanna be well rounded, you wanna go for something that is evenly shaped, and maybe as large as possible, but if you're more entry-level, you're probably starting close to I wouldn't say zero but let's just say like a little bit of baseline understanding of everything.
The ideal mid level PM would be a bit larger. But not everyone is going to have the same shape. So here's a hypothetical PM named Andrew, who is very charismatic and strong and carrying on leadership, very strong on their domain knowledge, maybe a little bit less so on the storytelling, and the communication and the strategy piece, but very, very strong on execution and follow through. Parvati is a PM, another hypothetical PM, who's also a very strong, even stronger leader and a great storyteller.
Pretty normal on execution, but maybe lacking in domain knowledge and strategy. This might be someone who's a really strong PM who has just moved into a brand new space and has some learning to do.
And I think one thing that I've found, just as a side observation, the strategy and domain pieces probably tend to move a bit in tandem because you might come into a new space, not understanding it very well and not knowing what strategic plays to make, and as you learn the space better, your sense of strategy for it will also improve. Another one, Connie.
This is one that's very close to like a normal polygon, but with one point in another direction.
Very deep and domain knowledge, knows the space very well and consequently is very good with strategy. On some of the more technical aspects of product management, leadership and execution and storytelling, some development that could happen.
So let me start going into each of these a little bit in depth.
This is probably the closest I would say, if you ask like this is not very resonant at a kid's birthday party but in the same way that an engineer is a code specialist, a designer might be a pixels or wire frames or user flow specialist, PMs are strategy specialists.
We identify a win, whatever that win may be for your team or your product, and the path by which the team can reach it. This is really the chest-playing aspect of Product Management.
This is a tweet from a few months ago.
I love this tweet.
I've never seen it felt more seen than when I read this tweet by Jessie Frazelle, who is a engineer who's worked at Google and Microsoft and GitHub, and does a lot of work in the operation space. She wrote that, "Product Managers are actually just "connecting-dots engineers." And I feel like a lot of what I do, in various forums, is connecting dots.
Not only actually connecting them and saying like, Well, I think that taking together all this information means da da da and then explaining that to the team, but also demonstrating how the dots connect and explaining the logic.
On the topic of like, what is a win? Like, what are the dots that we're connecting? What is this product that we're supposed to manage? This is a quote, I think, from a few years ago by Hunter Walk, which is a he's a VC and he was formerly a director of PM at Google. And he said this in, this is actually one of the crisper definitions of Product Management that I've read recently, in the General Assembly blog, that, "Product Management is helping a team build a product "that's loved by the community." And I think the, loved by the community piece is really interesting because for me, not that I mean, we all want a product that's loved by the community, but sometimes being loved by the community is not sufficient as a success definition.
It's one of the more emotionally satisfying ones 'cause we want to be loved by the community. We all wanna work on something that's loved by the community.
But we sometimes need a more nuanced and maybe more boring view of success.
So loved by the community is one, but it could also be meets users' needs, maybe you're working on something that's much more just useful and pragmatic, more of a utility.
If you're working on more of the growth hacker form of Product Management, your definition of success might be very quantitative, and may be very based on revenue or conversion. This is something, there's a product called Superhuman that's been a little controversial lately, because of some stuff they're doing with privacy, which is makes it really complicated that their CEO posted one of the best articles I've ever seen on product-market fit.
Because what got them into this world of shipping a feature that had this privacy issue was trying to really optimise for the experience of their most adept, most power user users. And they did this by running a survey asking, what percentage of users or which cohort of their users would be very disappointed, not a little but extremely disappointed if the product went away, and they had to stop using it? So their definition of success was growing the number of people who were these fanatical users.
That seems to maybe have led them down a few dark paths, but as a model, maybe leavened with some different approaches, I think, is quite reasonable, and quite interesting. At Google, we have a lot of stuff going on that's not just focused on building software for the sake of the consumer market or the business market but also actually, this always feels, especially after the show "Silicon Valley" and all the silly things where people were like, "I'm optimising cloud metrics performance "to save the world, or to change the world." At Google, we actually do have some projects that are trying to change the world, including things with life sciences.
So your success definition might be reducing world malaria cases or some other epidemic or social problem by a quantitative percentage.
And then finally, we talk a lot about moon shots, especially at Google.
I love to think about moon shots in terms of a product success statement, "Land on moon and safely return." This one is binary, this would actually make a really good OKR. You either hit it or you don't.
And if you don't, someone is lost in space forever. So, some of the tools of strategy is analysing the product space, which may be ambiguous.
I do a lot of interviews lately, like Google is like a machine that runs on people. So we interview and try to hire a lot of people. So I spent a lot of time interviewing new PM candidates. And one of the things that we look for is thrives in ambiguity, which I always find funny because I think the goal of product management and really for a lot of people in Google is to thrive in ambiguity by attacking it and just reducing the ambiguity as much as possible which I think is actually the one of the primary jobs of product management is not just to be happy in ambiguity, but to try to make sense of it and to create structure were structure did not exist.
From that, identify possible wins, like the statements that are on the previous slide, like whatever is the most contextually appropriate win, and maybe also the most available win because sometimes you might identify a five-year vision that you need to take some steps to achieve. And sometimes those steps may not be tenable, and you need to find like, Okay, well then what's the next best thing we can do? And look at the whole board and look at all the possible routes to success. From that, choosing the best path to the best win for your team.
As I just said, sometimes the optimal condition is not possible if you look at all the other factors. So you need to take all that into consideration and say here is, for example, a three-year roadmap or a three-year vision, each step of which should be feasible given certain conditions.
And here's why I think that it is important and this may be the most important thing for a PM to have buy in and credibility is to show your work, which might even just be as simple as explaining the logic and the reasoning to someone who doesn't live inside your head.
One more quote here on this one, this is a friend of mine who's a PM or an editor at a games company.
She and I were talking and some other teams were talking at a chat room recently about product road mapping in particular.
And what is the purpose of product road mapping? And I think she had a really good framing for this. That was, it's not about outlining what is your execution plan, what are the tasks and the things that you're trying to deliver, but it's actually a storytelling device to say, here's how we might win and here's the steps that we might take to the win. And there's a lot of things that you might do like when you're making these strategic decisions, you do have to make trade offs, usually involving resources, and the biggest resource we have is people's time. So do you wanna spend some time investing in a game store like Steam, if you work in a games company, on your own website, you want to build out your own e-commerce capability? Do you wanna go one off versus subscription? All of these things involved trade offs, usually cannot do all of them.
So you have to pick which one is going to be optimal, do the work to establish what that means and whether it is a good use of time and then call the play. Alright, so that's strategy.
Moving on to execution.
So this is one of the things I think is poorly understood. And sometimes like, honestly, it might depend, this might be a conditional statement.
This might really depend on the team.
Product Managers are not necessarily project or programme managers which to give an example of how not understood this is.
One of the engineers on my team recently, we had a welcome email for a new Head of Programme Management. And so one of the engineers as we were walking in was asking like, "Hey, I saw this email "that we have a new Head of Technical Programme Management "starting, so what does that mean for your job?" And which is kind of out that like, that's a programme manager, not a Product Manager. So it really doesn't mean anything for my job other than I'll be working closely with this person, and I think they're great.
But because all these titles start with P, and because they aren't very well understood, it's very easy for people to see one and think of the other. And also making this worse, Microsoft has a Product Management function that has since forever been called Programme Management. Like if you see a resume from someone who was a programme manager at Microsoft, they probably were actually a Product Manager. And I've actually heard of people who got hired as programme managers at other companies from Microsoft started the job and then realise, Oh, this is the wrong job.
You put me in the wrong job.
So this is really all to say, we aren't project or programme managers, we are not the people who necessarily are responsible for getting the execution and making it happen. But the reputation of a good PM is that they get things done.
So we're not responsible for any of the actual work, the code or design, we're not project managers. So how is it that we get sh*t done? And the answer is that we have more of a coaching role. We are the ones who can stand on the sidelines and help the team achieve their goals, whatever those might be.
So, from the strategy piece, we're often responsible for helping define what those goals are.
We're responsible for maybe outlining the steps to those goals, but we're also there in the thick of it, helping people day to day, keep their attention on what those goals are, and helping them execute.
So a few of the ways that we do that, or especially that I have done that, probably the biggest one, I'd say, one of the most like regular day to day functions that I've had as a especially as a line Product Manager, less so as I moved into being more of a Head of Product is managing priorities and scope.
And this can be really, really pedantic.
This can be the I would call it JIRA jockey, form of Product Manager, where you are just sending all the information and doing all of the documentation work in a tool like JIRA. But it can also be in a product requirements document or a wiki page, and the most important thing is identifying what are the most important things to do and what are things that we are not doing? Because one thing I found on every team I've ever worked on, is that if you make a list of the things that are very important, they will imply other things and people will assume that if it's not explicitly out of scope, it's potentially in scope.
And you don't want that to be ambiguous and you also wanna keep the scope under control. So once you identify something that seems like it might be implied as part of the scope, but which is actually not that important when you think about it, it's helpful to document that and say we made a decision not to totally redo the homepage, to add a discovery of the feature.
We're gonna build a feature first, and then test its performance in a more limited set of circumstances and then see if we can optimise discovery by putting it in more places.
And that's also because then you don't have to worry about, what if this hurts performance of other things on the homepage, like narrowing the scope of what you're doing is, you can also, if you're more of a quantitative or scientifically-minded person, you can say this, like putting some bounds on the experiment, like limiting the number of factors that are under test. Categorising features are also very important. Must-have, the things that...
One of my old engineering managers put this really, really nicely.
The must-haves are things where if it's not done and it doesn't pass approval, you don't go out the door. And if it's the deadline and you don't have it, you still don't go out the door.
So these are the things that we would probably call them P-zero inside of Google, like Absolute critical priority.
The next year is great-to-have where like, if you didn't have it on the day, you probably wouldn't block shipping.
But it would make you very unhappy and you would have everyone working around the clock to fit them in as soon as possible.
I think there was a thing this week where there's a new Wolfenstein game, where they were supposed to do a lot of changes and cleanups to how the in app-purchase micro transactions worked and they didn't get it done in time.
So all of the different game stores shipped with completely different rules or descriptions of how the transactions work, which led to people being really confused.
'Cause if you were coming from PS4, you had no idea how PC worked.
If you're coming from PC, you have no idea how Switch worked.
And that's something that they were going to do before launch and just didn't make it.
That's probably should have been categorised as a must-have and not a good-to-have.
And then finally nice-to-have.
Like, yeah, we'd love to have everything but if something has to fall off, these are the first to go. And having those three buckets is very important especially because then if you have a discussion about an idea, you can put it into its proper category and acknowledge the value, acknowledge the especially the value of the idea and also the person who proposed it, but be able to say clearly, for concrete reasons, we aren't gonna block ship if this doesn't go out. So it's gonna go on this list, we've recorded it and we will do it if we can. The real talk on this is things that get categorised as nice-to-have very often do not get done, unless some engineer or designer goes rogue and just does it.
There are features out there that have just gotten done. They didn't detract from anything else.
And they added to the delight of the user with the product. So that's the other aspect is like, just because you categorise it nice-to-have doesn't mean someone's not gonna work on it, it just means that you're not gonna prioritise it. Asking the questions.
It is said, and this is another one of those aspects of conventional wisdom about Product Management that I'm not wild, that the job of PM is to be the dumbest person in the room.
And there's actually a way that this is really problematic that I'll talk about later, but I think it's really more that the PM needs to be the most concrete-minded or the person who is going to just probe the questions from a perspective that's close to, as close as we can to beginner's mind. So the first one is asking the dumb questions. Asking the questions the user would ask, asking the questions that a VP would ask, people who have no context, who don't live your product every single day. What is it that they would ask that we need to be able to answer? And oftentimes, if the end, if you have an immediate answer, and you can answer it straight away, that's great. That's a great situation to be in.
Very often, that's not gonna be the case.
And there's gonna be a discussion from it and prompting those discussions will make the product better.
There's also the hard questions.
Product Managers are in a great position to keep folks accountable and maintain urgency like for example, asking, Can this be done by next week? Very often, product managers don't necessarily have authority.
It's not like people are gonna get fired for not getting it done by next week but it does prompt a conversation.
What would it take to get it done and what is blocking getting it done? And this is also good way to signal priority. If something is on that must-have list and you're asking question, can this be done by tomorrow? That's a good way of reinforcing that it is very important and it should be taken seriously.
Keeping it concrete.
It's actually a nice follow on from the other one where one of the kinds of questions you can ask is, for example, what shape will the button be? Will I be able to find the button? It's I think one of the most important jobs that we can do is help people who deal with the very, very low level details of a product or a service.
Remember that, at the far, far end of it, the opposite end of it, there is an experience that is gonna be really about sitting down in front of a computer, picking up a phone, walking into a place of business, or whatever the shape of your product is, and interacting with it in a real way over a period of time and keeping that very prosaic, very physical aspect, mechanical aspect of the product front of mind is a good way to first of all breed empathy, make sure people understand that someone is actually gonna have to interact with all this stuff at the end of the day, and that they are doing that in a way that breeds towards a success state.
And then lastly, this is the famous one is bring the donuts.
But really also whatever bringing the donuts might entail. Again, I don't think it's great to be in a position where a product manager has to go and pack a suitcase for an engineer.
If you'd get down to the wire, and really the only thing that's standing between you and success is going to pack that suitcase, you should probably pack the suitcase.
You'll spend less time doing that than having a conversation over whose job it is to pack the suitcase.
Scheduling the meetings, taking the notes, often, if it's easier to just do it, than have a meeting about doing it, you should do it.
And this is all part of doing your part to maintain progress and morale.
It's also really important to just show that everyone is doing work.
It's a physical thing that you can do, whether it's bringing the donuts, ordering the lunch, organising the conference room for the workshop. It takes a load off of someone else.
So if you have the access bandwidth to do it, it's also a good way to just more evenly and fairly distribute the work of getting the thing done. All right.
So storytelling.
I like to call myself a narrative-driven Product Manager, which is also to say this is not probably not a good look for a Google Product Manager but I have sometimes a distaste for numbers, but I think it's really that I have a distaste for vanity metrics and very, some of that very junk food, easy to source but not very meaningful metrics that you have around.
I'm really very insistent on trying to tell a story. And even if it's through a dashboard to understand what do these numbers mean? What does it mean when the graph goes up into the right? And is that actually of value? An optimal state is to be able to say, absolutely, yes, without having to think about it.
I've not found that optimal state very often. But I'll get back to that.
This is a quote actually from my manager at Google, who's Leland Rechis.
He's a PM who's been, worked at a bunch of places. Been in the New York Product Management community for a really long time and currently working as the overall Head of Product for the whole suite of material products and services. "PMs take in a fire hose information "and output it as structure." And what he meant by structure is not just putting it into a spreadsheet, but actually putting that into some kind of structure or framework, conceptual framework so that people can act on it and use the information. And I call the storytelling because it's humans who have to hear this storytelling and take it in. If you put all this into a JSON file so a machine can read it, that's not gonna get your software done.
You need to be able to put it into some kind of way that people can consume the information.
So one of the structure.
So an example of that is, this is like my three elements of product.
Like without these, you don't really have as a Product Manager, you don't really have a job, or you don't really have a product.
And one is, you have a team, the people who are making something.
You have a product, which is the thing that you're making.
And then you have a market, which is whoever you're making it for.
And together, we the team will deliver the product for the market.
This is the simplest story.
It's also pretty boring.
Like, obviously, this is what's going to happen. So one of the jobs of PM might be to improve on this. That we will deliver the right product, whatever that means and explain what that means, which solves an important problem for the market, which we can explain.
And they will in turn, reward us in money or ad impressions or whatever kind of metric that you get, which is how we will win.
I see a lot of cameras up so I'll wait a second. And you can also kind of take these dots and put them into a different shape.
There's all kinds of polygons in this presentation. You were promised polygons, and I'm giving you polygons. Where a PM, I've actually find this way more satisfying than the Venn diagram of like sitting in between the job functions of also sitting in and being a mediating presence between the team, the market and the product. It's not a perfect triangle, because the team works on the product and the product goes out to or is interfaced with by the market or users.
I say market 'cause it seems a little bit more general. But meanwhile, the PM interfaces with the team and also with the market.
So there's a really kind of indirection or circularness to it.
I'd actually say the PM could probably be like up on that edge of the triangle between the team in the market, but that also seems a little bit wrong.
So I also like how much this looks like a flux capacitor from Back to the Future.
(laughter) So it's really to say like the PM's job in this ecosystem in the flux capacitor, is to make the product story concrete and actionable to the team.
So you have the dots on the previous thing that you make the product which will lead to success for the user who will then generate some useful economic activity for your company. What does that mean to them and how does it actually work? Translate that into a narrative and make it make sense, make it make logical sense to the team, so they'll feel motivated and empowered to make it happen. And likewise, you helped to craft and PMs often work alongside but not necessarily in the marketing team, except at Apple, they don't have Product Managers, they only have marketing managers, for some reason. They help to craft the product story for users. You'll often see PMs quoted, if not be the author on a product blog post or press release.
And this is also the user-facing version of the story is also helpful to bring back.
One thing I found really useful on projects is something I think Amazon used to do for years, which is called blog post-driven development where you write the press release with a blog post first, and then you take that back to the team and say, here's where we wanna end up from the perspective of the user.
What technical decisions and work are implied by this? And then build a project plan around that, but keeping in mind how it is supposed to be taken in by the market at the end of the story.
And so, elements of narrative.
You'd have to think about who are the characters in this story? Who are the market? Are there different sub sections? Is it really like, is there one ideal user or several? Also, how much of it do you need to know at this moment? What do they want? What happens in the story? What are some of the actions that they take? What are some of the things that you'll deliver? How does it end? What is the success state? A really nice thing I found that from a screenwriting class I took years ago, like I said, I'm an art school weirdo who found myself in this job somehow was a screenwriting class where we would open each class with watching few minutes of a movie, and then at various points of the tape, usually about 20 minutes in, roughly the end of the first act, that he would stop the tape.
These were tapes, this was back in the 90s. And he would say, "What do we know and how do we know it?" And you'd have to think back to like, what information did you take in over the course of the story to be explained? Like what's the architecture? Who are the character? What do they want? And you would find there's an awful lot you can take from that.
So you can kind of work backwards from that and say, What is your first act exposition of your product story? What do you know when, how do you know it? And from there, there's an awful lot of interesting work that can happen.
Narrative complete versus MVP.
This is something I was introduced to by a former colleague of mine at Adobe, Katie Dryer.
When I think that there's some PMs, I forget, I can look at the attribution later.
But someone at Twitter, I think, had coined this phrase, where MVP is a really valuable concept.
You wanna be able to say like, what is the smallest thing that you can put out into the market and get some meaningful feedback? This is often abused to say, what is the cheapest thing that we can put out to the market? And not who cares about the feedback? We shipped something.
Or the feedback you want is from investors say, look, we ship something, give us money.
I think that from the user-centered perspective, narrative complete is a really important thing to build into your viability threshold, as I call it for an MVP, to be able to say like there is an overall story or user journey and I need you to say like, there are Minimum Viable Aspects of that and if the product does not satisfy those, you have not shipped a whole product.
I actually like to say that, for ad-supported products. I don't work on any directly.
But from what I've observed, you probably have not shipped your MVP until you've shipped the first version that has the ads in it.
Because then you've not really shipped the whole thing that's going to be sustainable.
You've only shipped a prototype.
And if people like the product without the ads, and then they don't like it with the ads, you don't actually have the feedback that's going to be meaningful.
So whenever it is that Instagram introduced ads, that was probably the first version that was their true MVP, 'cause then you get to find out is the product going to succeed or are people gonna switch to the next thing that's free.
And then lastly, metrics are narratives.
Every number tells a story.
And so when anytime that use a number, even if you're a very data-driven Product Manager, you have to think long and hard about where does this fit into the logic and the product story that you're telling? Because it's gonna be very easy for you to put a lot of numbers that seem like they're creating activity, they tell a story of something happening.
But if that's something does not fit the rest of the story, then the number is, well, it's probably gonna be short term valuable, because it looks like things are happening, which will help to raise capital or get headcount or whatever, if you work in a more corporate setting, but long term, that number is not gonna lead to real success, because it's not connected to the real definition of success.
Especially if you're mixing metrics with any other form of narrative.
It's very important that they all contribute to the same story.
All right, domain knowledge.
I think I've missed an auto advance in here. Do PMs need to be technical? Why don't I ask the room? Do PMs need to be technical? I think I see a few reactions that are like I was gonna say, as we say, in New York.
Who knows? There's a really good quote I read about this actually, like yesterday by Noah Weiss, who used to be at Google, he used to be at Foursquare and he's now a product leader at Slack and he does a lot of blogging and tweeting about the craft of product management.
"PMs do need to have a deep curiosity "about the underlying technology." I'd say, if you don't really care, or if you're bored by cloud DevOps, you should probably not work in a cloud DevOps product. Unless you can find your way to curiosity about it, you're just, you might be successful, but you'll probably just have a really hard time. And you need to have humility about the details and the ability to develop strong partnerships. There are people whose job it is to understand that part of the technical stack and that part of the domain very, very deeply. And they should be the experts, you should ask them questions.
You should be curious enough to care about the answers, but you don't have the responsibility for asking those questions, someone else does. So I think it's helpful to understand that the products domain is broader than the tech stack. It's a very important piece but it is not the only piece.
And so if it's important to be technical, to understand enough of the domain like for example, if you're a Product Manager on a pure developer product, like let's say Firebase, you probably need to be much more technical than if you are working on a purely consumer product.
One of the more interesting job postings that implies a domain that I've seen recently was a ride-sharing company was hiring recently for a Product Manager role for their bikes and scooters vertical.
And I thought that was really interesting because this role probably needs to understand a few things. One is mobile consumer products.
Like what is gonna make a product or an experience really compelling to users in mobile? Great.
E-commerce.
Before I worked at a part of Google that does not deal with money, I worked at Typekit which lived or died by subscription revenue. And my thing for the first several years is I was the e-commerce person.
And that mean, I didn't just need to understand what was the API we used to interface with Braintree or with Adobe's commerce back end, but like what are the rules? You have to understand like, what are the financial handling rules? What are the reporting rules? To make sure that things are done in the correct way. So that's an area of expertise that a PM would need to have. Urban planning.
This is an interesting one, because if you're making a product that you access from an app, but which then puts you into the urban environment on a small vehicle, where you can get hit by cars, you probably wanna understand that your full user journey is going to involve putting your user into that situation. And so like, where do you put the stations or the drop points for these bikes and scooters? Where do you, actually how far should people have to walk to go and get a bike or a scooter? These are things that you would need to understand, not just the software interface, but the urban interface. And then finally, actual bikes and scooters. Like you might be called on to ask, should you go with Model A or Model B of a bike? And you probably need to be able to ask the questions like, is model A versus model B going to have a better customer experience? Is it going to break down? Is it going to create a lot of replacement issues? Are people going to steal it? There's a lot of things that come into play. And so I think this is a really interesting one like, you can be a technical PM, a highly technical PM being... Okay, good.
I have a little pointer on here and I hit the wrong button. You can stay over here and be like the epitome of a Product Manager who works with engineers and works with designers and just stay at that part of it and be missing a very large part of the domain that would help you be successful.
All right.
So, lastly, and leadership.
So leadership is a tricky one.
And I think this is really exemplified by when I showed a version of this deck to some of my Product Manager friends in the chat room. This was their reaction, or what they said the reaction was when they saw the word leadership.
We talk a lot, lots of people talk about leadership for very good reason.
It's a hard job.
It's a hard skill.
There's an awful lot that's involved in it. And it's also frequently misunderstood.
As misunderstood as I'm saying product is, leadership is even more so.
And it makes product a very interesting role because I feel like we are one of the only jobs or few jobs that does purely exercise influence without authority, because in all of the other specialties you can be operating as a manager, as a lead manager where you might be, as they say in American baseball, a player manager where you're both practising in the craft and also managing people who practise the craft. And you're managing those people, probably feeds into your understanding of the craft. You're trying to, lead a team who actually do the thing, and you're optimising for, making sure that they're successful.
Product Managers don't do the thing, and we don't manage the people.
But we are expected to lead.
This one I think was actually like, it's another tweet I saw recently that I thought was really reassuring.
'Cause we have this whole binary, this whole balance between influence and authority. And I think it's really good to see people who have managed say that actually, leading by authority is not the way to do it. 'Cause if you get to the point where you have to say, we're doing it this way, otherwise you're fired. Or you have to listen to me because I have the power to fire you or to cut your bonus or to manage your compensation, you've probably not made a very good argument for the product.
And it might also mean that you haven't looked at the product and you're not going to be leading down a very successful path.
So even in cases where you do, if some of you do manage teams and have the ability to compel your decisions with authority, leading by influence might still be the stronger path. In my experience thing, one of the key elements of leadership, and there's lots of books like Laura Hogan just published a really good one called "Resilient Management" that has a lot of great stuff in it about leadership.
So it's a whole field.
I'm not gonna do it justice.
But one thing that came up a lot as I was first getting started on the team and establishing product management, like the My area of material hadn't really had strong, direct and engaged product management, or central leadership for a while before I joined. And so one of the first things we did was get a leadership off site and set up some regular meetings so that people could actually talk to each other and then I could talk to people and lead to kind of my mantra, for not just the first like two months, but really continuously, is that the leadership needs to show up.
Whoever your leaders are, I think if you're in the engineering specialty or UX, your direct manager is your interface to some of these things, but so is the PM, and for the org, as a whole PM is the primary interface to what are the priorities? What's the direction and what impact are we having? Basically, are we doing well? That's one of the things that people look to from the PM. And so there are lots of ways that you can kind of indirectly tell that story. But it's also very important to just be available, to be present, so that people can ask the questions that they need to ask and feel that you're gonna give them an answer. And so it fosters confidence in the strategy and in you, and it sets a good tone of openness and collaboration. This is one is, I don't have many words on this slide because I think it's pretty self explanatory is that good leaders listen.
I think it's really helpful mental model that PMs should be interviewers, not lecturers. If you find you have a lot of meetings where you're the Product Manager and you do a lot of the talking, you spend a lot of the time talking, that means other people are not talking, which means there's information you're not getting, and people who are probably getting frustrated that there's no room for that they can speak. So I think approaching it is like an interview, maybe an interview that ends with you saying, therefore in my role as Product Manager, we should do this and expect that to stick. One, it probably will stick 'cause the people felt that they were heard and that you were able to explain, given these three options, I've chosen one for these reasons can we all agree? Great.
Is gonna be a lot stronger than just like opining and then setting a direction and not giving any chance for feedback.
Good leaders are responsible.
I think you could also say that they are accountable. We, as a framework internally called RACI, which is Responsible, Accountable, Consulted and Informed. And we spent a lot of time asking like, who's the A on the RACI? Who's the directly responsible or accountable person? And I kind of combine these into one concept of responsible and accountable.
Really comes down to be the person who owns the problem or the product.
You share it with a lot of other people but if there's any question of like, who is the person responsible for making a decision or making something happen? It's usually gonna be the PM by default, and then they'll pull in other people as needed as co-responsible or as consulted.
The key thing with, if you're in that role is do what you'll say you'll do.
Conversely, don't say you'll do something that you're not able to do.
There's a fair bit of self knowledge that comes into play where, say your company or your product should under promise and over deliver, goes double for Product Managers. And I'd say for anyone on the team, but especially product, don't make a commitment that you're not prepared to follow through on especially because following through is going to set a very good, let's say good, very good, safe space for people to do their work, where they feel like things are gonna get done and things are being tended to.
You should be a model teammate.
I actually like this one a lot better than the PMs bring the donuts thing.
I think everyone on the team, if you have a really high functioning teams that are very cohesive, you have a lot of people who will like if they're travelling, they'll bring in some snacks.
Like I have an action item to go get some snacks from here in Melbourne to bring back to our micro kitchen at the team, a little bit as an apology for being out of pocket for a week.
So all the things that people might do to support each other and build a psychological safety and cohesion. Definitely do all those things and try to really model those behaviours.
Think about like what do you want a model teammate to do and do those things and do them consistently. The last one is look out for the team, which kind of goes to the other end.
But don't forget that that includes you.
A Product Manager who burns themselves out trying to look out for the team is, at some point going to have a breakdown.
And then all of that support structure you're providing for the team is going to go away. So you need to figure out, how can you support the team? How can you provide all of this structure and all this guidance and all of this priority setting in a way that is sustainable? So that people can look out into the future and trust that it will be there.
And then last one, is good leaders check their privilege, and check for biases.
I think one of the things that I mean, I feel this because I'm a, almost middle aged white man in text.
So there's and I came from a non technical background, which means I've had relatively few moments where I've had to show my papers and demonstrate why I'm being here and I know that many people that I work with have not had that luxury and it's something that I try to be aware of, and try to correct for, in interviewing, in hiring and just try to be aware that there are people who are not speaking up, are there people who are speaking and not being heard? And so, once again, kind of in theme of, Product Managers are not solely responsible for this, but are in a great position to move the needle on it by being in a central role and being kind of having this global view of what's going on on the team.
I wanted to put this up here 'cause as a reaction to again, that the notion that PMs are the dumbest person in the room. That is a strategy that works really well for me, as a white man at the front of the room, I can say, I don't know anything but I think this. Minimising myself, I think can work well, because I'm coming from a position of great privilege. Other people that strategy is not going to work because when they say that same statement, someone is gonna say, "Yes, you're right.
"You don't know anything, because you're not like me." So I think it's, again as Product Managers, do what's right for you, but also, I think that's one of the reasons why it's problematic to, put on let's just say the cloak of dumbness or try to minimise yourself in front of the team I think it's much more important than to just try to be straightforward, forthright, advocate for your viewpoint, advocate for people, and just try to build a more respectful environment. And so the last one returning to the coaching slide, end of the day PM helps the team achieve its goals. We're coming at this from the coach perspective, sitting on the sidelines, having more of a global view, trying to help the people who are on the field do their best work and play their best game. And I think that feeds into leadership and it feeds into all the other things.
Be the best coach or facilitator that you can and try to be a force multiplier.
I think that really, if there's like, one thing I try to carry through my day is like my job is to be a force multiplier. It's actually really unfair that I probably can take all the union of all the work that people do, put it on my own performance review and get credit for it because I didn't do any of that work.
But I did help people find their way to the right work, which is something.
So wrapping up.
PMs and their roles, we all have unique shapes. And I think rather than try to be in this existential crisis of not being in the optimal shape, it's helpful to find a framework where we can account for differences in roles and differences in people. And also understand the goal of product is constant, even with that variance of shape is that we're here to help teams ship their products and achieve success.
This is not a straightforward thing to do.
And the reason why we have product management as a job besides just having it be another responsibility for CEOs or for engineering managers, is to provide the perspective and the focus on that, that people can't do while also doing their day to day job, which I think is what makes it a really, really interesting space.
And with that, product is as much a mindset as a skill set is getting into this, the common term for it is servant leadership, but I really like facilitation, or being a force multiplier of understanding the space, educating people on the space, listening to the team, and helping to guide them towards what's gonna be the most impactful work that they can do. and develop the skill set that will help do that. And with that, I think that will help Product Managers find their shape and their place within the space. Thank you very much.
(applause) (gentle upbeat music)
