Transcript

Hi everybody, thanks for coming along. My name's Thor Mitchell and today I'm going to be telling you a little bit about Product Management. So before we get stuck in, just a little bit about me.

I originally studied Physics a long time ago and while I was at University I got a summer job in my home town of Bournemouth at a small internet company that had just started up. It was literally one of these tiny little provincial internet companies that were a bit of a thing in 1995, and I quickly realised that this internet stuff seemed quite interesting and probably more interesting than Physics. So when I graduated I got a job at a company called Sun Microsystems and they were a big player in internet infrastructure in the late 90s. I was there for about 8 years. Spent some time with them in the U.S. Rode the dot-com boom up, rode the dot-com collapse down, and then moved to Google in 2006 and spent another 9 years at Google. And while I was at Google I moved from more of an engineering role into more of a Product role and I'll explain what that means in a minute. And I spent some time with Google both in London and also quite a bit of time in Sydney and in San Francisco and then about a year ago moved back home back to the U.K. to join Crowdcube who are a small company based up in the Innovation Centre here on the University.

So why am I here? One of the first things I was asked to do when I started at Crowdcube was build a Product team. In other words hire a bunch of people. And my plan was to hire a few experienced Product Managers, and a few, one or two maybe graduates or people who were interested in Product Management. And I thought it would be easy to find graduates and hard to find experienced people and I was completely wrong, it was the complete opposite. It proved surprisingly difficult to find graduates who might be interested in these roles, because it turns out nobody understands what this role is and nobody has ever heard of it. Nobody knows why they might want to do it and that seemed like a real shame to me because it's actually very fundamental to modern technology companies and actually a really interesting and fun role, especially if you've got aspirations to perhaps start your own business one day, or take a leadership position.

So what I decided to do, essentially this presentation, is my attempt to fix that. This is not actually a hiring presentation, we did eventually manage to fill these positions and we're not actually hiring right now. But it worried me so much that graduates didn't have a good sense of what Product Management is and why they might want to consider it as a career option that the least I could do was try and help. So this is the first time I've given this presentation, so it's as bad as it's ever going to be, so bear with me. But hopefully by the end of it you'll get a sense of what this role is and why it might be interesting to you, and then hopefully there'll be more opportunities for me to do this to other groups of students in the future.

So what are we going to cover? Three things. What is a Product Manager? What on earth am I talking about? Is this a role that might be good for you, and then if it is how would you actually go about becoming one?

I should stress actually that also, even if you decide by point two that this is not the role for you, that you want nothing to do with this, it sounds awful, you may well end up working with Product Managers at some point in your career so it might be good for you to know what you're up against.

OK, so what is a Product Manager?

So firstly, start with something fundamental, what is a Product? When we talk about Products, we talk about Product Managers, a product is any physical good, software, or service offered to consumers or businesses. So a very broad definition. It could be a camera, it could be a bottle of water, it could be an app on your phone, it could be a plumber, it could be a fairground ride. Now essentially, in one phrase, the Product Manager's job is to own the success of that product. Figure out what it will take for that product to succeed.

So how do you go about doing that as a Product Manager?

So to do that you've got to step right back and say what's the goal of this product, what is the vision for it, what is its potential, what could it be in a few years time if we really tried to make it a success? And so you start with the vision and then you start working your way down through the different steps as you work your way towards actually doing something.

So once you've got a vision then you need a strategy. How are we going to get from where we are to where we want to be with this product, and how will it deliver value to the business. Obviously products have to pay for themselves as they're being developed. OK, so you've got a strategy and that will come in the form of a roadmap, a path from where you are to where you want to be, which is a sequence of milestones, releases, whatever you want to call them.

And each of those has to have a set of requirements that it is trying to address, and the thing about requirements gathering is that it's really an exercise in listening. You need to listen to your customers, you need to listen to your users or your potential customers, and understand what is it they need, what are their pain points, what are they struggling with, why are they using your product and how can you help them? Because often your expectations as to what your product is for and how it's used are completely different from the thing that draws your users in.

OK, so once you've got your requirements then you compile those together and you create what we call User Stories, and "User Story" is a fancy way of saying a feature, essentially, some incremental improvement in the product. We call them User Stories because we try and separate ourselves as Product Managers from the implementation. We don't dictate to the Engineering team or the Design team how something is built. What we say is, these are the user behaviours that we need to facilitate. So for example, if you were building a system for railway ticketing, a user story might be "As a passenger I want to be able to carry my ticket on my phone" and that's it. That's the whole story. And then it's up to the Design team and the Engineering team who you hand these things off to, to actually figure out how to make that happen.

So as a Product Manager you own this whole tree. Your job is to understand fundamentally what the goal of your Product is, to have a sense of where it's going, of what it could be, evangelise that to people, get people excited about it, get them onboard, get them willing to help you, because you're going to need a lot of help, and then go from there, all the way down to the nitty gritty of "What are we doing tomorrow? What are we going to build?".

So once you've handed it off, the job's not over. Because you're still the maker of trivial decisions. And what I mean by this is when you actually get stuck into developing a product, any kind of product, what you tend to find is that no matter how good you are at that requirements gathering stage, there's always lots of little questions that bubble up all the way along. What should the label on this button be? What should the help text on this tooltip be? Should we go for red, should we go for green? Silly little things, but little things which if nobody feels empowered to do them or decide them will just paralyse your development. So someone has to just step up and say "I'm going to decide and we're going to do it that way". And sometimes you've got data, which is great. Sometimes you've got a way of actually testing different variations, or you've got some evidence from previous experience that doing it one way is better than the other, but often it's just that either of these solutions is a perfectly good one, someone just has to decide.

You're also, I couldn't resist this terrible pun, you're also the one person who really deeply cares about how good this thing is, and wants it to be great, wants it to feel polished, wants it to feel really refined, wants it to make people happy. And so you're the person who has to really focus on the details. You have to say "Actually no, I don't think that works quite as well as it could, or I don't think that looks quite as good as it could", and hold the teams to account, and push them, to actually deliver something really really great.

And then, when you get to the point where you're almost ready, you've got to coordinate the launch of the thing, you've got to get the thing out of the door. And that could mean a million and one different things. So, it depends again on the product, but you might have documentation that someone needs to write, you have to make sure that happens, you have to review it, make sure it's accurate. There might be reasons why you need to speak to the legal team. You might be in a regulated industry, or there might be compliance issues, or privacy, or security that you have to worry about. You have to talk to the marketing team. How are we going to tell this story, how are we going to bring people into the product? What's our launch messaging, are there blog posts, are there social media, are we doing any press, do I have to speak about this, do I have to go do public speaking at industry events? That sort of thing.

So you can probably tell that as a Product Manager you’re basically doing a little bit of everything. Because you are that single point of contact for the product both inside the company and out. You're the person who is most strongly associated with it, and you end up working with all these different teams. And although you work with all these different teams you are not in any of those teams so you develop a bit of skill in all these areas but you're not really an expert in any of them. But you are the only person who has the complete picture over everything that's going on.

So a thing worth stressing actually is you manage Products, you don't manage people. Despite the fact that you have all this responsibility to make this thing great, whatever it is, you don't actually have a team that reports to you. You don't actually manage individuals from an organisational perspective. You just manage that product. So everything you do is driven by influence essentially. You have to build trust and confidence amongst your peers, that you know what you're doing, and that things are going in the right direction and it's helping the business. And then once you've built that buy-in you can coordinate them and get them to help you.

So understandably, communication skills are critical, they are a fundamental part of the role. Right, so this is a quote I'm fond of from a guy called Ken Norton, who's a highly respected Product Manager who works now at Google Ventures, who are the Venture Capital investment arm of Google. And his role at that organisation is to provide essentially Product advice, to act as a mentor, to all the companies they have invested in. And he's got this great article he wrote quite a long time ago now, but it's still very well known, called "Bring the Donuts", which is about how he goes about finding Product Managers, and about the role of Product Managers. And one of the things he says in there is "Remember friend, nobody asked you to show up".

And what this means, is that, Product Management is kind of weird because it's not actually essential. If you took the Product Managers out of an organisation that organisation wouldn't collapse. If you took the Developers out, nothing would get built. If you took the Finance people out nobody would get paid. But Product Managers, the company would just continue ticking on, but over time it would start to struggle, it would become quite bureaucratic, because the communication would start to break down internally. They'd lose potentially a sense of direction. There wouldn't be anybody strongly representing the users in there. A lot of that coordination burden would then be falling on the engineers, and engineers are generally much more productive when they are not interrupted than when they are. So essentially it's a facilitating function that greases the wheels of the organisation, but it's not essential.

So I've been going on and on about this role and how you've got all this responsibility and do all this great stuff, and you might be wondering "If Product Managers are so important, why haven't heard of any of them?". And the chances are you probably have, you just don't realise that they were Product Managers, or are Product Managers. And there are quite a few people who have come up through Product Management, and have gone on to success elsewhere. So here's a few names.

This is a guy called Brett Taylor. He was the original Product Manager for Google Maps. After doing Google Maps he left Google, and started a company called FriendFeed. FriendFeed was acquired by Facebook. He became Chief Technology Officer at Facebook, and then after that he left and founded another company called Quip who create online document collaboration tools. And you tend to find that happens a lot. Product Managers tend to be quite ambitious people, and often they develop this wide set of skills and then they get frustrated being just part of this machine and they go off and do their own thing.

This is Stephanie Hannon. She was again at Google. Originally she was the Product Manager who proposed GMail for organisations outside of Google. So essentially Universities, Business, that sort of thing. She then went on to do Google Wave, then she left and went to Facebook, and did Risk and Trust which sounds terrifying at Facebook, and then she came back, did YouTube. And then last year she was made Chief Technology Officer of Hillary Clinton's election campaign, and was recently listed as the fourth most politically influential person in Technology by Wired magazine.

Marissa, who you probably have heard of. So Marissa ran Product at Google for about 11 years before she left to become CEO of Yahoo. She's also very significant because she founded Google's Associate Product Management program, which is their graduate hiring and training program for Product Managers, which set the template for all the graduate training schemes to follow. There are a lot of really interesting articles out there, if you search for "Google APM Program", you'll find all sorts of interesting articles about this program, which is a two year program, where they rotate you through a number of teams, they take you on a world tour, literally, and she ran the program personally right up until she left. And now she has started a very similar program at Yahoo!

Sundar. So Sundar was Product Manager for Chrome, the original Product Manager for Chrome, when that launched. And that went quite well, so then they gave him Apps, and that went quite well so then they gave him Android, and that went quite well so they made him CEO of Google. So he's done alright.

So, we've talked a bit about what a Product Manager is, and what it involves, and hopefully by this time you're beginning to get a sense for whether this sounds really interesting or really terrifying, because there is no doubt that Product Management isn't for everybody, it's a certain character type, so let's dig into whether it might be for you.

So let's talk a little bit about some of the traits you see in Product Managers. Incidentally I'm not suggesting that every Product Manager exhibits everything on this list. But if you recognise yourself in some of these things, then it might be a good fit.

So, first things first. It's a leadership role. And I don't mean that, as I said, in the managing people sense. I mean in the showing people the way sense. You set the direction for people to follow around that product. That comes with a certain set of skills. Obviously you need to be pretty confident, you need to inspire people. Decision making is essential. It's very easy to get stuck trying to make the perfect decision, the right decision, trying to get all the data and nail it, but often it's better just to make a decision, even if it's the wrong one, learn quickly that it's the wrong one, correct yourself and move on. That sort of constant course correction is kind of an essential skill because momentum is critical. You also have to be quite tenacious. Things go wrong, and you have to be able to just stick with it. And you have to be quite resilient because you have to make, you have to be comfortable making unpopular decisions. Because the best decision for a product might not be the decision that your Engineering team likes, or that your Marketing team likes, or that your Users like. Sometimes the best thing to do is to kill something completely, and that can make you really unpopular. So, if you're the sort of person who needs to be loved, this might not be something that you enjoy.

Communicate. I already mentioned that communication is essential. You need to be able to articulate your direction, your vision. You need to be able to persuade people that the direction you're going in is the right one. But you also need to be able to listen, listen to those users and listen to the people around you, and empathise with users, particularly people who are dissimilar to yourselves. There's a well known tendency in Silicon Valley in particular, for companies to build products that are really only of interest to people in Silicon Valley, because they don't empathise with the broader U.S. or the broader world. Empathy's also very important inside companies, when you’re doing relationship building you need to be able to empathise with the people around you and understand what do they care about, what constraints are they operating under, what incentives are driving them, what pressures are they feeling, in order to manage those relationships.

Energy. So the Product Manager drives the team. They are the person who sets the mood for the team. You tend to find that everybody around the Product Manager is highly attuned to their emotional state, and if the Product Manager starts to look down then everybody comes down with them. And so it's important to be able to stay positive even in the face of setbacks. It's also important that you just like working with people, that you love what you do, and that you're passionate about technology, and that you believe in the power of technology to do good things.

So you've got to be a bit practical. I mentioned about being detail orientated, caring about the little things that make it great, but you have to balance that with some pragmatism, because you can't do everything. And sometimes you just have to say, "Let's ship it". Because nothing you build has any value until it's shipped. So sometimes you just have to say "This will do". You've got to be organised, there's a project management element to the role. You're managing the schedule, you're managing people, you're handling dependencies, you've got to be able to juggle all those things. And then, when it's coming down to the wire, and everybody's watching, and are you going to make it. and you've got some event coming up, you need to be able to just knuckle down and get on with it and not buckle under pressure.

There's a Creative side to it as well. You have to see opportunities to make the product better. You have to recognise opportunities for new products, ways of solving existing problems creatively, or new problems that haven't yet been solved. It's also useful if you have a good eye for design, you recognise what a good product looks like, you see the beauty and simplicity in everyday things.

There's an Analytical side to this, which is kind of the counterbalance to the Creative side and you can see that a lot of these things seem strangely contradictory in some respects. Because often, as I mentioned, you can't just wing it. You can’t just say, "Well, you know, I think it looks better that way, so let's do that". You have to be a bit data driven. You have to actually go out there and collect data. And we run a lot of things called A/B tests, which is where you say "I hypothesise that this product might perform better if it behaved in this way, but I don't know for sure so what I'm going to do is I'm going to build that behaviour but then I’m going to split my user base down the middle and half of them will get the old behaviour and half of them will get the new behaviour, and we'll see which one performs better". And that's a really fundamental iterative process you use to do continual refinement on product design.

You also have to be Informed, in the sense that you have to care about the industry you're in, you have to care about the space you're in, you have to know what the competitors are doing, you have to know what new trends are there in the industry, what new technology is coming up that will enable you to do interesting new things with your product.

And then Questioning. So essentially there's an element of curiosity to this. You tend to find that Product Managers, they look at the world, and they ask the question "Why are things the way they are?". And once you start having to make those kind of product decisions about the way things should work you start wondering why other things work they way they work. What factors went into that? You have to be open-minded, in the sense that you could very well be wrong, right, and in fact often you are wrong, and it's important to be able to say "Actually I was completely wrong, I'm going to change my mind and go do something else", and you have to do that in a way such that people see that as a sign of strength rather than of weakness. I was kind of on the fence about the word Opinionated because it's got negative connotations, and that's not really what I mean but can't find a better word. What I mean is that you have to be the sort of person who forms and expresses opinions. You have to have an opinion about subjects that come up, about direction, about strategy, about the business. You have to be willing to actually voice them, and you have to be reasonably assertive about your opinions. And that doesn't mean being arrogant or unpleasant or rude. You just have to be willing to speak up.

And then you have to balance that with Humility. I mentioned a minute ago that you might be wrong, you might have to change your mind, it's important that when things go wrong you take the blame, and when they go well you give others the credit. It's important that you recognise value in the ideas and opinions of people other than yourself, and that you’re constantly collecting feedback and suggestions from all around you, and distilling them down and synthesising them into the best, most impactful things you could be doing at that moment. And it's important that you don't mind getting your hands dirty, that you don't mind doing what needs to be done just to get the thing out the door. Even if that's really demeaning or trivial. The reason why Ken Norton's article is called "Bring the Donuts" is because he argues in there that sometimes the job of Product manager, when you're right down to the wire and you've got a release that's due and everybody's working late, is just to go out and get donuts.

So, I realise that's a pretty long and potentially intimidating list of character traits and as I say I'm not expecting people to have all of those things, and indeed most Product Managers don't have all of those things when you start. But if you look at that and think "That's a set of skills I'd like to evolve" then Product Management is a good place to do that. You will develop those skills.

And actually that brings me to an interesting point. We're going to take kind of a weird aside for a moment, as we're about halfway through. What I've seen when I've been recruiting, both for Google and now, is a tendency for some people to be reluctant to apply for roles unless they feel like they meet every single criteria listed on the job spec. And I just want to say, just a piece of advice if you'll indulge me for a moment, that's a terrible idea. Never apply for a job where you already meet all of the requirements, because what are you going to learn? If you want to increase your value, if you want to grow yourself personally and professionally, and progress with your career, you have to be continually evolving and growing, and the only way you do that is by learning new things. If you already know everything they are asking you to do you're going to be bored out of your mind. And then you're going to leave, which isn't good for them or you. So, when you look at a job, it's not about "Can I do everything they're asking for?", it's about "Can I do enough of these things to get by?". And believe me you'll be really surprised by what you can achieve when you're thrown in the deep end.

There's a well known, well discussed, phenomenon amongst "successful people" (in quotes) called Imposter Syndrome. And this is the sense that you secretly believe internally that you are not at all qualified for what you're doing, that you're a complete imposter, and that any minute now someone is going to realise, and you're in trouble. And a certain amount of that is healthy and normal. Too much, and you're crushed under your own self doubt, so don't go there. But don't worry if you feel a little bit that way, because in truth, you should always feel a little bit uncomfortable in what you're doing because then you're learning, then you're developing new things, and if you get to the point where you feel comfortable and you're like "Ah, I know how to do this, I've got this nailed" it's time to move on.

Ok, so that was my small rant. Back to the topic at hand.

So we talked a bit about "Are you right for Product Management?", but equally, if not more so important is "Is Product Management right for you?". And I just want to cover some of the reasons why I enjoy it, some of the reasons why I like it, why I feel in terms of my goals it makes me happy, and I find it fulfilling.

So firstly Autonomy. As you can probably tell, as a Product Manager, it's kind of up to you to figure out what to do with your product. You have a lot of autonomy to set the direction, and to set the priorities. So, I mentioned that when I was younger I came up through engineering roles at Sun and other places, but I also mentioned that I wasn't a Computer Scientist, I did Physics. So I wasn't, I was never a hard core coder. I didn't have the theoretical background. So I was doing more support roles, I was doing a lot of help fixing stuff. And Support is a great place to learn stuff but at the end of the day, everything you've done has no real value the following day, all you've done is fix things that were broken and everybody says "Thank you very much", hangs up the phone, and moves on with their lives. The good thing about Product Management, and product development in general, is that you're creating something. You're doing something that leaves a mark on the world.

One of the products that I managed for a long time when I was at Google was called the Google Maps API, which is Google's technology stack for allowing third parties to utilise Google Maps in their own products. And if you've ever used a website that has a Google Map on it and it's not a Google site, it could be Rightmove, it could be a travel site, or if you've ever used an App that has a Google map in it and it's not a Google App then you're using the Google Maps API. And every day I woke up feeling like I was doing something that mattered, which is just a great feeling, and it's not necessarily that common. Because this product is used, yes it's used in retail, yes it's used in travel, but it's also used by humanitarian organisations. It's also used by environmental organisations. It's also used by organisations that are supporting regime change in oppressive countries. Every day, new use cases would come across my desk that just made me feel like "This is good, we're doing something good here". And that's a really really wonderful feeling.

So you've probably figured out that you learn a lot, and a lot of what you learn is actually quite valuable. In fact Product Management in general is an increasingly in demand skill. One of the reasons why I struggled a bit to hire, I think, last year, was because it's not that well established in the U.K. right now. It's growing. I went to the big Product Management conference in London last year and it was about 1,500 people, but it's not that well established compared to say, the U.S. But within the technology sector it's very very well understood that this is an important role, and that companies need Product Managers, and generally you find companies need them when they get to about 30 people, something like that. Up to that point it's the founder, it's a couple of engineers, they're just making it work, but eventually the CEO, the founders, are starting to think more about financing, and some of the more administrative aspects of running a business, and they need to hand off that day to day management of the product and that's when they bring a Product team in.

Also, you do see a few Product Managers who start in Product Management, and they get really attached to one aspect of it, and then essentially, go off on a career tangent. Perhaps you really enjoy the Marketing piece. Perhaps you have a secret desire to be an engineer or whatever, that happens quite a bit as well.

You work with lots of interesting people, that's sort of a given. You've got that perspective on the big picture. That mattered a lot to me. Because I'm naturally curious it wasn't enough for me to just be told to go and build this or support that, I needed to know why, why are we doing this, does this make sense, is this worthwhile, what are the goals here?

I'll come to this in a second, but there's a surprising sort of, there's a lot of different directions you can go in, so it's good from that perspective. It's very varied, every day is different. And it's a lot of fun actually. Especially when you actually ship something, you get something out, you see people start to use it, it's really a lot of fun.

OK, so I mentioned this a moment ago. Where can you go from here? So, Product Managers exist in both large and small companies. Again, because it's a relatively new role, you tend to find it's the bigger newer companies, so Google, Yahoo, Facebook, Microsoft, these kind of companies. They will have Product Managers or an equivalent. And then most of the startups will get to a point where they need them, and they're hiring for them as well.

So you can go in either of those directions. There's travel opportunities as I mentioned, it's a sought after role, so it's quite easy... well let me give you an example. At Google, every six months, every Product Manager in the company gets an email that says "Do you have any interest in moving overseas?", and if you say "Yes", they say "Which countries would you like to go to?" and you say "I would like to go to Singapore" and they start emailing you Product Management jobs in Singapore. Because they believe strongly that cross-pollination of ideas between geographies is extremely valuable from a Product perspective. Because it's a global company. They need people to build products that work anywhere. So you can't just have a bunch of Americans working on a product in America, and a bunch of Brits working in London. And that was how it was so easy for me to go from London to Sydney, and then Sydney to San Francisco. I could have just as easily come back to London, but I decided that maybe I should try something new.

So, certainly a lot of travel. Also you tend to find that because Product Management is that single point of contact for the product, if you're working on something significant or important to the business, and that business is based somewhere else, you'll spend a lot of time going somewhere else. One year in Sydney I did seven round trips to San Francisco, which is 14 hours each way. So I had a lot of frequent flyer points, it was great.

As I mentioned a lot of Product Managers go and start their own company. In fact Marissa famously said in an interview once that for any given Associate Product Manager cohort at Google, she expected only half of them to still be there in a couple of years time, because by definition, these are the kind of people who aspire to run their own company. If you do that, but you perhaps don't have that great idea right now, Product Management gives you exposure to all the different aspects of a business, which is a really great place to get a grounding, the foundational stuff you need to do that.

OK. Let's get down to the numbers. How much do you get paid? So this is based on a survey, admittedly it's a little bit old, it was done in 2013, but I've updated it based on inflation. It's still the best numbers that I've found. These are median numbers so you wouldn't expect to necessarily go in on this salary, but you perhaps spend three or four years here and then work your way up. I mean you can see it's a pretty good trajectory. It's certainly a valuable role. And also this is U.K. salaries. In the U.S., particularly in the Bay Area, you get paid a lot more, but also your cost of living is also significantly higher, so it all comes out in the wash.

OK, so that's why you might want to become a Product Manager. Now, how would you go about doing it if you're interested in doing it>

So I mentioned that many of the big technology companies have actual graduate training programs for Product Managers. So specific processes by which they find people like you, bring them in, and then train them up. Google I was surprised to find doesn't actually have a dedicated website for the APM program but they do have a student website. Facebook have something called the Rotational Product Management Program, which is specifically for graduates. And again they cycle you through a number of teams, and potentially through a few offices, and get you started. Yahoo! So Marissa took the APM program to Yahoo! when she went there so they have a similar thing.

Microsoft, a little bit different. So you have to be a bit careful with Microsoft because the role "Product Manager" at Microsoft is not what we're talking about. It's more Marketing led. They have a role called a "Program Manager" which is much more similar to Product Managers elsewhere, so if you're looking at Microsoft look for Program Manager. I feel obliged to mention that I did look at Amazon and I couldn't find an equivalent program so I didn't put it on the slide, but I will be chasing them later to find out if they have anything similar. I know that I've had Product Managers from Amazon apply for jobs that I've listed so I know they exist, but I'm not sure whether they have a training program.

But if you don't want to go the big company route, you want to go the small company route, here's a few places I would look for roles at smaller companies, at startups and so forth.

Work in Startups is a funny site because it looks like something out of the late '90s, early 2000s, but actually it has a lot of good positions on there and we had quite a bit of success recruiting from that site. AngelList is the techies hot trendy place to go and find jobs if you like, so that's also a good place to list.

I was a bit hesitant about putting LinkedIn on here because LinkedIn is a bit of a nightmare. It's got everybody on it. It's got everything on it. It's kind of hard to use. The one thing I would say about LinkedIn is that it makes it almost too easy to apply for jobs. You can just go "Yeah, that sounds interesting, I'll have that one and that one and that one", and so as a recruiter I can tell you that you get tons of applicants off of LinkedIn, but very few of them are actually good quality applicants. So if you find jobs on LinkedIn that you think are interesting, then make a bit more of an effort to stand out from the crowd. Try and figure out who's recruiting, maybe connect to them on LinkedIn, send them a personal message. Just do something that says "I want this job, I'm not just applying for anything".

Mind the Product are an organisation that organise Product Management events in the U.K., and abroad now as well. Really good bunch of people. And they've started a little jobs board. It's not that active yet but I think it's growing.

OK, so we're going to talk a little bit about how you should craft an application based on my experience of receiving them. Some of this advice actually extends to other roles as well, but I thought it might be useful to give you the perspective from the other side of the fence.

So, CVs. I'm not going to tell you how to write a CV. There are a million people that can do that. The one disadvantage that you have as a group is that most of "The usual stuff", your educational background and so forth is very very similar from one candidate to the next. There's really not much there that tells me anything useful. So what I care about on your CV is do you have any relevant skills, any relevant experience? And you might say "Well obviously I haven't done Product Management by this point", but if you think back to that list of traits, do you have anything that demonstrates those kind of traits? Have you organised events? Have you spoken at meetups? Have you done charity runs? Anything that just says "I am someone who does stuff, who gets stuff done, and is passionate and enthusiastic".

Cover letters. You would be horrified at how bad cover letters in general are. It's shocking. So first and foremost, before anything else, just make sure that it has reasonable written English. I could not believe how much bad English I got. And you might say "Well that's a bit petty" but the problem is that as someone who's hiring Product Managers I'm looking for someone who's going to come in and review documentation, and draft copy for emails, communicate with partners, even just specify what the labels should be on buttons. I need to know they can do that without me having to copy check everything that they're doing. So I took a zero tolerance approach to bad English. Get someone to proof read it if necessary. Personal bug bear. Don't use ampersand symbols in the middle of prose sentences. Thank you.

Don't make it too long. I got some that were massive, like essays. Keep it succinct, keep it eloquent. Don't just reiterate your CV. What I mean by that is that I got a lot of letters that said "I am good for this job because I've studied this here, blah, blah, blah, blah, blah" and it was just cut-and-pasted essentially from their CV. What I really want to know when I look at a cover letter is why are you right for this role, and why is this role right for you? Tell me something about who you are, about your motivations, about why you're enthusiastic about this. And obviously it's a given that what I'm saying is this should be a tailored thing. Don't just create a form cover letter and send it to everybody. I want people who care enough about this job to have actually put some effort into applying for it.

This is kind of obvious. I won't dwell on it, but essentially since you started applying for jobs you now have a professional identity online as well as a personal identity, so think about that. I'm not the sort of person personally that goes and checks your Facebook history. Some people do, but I think that's a bit unfair. But there are some things which are clearly quasi-professional in nature that you should be conscious of. So I will go and check your LinkedIn profile. I was really surprised when I was looking for a job a year or so ago how LinkedIn is just the only tool that recruiters use. And so, make sure you have a LinkedIn profile, make sure it's up to date, make sure it matches your CV. Surprisingly that wasn't always the case.

If you've got a website, great. I would say that the last few things on there are not about me looking for reasons not to interview you. Actually they help your case. If you've got a website, it looks good, it's got some interesting content on it, or if you've written articles, or if you've spoken at events and there are videos online, this is all good. The more the better basically.

OK, so let's assume that you send me an application and it looks promising so we're going to set up interviews. What sort of interviews might you get if you want to be a Product Manager?

This is a very very simplistic list of the kinds of topics that will be covered, if you go for a Product Manager interview. Certainly at the bigger technology companies they have a very structured process. So for example at Google these days they do a phone screen, at least one maybe two, and then they'll do at least one Product interview, one Analytic interview, one Technical interview, and then one more across the board senior level interview. Each of those are about 45 minutes, something like that.

So I'm going to talk about these in a bit more detail. I'm going to go into some tips on how to get through an interview of that type. Before I do that, some general tips. Again, probably not Product Management specific, but worth mentioning.

Firstly, don't panic. Don't be afraid of dead air. When you get asked questions just take a breath. Think about them before you get stuck in. Ask lots of clarifying questions. Generally speaking, if you're interviewing somewhere good, somewhere that respects their employees and wants you to have a good experience, they're not trying to trip you up. But it is often the case that they want to see whether you explore the space of the question. Are you actually just taking it at face value or are you digging a little deeper to understand what they're getting at, what they're looking for. I'll give you a few examples in a minute.

As I mentioned, don't be afraid to say "Can I have a moment to think about it?". That's absolutely fine. Be careful about jumping to conclusions, or making assumptions about the question, or about the context. So check your assumptions, run them past the interviewer. Which also relates to something else on the slide, which is, have a conversation. Don't just give an answer, sit back, and shut up. Engage the interviewer. Because they're not just trying to find out whether you know certain things, or whether you can do certain things, they're trying to figure out whether they want to work with you. Are you going to be interesting to work with? Are you going to actually spur good constructive conversations.

Read the interviewer. What I mean by that is every interviewer is a little bit different. Some are better than others. But try and pick up, do they want more detail, are you beginning to run on a bit too long? Are you going in the right direction? Just try and be tuned in to the interviewer and how they're reacting, and how they're trying to steer you.

Use the whiteboard may seem weirdly specific and petty but it's a general rule. Someone who comes in and just sits there, at the desk the whole time, and just answers questions is not as good a candidate as someone who stands up, grabs a marker and gets stuck into the whiteboard. Think out loud, show your workings as they used to say at school, do it up on the board. And lastly, as I mentioned, they're not necessarily trying to trip you up, they're actually trying to give you an opportunity to demonstrate what you can do, so take those opportunities. If we throw you a bone, grab it and run with it. Show your strengths.

OK, so, let's talk a little bit about some example... the sort of things you might get in a Product interview.

So, Product interviews are about your appreciation for Products in general. Do you recognise a good one from a bad one? Can you think about how you might go about designing or developing some product to solve a particular problem? And you might get some softball questions at first like "Suggest a product you've been particularly impressed by and tell me why", but then you'll probably get stuck into something a bit more concrete. And this is an example of a question I was actually asked in my Product Management conversion interview when I applied to be a Product Manager at Google.

And so obviously there's a wide variety of different types of these questions you could be asked, but a few basic guidelines is the best candidates are the ones that start with the user. So, if I were to say to you "Design me an app to help me find gluten free bakeries in my nearby town", some candidates will just go straight into "Well I'll have a map here, and a list of places, then we'll have some reviews, and yadda yadda yadda yadda". But the best candidates step back and say "So, what do you need, when will you be there, why are you not being served by existing tools? Let me understand you as a person, and then we'll figure out how to solve these problems".

Start from the user. Empathise with their needs. Figure out whether there are any constraints around the problem that you should be aware of that haven't been explicitly specified. Again that's a bit about exploring the space. And then lay out the requirements. In other words say "These are the problems we're going to try and solve here", before you then go and try and solve them. And solve as simply as possible. All I mean by that is I'm not impressed by these elaborate overly complicated solutions. I'm impressed by the simplest quickest solution possible.

One thing I forgot to mention when I say "and select one as needed". Sometimes you'll find yourself in a situation where you're being asked a question where there are potentially multiple audiences that this service, whatever it is, could cater to. Specify them, and then pick one. Don't try and do an answer that serves everybody at once. Just say, "OK, and for the purposes of this answer I'm going to focus on this audience". And then go from there.

OK. Design sense. There are a bunch of different ways of doing this but a very common approach is just for the company concerned, and I've done this, to take a particular page on their website, or a particular part of their app, stick it in front of you and say "Tell me what's wrong with it, tell me how you can make it better". So the important thing in that situation is to look at what they've given you and take a moment to just figure out what is it I'm looking at? What is it for? What behaviours is it trying to facilitate for the users, and also I said "or encourage" there. What I mean by that is what is the business goal behind this? What does the business want me, as a user of this service, to be doing here?

Again, what constraints was it designed under? What I mean by that is find out, when was it built? And why was it built this way in the first place? If you look at, for example, one part of our website, you'll see that there's a list of all the different companies that you can invest in on Crowdcube. And each item takes up a third of the screen. And if you've got a lot of companies listed it's really really long. And you might think "Well, that's a bit strange, why is it this massive long list?". Well that's because when it was built the company was far younger, far smaller, and we only had four or five companies on the platform at any one time, so we needed to make them take up space. They couldn't just be little boxes in the corner. But times have changed, we've moved on, now it's not fit for purpose any more. So taking that example, taking that question of what was it like then and what is it now, also what will it be like in another few years time? Plan ahead.

And then at the bottom, what should be removed? So this is so simple but so often overlooked. There's often an assumption by candidates that when they get these problems, that everything on the page is sacred. They can't possibly take anything away. And therefore they have to just design things that just tidy things up, move things around. No. Think about, is any of this useful, is it actually used? Do we need it? Would the product be better if we actually tore it out? That's impressive. Someone who says that to me, "This is pointless, you should get rid of that". Well done, you're absolutely right.

OK, Analytical skills. This is a bit of a weird grab bag, but essentially it's about your ability to take problems and break them down. Your problem solving methodology if you like. And often you'll get what are called Fermi Estimation questions. This is the basic idea that I will ask you a question, I will ask you to estimate something when you have no data available to help you do it. Stuff that you could just look up on the internet most of the time. But the problem is more about how you go about solving that. And it turns out most of them are more than doable if you just step back and think about it a little bit. Start figuring out what are the different factors that will influence this. So to take this example, you might come at this from the demand side. How many people are likely to be going to the cinema, and how many cinemas will they need? Or you might do it from the supply side. What are the necessary occupancy rates of a cinema in order for it to stay in business? Both of those are perfectly valid approaches, and they should give you approximately similar answers.

The task here is not to get the right answer. And you are likely not going to be judged based on whether your answer was closer or further away than the next person. It's about the approach. It's about how you break it down, so the thing to do here is to be very very explicit about that. Don't do stuff in your head, at all. Just say, "This is the way I'm going to go about it" and write a pseudo-equation on the board that says "I'm going to figure out this, and then I'm going to multiply it by that, and then I'm going to divide it by that, and then I'm going to add this". And then break those things down. Do we know those things? Until you get to a point where it's like "OK, I'm going to estimate this based on the limited data I have. The fact that I know there are 65 million people in the U.K." or something like that.

And at the end, just double check. I was once... I was training someone actually, I was giving them interview training for a Product Management role, so we were doing a few of these questions. And one question I asked, which you will never get asked in an interview because it's been discussed to death on the internet, and that was why it was good for training, because I knew it wouldn't come up, was... I was in the U.S. at the time, and the question is "Estimate how many planes are in the air over the U.S. right now". And he went through this model and he came up with... no sorry, how many people are in the air, and he came up with an estimate of one hundred million. And I said "Think about that for a moment". And he said "Is it a bit high?". And I said "How many people live in the U.S.?", and he said "Three hundred million". "So you're telling me one in three people are in the air right now?". No. So just double check your working as it were.

OK. Technical skills. So technical skills is a little tough because it really depends on the interviewer. And I know that sounds a bit of a cop out, but most large technology companies will have an Engineer interview you, and if they've been well trained, they'll know that the task of an engineering interview for a Product Manager is not to grill you on algorithms and CS theory. So what they should do, and hopefully by now most of them do, is ask you questions that test your ability to communicate with them as an engineer. Because that's the core skill of a Product Manager when it comes to working with Engineers is are you able to maintain a high bandwidth conversation with an Engineer about technical topics?

So, essentially they might ask you how to troubleshoot something. They might ask you how you would design something. I sometimes ask people to tell me what the technical challenges would be of rolling out seat back entertainment on an intercity train. And so you can talk about buffering, you can talk about whether you want to put the content on the train, you can talk about whether you want to stream it. If you stream it what challenges are you going to have? Various other things like that. But the point is do you have enough of a technical sense to have these conversations?

It used to be, until very recently, that Google and a couple of other companies would only hire CS graduates into Product Management roles. And fortunately everybody's now realised that that was a stupid idea because a diversity of different skills and opinions is actually hugely valuable for a team. And so the strategy around these technical questions has changed a little bit. But one thing I would say is do a bit of homework beforehand. Figure out what this company is, what technology they use, and what they therefore might ask you about. If you go to Crowdcube right now you'll figure out quite quickly that we're a pretty web centric company. We don't have a big mobile app yet, so we're a web based platform. So it's likely you're going to get questions that are more focused on web related technologies in a technical interview with us.

OK, strategy. Last one. So this is really about, can you come up with a business strategy around a product? Can you think about how to make it successful as a business. And so, often someone will take a well known product like Facebook Messenger, which doesn't necessarily have an obvious monetisation strategy, and ask you to figure out what that might be or figure out the opportunity side. And the thing to do here is, firstly identify where the value lies in the product. What I mean by that is not the value to the company but the perceived value outside the company. Where do people recognise that value to be? Is it in the service they're providing? Is it in algorithms and technology that's been developed in the infrastructure. Is it in data that you've accumulated? Is it in the audience that that technology gives you access to? And I'm sure there are other categories as well. Figure out where that value is, because that's what people often pay for, so that's what you need to identify.

I once asked someone to come up with alternative monetisation models for Wikipedia. And what you tend to find when you ask that question is some candidates will just go straight to Ads, because it's easy and obvious, but it has some clear downsides in terms of editorial independence. But one candidate, the best response I've got... what you tend to find then is the candidates that do better tend to be the ones that focus more on the data that Wikipedia has. How would you syndicate it, how would you license it? But one candidate said "Actually I think the most interesting data that WIkipedia has is not the data in the articles themselves, it's the usage information based on the usage patterns of their users. It's the information they have about what people are reading and when they're reading it". So, they were talking about the ability to track up and coming news stories, or trends, or weather, or things like that. That was a really interesting answer and we had a long conversation about that.

Also, don't get hung up on one approach. Scattershot, just come up with a bunch of different approaches, let the interview decide if they want to explore any of them in detail. And also, show some awareness of where this product relates to the broader strategy of the company. So for Facebook Messenger, their goal as a company is to connect the world, and so if you come up with a strategy, if you propose a strategy that was explicitly in conflict with the core business, that's not so great.

OK, so, I've talked a lot about interviews, and we're almost done, I promise. So, practice. There's this great site called thepminterview.com. It just fires a random Product Manager interview question at you and times how long it takes you to answer it. It's actually a really good site. It was put together by someone who built it for themselves actually, to help them practice. And it will also give you a better sense of the sorts of questions that you might get.

So, I just want to say something that I think is really important, because I know in your situation where you're graduating, you're trying to find a job, you want financial independence and all the rest of it, that you might feel like it's just about finding something. It's about being selected. But actually it's as much about you selecting the company as it is about the company selecting you. And this is really really important because companies will try and lure you in with promises of all sorts of great things. It could be food, it could be gym vouchers, it could be table football, it could be on-site massage, whatever. And that's all very well and good, but ultimately you will be at your desk, or something equivalent to it, 8 hours a day, 5 days a week, 48 weeks of the year, and there's only three things that will actually make the difference between whether you enjoy this job or not. And it's not the free food, and it's not the massages, and so forth.

It's just are you working with people you like? Do you enjoy the work you're doing? And is the company culture positive? In other words is it a culture where people are respected, where people are well treated, and so those are the three things that you need to get to the bottom of when you're considering whether to work for a company. And the interviews are your opportunity to do that. So, while they're asking you questions you should be also be judging them on, do they seem like good people? Are they treating you well? Does this seem like a good environment? What work am I going to be doing? Does that sound interesting and fun? That's the stuff that will actually matter to you on a day to day basis.

OK, so this is a bit of a cop out actually. This is the website I am putting together to go with this presentation. This website does not actually exist yet, I'm sorry. I didn't manage to finish it, but if you give it a few days, then hopefully a copy of this presentation, and a whole bunch of supporting information about articles you might want to read, books you might want to buy, other videos you can watch. I've got it all stacked up, I just need to publish it on the site.

And that is that. Yes. Thank you.