About this talk
Everything you never wanted to know about product management, including the triangle of ambiguity and how you, as a developer, can benefit from being more product manager.
[00:00:02] As Ilya said, I’m a product manager here. You might be thinking, “Why is a product manager talking to us? What’s this got to do with what we do? What are we going to learn from this?” I’m going to keep you in suspense on that, for the time being. We’re going to start with this. This is actually an Ikea advert, which is not the point of the slide, but what it does is it illustrates one of my slightly nightmare scenarios. I’ve only just noticed the kid in the background though. This is one of those parties you go to where everyone is really cool and there are lots of new people and they maybe don’t all work in tech, so you’re getting outside of the bubble and you’re like, “This is great.” It’s not that I hate parties or meeting new people or fun, but inevitably, the first question that anyone asks when you meet them, and it has actually happened tonight, already, is, “So, what do you do?” Much like that. This is hard for me because you take a deep breath and I know what their reaction is going to be and I say, “Well, I’m a product manager.” You almost always get this blank stare or you get, “Oh, so you’re a project manager?” I’m just like, “Oh, no, that’s not at all what I do.” Or, they follow up with this question, “What do you actually do? Day-to-day?” I try things like, so maybe they don’t understand what product is, I make useful websites and apps for people. Then you have them say, “You’re a developer; you’re a designer?” No, that’s not what I am either, I just tell people what to make, and then I’m like, “No, I really don’t tell people what to make because although I’ve got manager in my job, I don’t actually manage anybody in any conventional sense.” You’re probably still thinking, “How is this relevant? Does it really matter if these people at a party know what I do?” These aren’t the people I’m concerned about. It doesn’t really matter if they know what I do. I might have an awkward conversation and be a bit like, “It would have been really nice for that not to have been awkward.” It does matter that the people I’m working with know what I do, because a bit part of my job, actually, is to help other people do their job better, so that we can all succeed. [00:02:36] In the course of thinking about this talk, I’ve been collecting phrases or ways that you’d describe product managers. I did what any self-respecting internet person does and went to Medium and typed in product management, what is a product manager? You quickly realise that there are tens or hundreds of articles, almost exclusively written by product managers. They’re covering what a product manager is, what they aren’t, how they should be, how we can be better, what they definitely shouldn’t be doing. It quickly becomes clear that there’s just many different ways of defining what it is that we do. Here at Made by Many, it’s something that we’ve been, over the last year and a half, it’s a relatively new job title here and role, so it’s something we’ve been trying to define. Especially where we work, where we’re talking about clients, so we’re not looking after a product directly ourselves in quite the same way. I also thought, “Medium hasn’t really helped me. Maybe I’ll ask some of our developers here what they think I do.” Actually, they did quite well. They didn’t say anything that was offensive and all of the things they said were things that I consider part of my job, but there was still a huge variety of answers. None of them were what I would probably say myself. These are some of the things I have collected. Yes, there are some good ones. I kind of agree in part with all of them, to some degree. My personal favourite is janitor. Not because it’s demeaning but because I actually think it gets to the core of what my day-to-day reality sometimes is. Yes, you even wondered who does data entry when you’re like, “We need to put all the content in this.” It’s probably a product manager somewhere. [00:04:28] I also found this, which I’ll just let you absorb for a second. I worry that this is true a lot of the time. I don’t think I’ve ever really considered myself Superman, but there would definitely be moments where you feel like a headless chicken. To stop that feeling and to stop running around in circles and having people wonder what I’m doing, why I’m doing it, am I doing anything at all. There are three big questions I really think this boils down to. I think ultimately for me, product management boils down to, and this is the difference between a project manager and a product manager, what is the right product? Why is that the right thing? How do we make it happen? I’ve put these in a triangle of uncertainty because they’re not all independent questions that you can answer simply. You can’t answer any of these in isolation. Each of them are continually informing the other. As we find out more about what something should be and why it should be, we’re then moving onto thinking about how do we achieve that. As we start making progress with how and getting into the details, we probably need to go back and revisit why we’re going it in the first place, as we try to figure out, should it behave in this way or that way? [00:05:55] Made by Many for what we’re always aiming for is the right products. This is our Venn Diagram, that we use extensively and if you’ve ever seen anyone from Made by Many talk anywhere before, you’ve probably seen it. We’re aiming for that bit in the middle. There is this really slim sliver between what the customers need and what’s right for the business. That’s our sweet spot. Getting to that what, as I said, needs to be continually guided by the why and the how. As I said, it’s a triangle of ambiguity and so part of my job, a very large part, is navigating that and helping other people to navigate it. I think of this, as a product manager, the most important thing is being able to ask the right questions at the right time to the right people, in order to figure out all of these things and make progress. Big question mark. We always have a starting point for reference. In this case, I’m going to be assuming we’re thinking about a product that already exists in some way, shape, or form, and so the one thing that helps to guide all of those questions for me is having a product vision in mind. For those of you that may not know exactly what a product vision is and should be, it’s something that looks into the future. They tend to be big and bold and they serve as inspiration and direction and allude the problem that it is that we’re trying to solve. We like to refer to them a lot as our north star, because that’s where we’re going, that’s where we’re headed. We might be taking small steps to get there but that’s what we’re trying to do. For me, the absolutely best ones as well, help you makquee all of the decisions you need to make on the journey. Those are the sort of questions that can be everything from which feature to prioritise over another one? How they should be implemented? Which things we should just kill because they’re never going anywhere? What we should be tackling right now, because it’s going to have the most impact? What can wait for a next sprint or a future one? [00:08:14] I’ve just ranted about vision for a few minutes, but ultimately, and this is an important one – I keep thinking I’ve got a clicker. Product managers are facilitators, not visionaries. I think if you’re in a situation where a product manager is acting like a product dictator and telling people how to solve their problems and not figuring it out with an awesome team, that for me is doing it really, really wrong. I believe the only way to make something right, to make that right product that we’re all aiming for, I hope, is by listening to a lot of people and working with everyone as a team. That’s something that is particularly relevant to this role of product management, because as a product manager, actually my experience and knowledge goes across a load of disciplines but are relatively shallow level. Thinking about design, I might be able to sketch out a use journey but I can’t do the actual design of an interface and make it look amazing and really work for people. I can do some budgeting and understand business models, but I’m not an amazing finance wiz, who’s going to be able to solve all of your future profit projections. I can sort of talk tech. Ilia laughs. I definitely can’t code anything, unless you want some kind of very 90s iPhones. For you and what I want to talk to you really is because your knowledge and your skills are far, far deeper than mine. Whereas, I touch a bit of everything, you actually are the experts. I couldn’t do my job; my job wouldn’t exist without you lot. If I wasn’t around you might miss me, if I got hit by a bus I’d hope you’d be slightly sad. You would ultimately still be able to make something. I’m going to argue that I don’t think it would necessarily be the right thing, but you could still build something. [00:10:22] Ultimately, even with this amazing deep knowledge where you really know your stuff, when we’re thinking about a product we’re trying to make, we’re actually all part of this much, much bigger team. Down here, that’s probably developers, designers, people working directly and building stuff on a product team together, with all sorts of people that might then be a stakeholder in what you’re doing. I think we might have to make friends with a finance person, your CEO or strategist, whoever is that visionary is probably going to turn up with some very strong opinions. We’re got marketing, customer service, and of course, really importantly, the actual customers. The people we’re building this thing for. All of these people, in the same way you have this depth of knowledge about being developers and how to write code and how to make stuff, they all have the same level of depth of expertise as you do, in their own particular fields. Me, I sit somewhere in the middle there. Possibly closer to a product team than anyone else, but that’s my happy place. Mostly happy place. It’s where I’m comfortable because what I’m trying to do at every point in a project when making a product is hear all of these people’s opinions. I want to know what’s motivating them, what they’re thinking about, what they’re worried about, what their goals are, where they want to be, and helping all of them to come together to build something that works for everyone. [00:12:01] For me, this is really a position of facilitation, negotiation, a bit of persuasion. It’s far more about that than it is about leadership. The big thing here is, my role here is to stop any one of those parties from becoming too loud or dominant. It’s all about trying to balance all of these inputs, to find something that’s actually going to work for people. It’s not necessarily just people either but it’s also on top of this you might have quantity of data, what your competitors are doing, changes in broad technology landscapes. There are so many different things that have to be considered when we’re aiming for the right product. Another way for me to describe this, is that there’s a bunch of people that sit at a very high level who are thinking about that product vision in a long-term way. They’re thinking about where are we going to be in the next year, three years, five years? Then as developers, I think, you probably often find yourselves right in the now, in the implementation and the particular feature that you’re working on at any given moment. You’re looking at things from this very minute detail. A big part of what I try to do is translate between those two things, to help people who are at that high level understand the problems that come when you’re actually implementing their grand vision, and to help the people who are doing that implementation understand the why a lot better. As I said, a bit part of how I do this is by asking questions and forming hypothesises and trying to validate them. [00:13:41] Here are the hypothesises for you. I think we can make better, more successful products by all thinking a little bit more like a product manager. I’m not going to try and convince anyone to become one, but I think there are some things in that world and skillset that can help everyone to do their jobs better. You probably thought I was just going to talk to you about what a product manager is without asking anything, but there are a few ways that I think we can all start to do this. I think this is the first step. For me, the worst developers to work with are the ones that are like, “I’m really great at writing code. You’re just going to give me stories, I’m going to write it in a really beautiful way and I’ll do it exactly as it’s described and it’ll be done.” That’s painful. What I actually want is the people to look at the backlog, look at the tasks and consider user stories within that wider context of why are we doing this, who it’s for, and how can I build this in a way that best serves them? Which kind of leads on to encouraging everyone to step away from their screens occasionally. It does happen. I’m sure I’m also not the first person to stand up at a dev conference and say, “You should all go and meet your users.” I think that is one of the first steps. If you have potential and you’re able to go out and meet customers and speak to them directly. It can make it a lot easier for you to know how something should be built, because there’s nothing quite like sitting down with a use, seeing them use the thing you’ve been working on for days, we’ll be generous. Seeing that they struggled to use it or that the loading time is unrealistic for the device they’re using it on. [00:15:36] It’s not just about customers either, as I said. They’re one part of this big force that brings a product into being. I’d also urge everyone to step away from their computer within the office as well, whether it’s in the kitchen and just talk to the person who you have no idea what their job is, find out what their concerns are, and then the next time someone comes down be like, “We must build this feature now.” You might have a better understanding of where they’re coming from and be able to solve that in a better way. I can’t work out whether this is dangerous or not. I think a lot of people also think product managers are in charge of the process and we say this is how it should be done, but especially for those of us who aren’t from a tech background. It’s not always clear to us how we can best help and to make work more efficiently. Ultimately, no matter how good we are at listening to our customers, listening to stakeholders, if we don’t get something out the door it’s kind of all work for nothing. I think from that perspective; I think product managers are really pragmatists. There are sometimes obviously we want to do and make sure happen, but ultimately, you’re the experts on things like estimation and exactly how long it takes to build something or the benefits of one way of doing a feature versus another. [00:17:01] I really want to encourage everyone that you can feel that you can own that process you’re working with to make it more efficient and suit the way you work and let you do better work. Ultimately, it all boils down to me as they ask more questions. There were the three questions at the beginning and I think those are things we can all use in whatever we’re doing, to really guide and make the work that we’re doing better. There’s stuff you can ask yourself. What are we really trying to achieve with building this thing? Who is it for? How’s it going to be used? How can it help us to get to that vision? There are things to ask people around you as well. Whether it’s colleagues or clients or customers, using that curiosity to sniff out their motivations and fears and develop a better understanding of their point of view can be really helpful when an unexpected curveball flies in. That’s what I really want to leave you with, is that I hear of tension between product managers and developers and I think it’s largely because you don’t feel enough ownership or the product manager is holding on to stuff too much. Actually, this is all a shared responsibility. That’s shared across the team. The only way we can navigate the uncertainty of getting to the right thing and trying to make products that are right for the business and for the customers, is to find out what we don’t know, what we need to ask to find the next answer that’s going to help us release the next thing that’s going to get a little bit closer to where we’re going. Thank you.