 So, today my guest is Ryan Hoover. Ryan is the founder of Product Hunt, Product Hunt.co, which is a site for discovering new products like mobile apps, websites, hardware projects, and tech creations updated daily and curated by the Product Hunt members. Welcome, Ryan. Hey, how's it going, Felix? Good. So, you obviously have a time's assessor right now with the recent round that you raised and just over the past year, I've heard so much about Product Hunt and the things that you're doing, but I kind of want to wind the clock back a little bit to the very beginning where you first kind of started your startup life as a product manager where you are director of products at Playhaven. So, what was Playhaven and what were you guys doing over there? Yeah. Well, actually, if you go back a little bit further, I was my first role in Product Manager was at a previous company right before that. It was called Instant Action, and it was in PC gaming space. I actually kind of fell into the role of doing marketing straight out of college, and then my boss was a VP of Product, and so long story short, I ended up moving into Product Manager and learning on the job. I had no idea what I was doing. It was kind of embarrassing if I looked back at what I was actually doing and learned along the way. So, from there, I joined Playhaven. It was the first PM there for maybe a year and a half. That was the only PM, I have to say. And then same thing, just kind of learning on the job. So, college doesn't, my college and most really don't provide direct kind of education or guidance on Product Management because it's somewhat of a vague role, and it varies by company. So, that's how I learned is just getting an opportunity, fortunately, in the actual role itself. Yeah, that seems to happen a lot where people kind of just fall into this role because like you were saying, there's really no track to get to a Product Management job using the kind of traditional way of going to school for the particular concentration or major and then coming out and getting a Product Management job. It's not that straightforward. So, once you first got that transition to Product Management, how did you get the second job at Playhaven? What were they, were you doing kind of to market yourself and get a position as a Product Manager at a different company? Yeah, so I was fortunate in that I transitioned from this action to Playhaven and the CEO actually, Andy Yang, was a joint in Playhaven. So, I worked with him at the previous company and that's how we got connected. And then, you know, he knew that I had this interest and this talent in the Product Management industry. So, he gave me a shot. You know, it was still pretty great. I think I was only at PM for about a year before I moved to Playhaven and he took a chance on me and super fortunate for that. So, you know, really it's just like most businesses, there's also an element of connections and relationships that you build. And it's really testament to how important it is to treat people fairly and good and build relationships in the network. And that's how I got my role at Playhaven really. Yeah, that makes sense. You know, when you first got the role at Playhaven, what were some skills that you think that you, that were very, that is very important for a Product Manager to have that you had to kind of develop on the job? I think there's a number of them. I think part of it is empathy, is the recurring theme that probably every single PM would say at some point, is just understanding how do you understand what people want and how they feel and how they react to things and having some empathy for other people. It's really important especially if you're building a product for someone else. So, at Playhaven it was in the mobile game space and we were building tools for mobile game developers. And you know, I was not a mobile game developer, I'm not today. And so, for me I had to really understand, okay, what is their day that they like? What challenges they have? How are they being measured? And you really find that stuff out by observing behavior and talking to mobile game developers. And so, empathy is kind of a recurring theme and something that you just need to understand and have an appreciation for. And to go along with that, you kind of have to be humble in a way too. You have to also realize that your assumption is probably not correct, as confident as you are. So, it's good to have confidence but also to verify those assumptions and talk to customers and look at data to understand that, you know, are you actually building something that people want? Yeah, that makes sense. What was your day to day like? I know you're saying that you spent a lot of time actually talking and observing the customers. Does that mean that you are going to their offices every day? Or, you know, what does your day to day consist of? Yeah, it played you that it was, yeah, it was a combination of many different things. Part of it was, part of it frankly is intuition. So, it's actually not talking to customers because you can't talk to them about every single thing. So, you have to have some intuition on how this interface should look and how it should work. So, there's that piece. But then in terms of getting actual quantifiable data, there's looking at the methods, what pieces of the product are people using is one piece of it. So, over time in our product, we had this dashboard with many different features. And something that we did do at one point is we just looked at, okay, what are people actually using? You know, which tools are they using out of these 10 that we created? And that gives you an understanding of, okay, why are they not using these other two tools? Is it because they have no use for it? Is it because it's too confusing? Is it because they can't measure the output and therefore they won't use it? So, you start building these hypotheses around why they're using some things and why they're not using others. And you can take that information with you when you go talk to customers. So, I would go to big companies and small companies like Glue Mobile, for example, we would go to their office and talk with some of their VP's and some of their producers directly about Playhaven and also about their own personal goals and what they're trying to achieve. I would also talk on the phone with some indie game developers, some guys that are literally a guy in the garage building a game. So, you get a variety of opinions and perspectives. So, it's a combination of data and qualitative feedback that you get. I see what you're saying. So, you first do the research, do the data in your office and then go out and talk to the customers to help kind of validate those assumptions that you came up with based on the data. And also, it's kind of the context when you're having the conversation so that you're not unaware of how they use it, which you can easily get by looking at the data. So, what other tools do you use for you to do your job as a product manager? Let me think here. So, we had an internal tool that we used for looking at data and doing some data analysis that we used at Playhaven. And then we used some project management tools. At one point, we were using Pivotal and then we drew it to pretty large size teams. So, we moved to Jira. So, we used kind of the standard tools in that sense. You know, I haven't found any particular eclectic tool that other people don't use that have been super valuable. I mean, we use Gmail, we use Google Docs, we use pen and paper. Pen and paper whiteboards are oftentimes the best thing for collaboration and that kind of thing. So, nothing too surprising, honestly. I mean, if you know of any cool product manager tools, let me know because I haven't found anything that's been demonstrably impactful in making my job easier. Yeah, it seems like there are some kind of new tools that are coming out there that are almost specialized for the entire product management job. I'm not sure how well they're playing out yet, but it does seem like there's some interest in the space of making the job for a product manager easier. Were you using any tools for wireframing or any apps for that? Yeah, I personally like Omegraphle and I know it's not the most popular tool, but I've just become really familiar with it and I know the shortcuts and I have stencils and for me, I can wireframe things pretty quickly in Omegraphle. Other people use Balsamic. Some go straight into Sketch and others. So, I use that. I also will force myself to avoiding digital tools like that for wireframing though and I go straight to Lightboard or Post-it notes and for that, it makes it easier to sketch out ideas faster and since it's so constrained and since you can't change or edit your pen, it forces you to be very succinct and quick in sketching out your ideas. One mistake I've made is I will use something like Omegraphle and I will for whatever reason start being pixel perfect in my wireframes and for some things when it's early on, it's just a waste of time, but I'm such a perfectionist that I will just spend such a time, you know, aligning things correctly when really it's not important. Yeah, sometimes tools can definitely consume your time when one is not really moving the needle. So, you know, like you were saying before, there is a lot of collaboration when it comes to things like, you know, working as a product manager and also while you're doing things like wireframing, you know, you need designers or other folks in the room. You know, what was the team like that you're working with and what kind of roles do they have and how did you work with them? You know, so this is actually something that people need to be aware of that maybe aren't in a product manager role or maybe not in startups is that first off, product manager role varies by company, but it also varies by team size. When I joined playing, we were around 10 people or so, and it was just me and the master engineers for the most part, we didn't have a designer. Well, we actually had a visual designer at one point, but you know, it was me doing the wireframes and UX and everything, along with general product management role. And then we grew and we grew to 100 people and we started building up multiple product management teams. We had a UX designer, a visual designer, and that certainly changed the way that we worked because now we had more resources to build out more fully fledged features, you know, and do more research. Whereas before, it was just me making some quick wireframes, engineers building it. And you know, there's pros and cons to both approaches. The pro is that you can move relatively fast with few resources, few people, but you may not be coming out with the best product because you have someone like myself doing, you know, all of the work when it comes to UX when, you know, professional, that it does this full time for living to probably come out something better. So it really varies in that you kind of have to adapt to those different roles. Like when you're in the beginning and you're just building wireframes at the PM and you're working with a small team, it's pretty loose and there's relatively usually very little process and that's a good thing. But then when you're bigger, you need more process and you have to plan ahead more. You have to communicate with a lot more people. Like communication is probably the most important skill set for a product manager being able to talk with a lot of people and that gets back to empathy. Being able to empathize with an engineer and with a designer is really important to building a good team, but also making sure everyone's on the same page. Yeah. It's going to jump to that next. You know, once you're, when you're kind of a smaller team, the communication issues that you might have aren't really enlarged. You know, they're not that serious, I guess, because the team is so small that you guys can hear each other's conversations. But once it grows to 100 people or more, those communication kind of issues that you might have worked out earlier, then really start to show themselves. What would if you could give a tip or number one tip that you have for working with, like let's say developers and engineers, what would it be? I would say, number one tip, I'd say, I guess, err on too much communication rather than under communicating. You don't want to, so the one thing that people that are not familiar with, with product manager or maybe not familiar with engineering, that they make this and say, they go up to an engineer and they say, hey, can you build this thing? Can you add this thing? Like this happening? I mean, they don't have this empathy or this understanding that they have a lot of other things going on when you talk to an engineer. A lot of times they're headed in a different place, and you immediately break this spider web of code that's in your head when you interrupt them. And then you can also really frustrate people when you're like, okay, here's this new thing. Can you build it? And you don't think ahead. So as a team get bigger, you want to kind of have some level of communication in the process of that and understanding that, you know, it might seem easy and it might be easy, but don't just throw things on engineers. Like you got to give them some warning, to an extent if you can. Same thing for designers, but I feel like it's even more prevalent with engineers, the way that they operate and they typically like to work. Right, that makes sense. And what about when you go talk to clients, like what are some kind of tips or things that you keep in mind when you go and, you know, talk to them? Do you like do things like conduct customer interviews or do you like testing or anything with your customers when you go meet them in person? It varies, depends on what we're focusing on. Sometimes we're exploring new product ideas, new feature ideas, and we start with not, here's this cool idea, aren't you going to love it? That's a bad way of trying to understand what they actually need, but we do start exploring questions around that space. An example could be, you know, we have a prompt idea that we'll increase engagement, and so we might start asking questions about that, like how do you measure engagement, or how are users currently engaging with their products, and start pulling out some themes. Then maybe towards the end of that conversation you start talking more specifically about, okay, here's this thing I have, this idea we have, this feature. Maybe we'll show them wireframes, maybe we'll show them a prototype, maybe we'll have them play with it, and we'll sit back and watch and see what they do. So it kind of varies. Usability tests are really helpful. At some point you don't want to introduce them to early in conversation like that, but when you get to that stage, having them just use a product and having to struggle with it, because that's inevitably going to happen most likely, and it's super painful, but you'll learn a lot when you see them playing with your actual prototype for your product. Yeah, and once the product is built, do you have any kind of recommendations or any rules of thumb or any strategies for making sure that a new product release is launched successfully? So that can fit within the role of a product manager. Sometimes it's not always, sometimes it's kind of the role of a product marketing manager or just marketing team in general. It's such a contextual question. It really depends on what you're building. Are you building a new feature for an existing audience? Are you building a brand new product? And so the approach can be completely different. I think, yeah, it's kind of hard to answer that without having a certain frame or context. If it's, let's say, an existing feature, then a feature to an existing audience, like let's say it plays, and when you release a new tool, then for us it's communicating, okay, here's what this tool is, here's what it does, here's why it's important, and why you, in communicating along with what their goals are, why it will help them do better in their job. That's communicated through email, it's communicated through the actual product itself on the dashboard, let's say. It's also communicated throughout the company, because at play even we had a team of account managers and salespeople too, so it's important for them to understand, this is what it does, here's how you communicate externally, and they can then do the sales and education on new features. That makes sense. So when you are a director there, I'm sure you've came across a lot of product manager applicants and folks that wanted to get into the role. When you're interviewing someone for a product manager job, what are some things that you've seen applicants come through with that kind of blew you away and made you think this is the perfect person to join our team? Yeah, it's a hard one. I guess it's kind of hard for any role. I mean, we're hiring also at Prolix on right now, and the best candidates are people I've already worked with, and I know are good, otherwise it's through referrals oftentimes. So play even rather, that was similar. A lot of the hires that we got were through referrals or people that hadn't worked with them before, and actually a lot of the people from Instant Action, the previous company I was with, joined play even early on. So I think maybe we met over 8 or 10 people from Instant Action at one point. When I do see someone that I don't know or doesn't have a referral necessarily, I typically look at what are they actually done, and I will also stalk them online. I mean, I'll look on Twitter. What are they talking about on Twitter if they're out there? They have a blog, what are they writing about? I've written about this before, but blogging is one of many different ways to frame yourself, but also communicate your ideas. And since a product manager doesn't necessarily do design, they don't do code, they don't have a profile you can point to. Blogging is a really good way to communicate how you think about things. What are some other ways they can do that? Because I know you did write a short blog post called Anyone Can Ship, and it's about creating side projects and how you don't need to be technical or a designer or a coder to create a side project. What are some other things that an aspiring product manager can do outside of work with a side project to look attractive to a hiring company? Yeah, I'm very, I encourage people to do side projects, and you can do many different things. Of course, it could be an email newsletter, that's how products are actually started. It could be meetups, you know, you could organize meetups in your city around startups, or maybe some other category of interest. It could be a podcast. There's many different ways of effectively trying to create value in some way, and or it could be a product itself. Maybe have a cool product idea and you just want to try it out. That's actually a good way of getting into product management. If you have no opportunity to get a role in as a PM, which is really hard to do if you don't have experience, one way is just to build some sort of product on the side. What you're doing by that is demonstrating your product sense, your ability to execute. There's no reason that you shouldn't start something like that. You don't necessarily need the code to do that. Figure out how do you build something simply and how do you start measuring and getting some feedback on why do people care about this thing, and oftentimes it doesn't require code in the beginning. Right, that makes sense, and I've seen some people go to the lengths of taking their idea that they have and just hiring freelancers to build it for them, because I think that kind of shows your ability to manage resources, because it's your own money and time that you have put into it, and it shows that you can deliver something that has a value and that you are able to manage the entire process, manage another developer, or maybe a couple of developers, and manage the resource. I think it speaks a lot of volumes about the kind of performance that you can have on the job. I've seen some cool stuff like that happen too. You also actually wrote another blog post that I liked that was, I think it was right after you made the jump outside of Playhaven and you were questioning whether you should learn how to code because it seems like such a big movement right now. You settled on the idea that you shouldn't because there's the opportunity cost that affects you because you could be spending your time doing something more valuable that's more impactful for your life. In general, the question I have is, do you need to be technical or how technical do you need to be to be a product manager? Yeah, it's kind of like a portion of a lot of my interest is it depends. Some roles at the time you need to be an engineer to be able to communicate what you're building and that's just a requirement. Others, you need to be more maybe design centered. You may not have to be technical at all, but you need to be very conscientious of like UX and how people think. So it heavily varies honestly. It depends on kind of what type of company you want to join. Yeah. So one last question I think that is kind of in mind of a lot of aspiring product managers when they look out in their career like five years down the line is, you know, now that you've kind of found and recently raised a series of investment around product hot and things are going really well for you at your new startup, do you find that you rely on your product manager skills that you picked up on at Playhaven in previous roles a lot and which skills specifically? Yeah, I think it's hard for me to articulate the exact skills sometimes. I think it's part of it is over time to start learning how to speak with designers and developers. You start working with more of them. Some people just operate differently. So it gets back to human empathy and having an understanding of how people work. So it's kind of the people soft skills that you learn. There's the hard skills in terms of like how do you look at data and what should you measure? I wish I had a better way of articulating like the five skills or something that you should have as a product manager. But it's just a lot of learning on the job. It's a lot of being creative but also curious too. Like product type was not the first experiment I did. I've done many different experiments and learned along the way doing those whether I know it or not. So I think it's sort of having the right frame of mind and being open to experimentation and curiosity and continually doing that over time that you'll learn things without realizing it. Yeah, I agree. I think you're saying experimentation and just kind of having the frame of mind to just take action and try things out and see where they go. I think that's an important way to A, get a job as a product manager and B, be successful in product manager. Or when you decide to move on from their start zone company, it's definitely a mindset that is I think important to have. So thanks so much for your time, Ryan. I think that you provide a lot of great information and actionable tips for anybody that's either just starting out in their product management career or beginning the process. So you have a blog, ryanhoover.me. Is there any other ways that folks can kind of reach out to you or follow your story? Yeah, yeah hit me up on ryanhoover and I am with him so if you follow me you'll probably see me multiple times per day. For better or for worse.