 So I've been in product for a year and a half now. Now, I'm certainly no expert, and that's why I've called this talk 30 product management things I've learned. These aren't lessons, learnings are not lessons. Very important to note that about this talk, being in PM for a year and a half at HubSpot. I've gone through two different product teams. I've gotten a promotion in there. So I've seen like a little bit of the product side of the world, but certainly not all of it. There's so much to learn, and I'm sure next year this will look like 300 product management things I've learned. So these are all learnings that I've gotten in the last 18 months or so in product at HubSpot. I did cross out in 30 minutes, because I was told I had a little bit more time. So I'm not going to hold myself to that. I could if I wanted to, but we're going to be a little more loose than that. So this format will be pretty rapid fire. I basically want to go through line by line, 30 things I've learned as a product manager. Learnings are not lessons. Final reminder. Let's get into it. Product development. This is the first theme that I want to talk about here in the talk. The first thing I've learned in product management is that product management is not a science. It's far from mathematic. It's far from calculated. Everything you do is constantly changing. It's not very scientific in general. That's really the first thing I ever learned about product management. As your day-to-day is super ambiguous, what you're going to do, who you're going to talk to, who you're going to meet with, it's always changing. At the same time, product development is a lot like science. So I'm sure you all, I welcome everyone new to the room also. Product development is a lot like science. So I know that back in second grade, third grade, you learn the scientific method, right? You identify a problem, you form a hypothesis, you gather data to validate that hypothesis, you run a test, and that's a lot like what product management is. So while it may not be science, it's a lot like science. Let's keep that in mind. The third thing I learned about product development is that bringing something to market, taking a product and giving it to your very first customer is actually the beginning of a product's life cycle. It's not the end of it. So although there are months, sometimes years that lead up to actually delivering a product to the market, giving that to a customer, getting your first piece of feedback. From what I've experienced, that's where things just are actually getting started. Now, you'll be talking to customers before then, you'll be working on product development things well before you actually reach a customer. But the product itself, it's life doesn't actually start until customers grab hold of it. The next thing, small features for very specific audiences yield really big wins. So one of the earliest things I've learned is like you can't boil the ocean, right? We've all heard that term. The more you try to solve for and the more broad you get with your product development or your product strategy, the more likely it's likely going to flop. You likely have a pretty diverse audience, people, different people who use your product in different ways. Solving for a very specific use case and a very specific feature is usually some of the easiest ways to get the biggest wins. One of those examples that we use at HubSpot I worked on the import tool in our CRM. Now, every object in a CRM has a unique ID. We never let people import using that unique ID as a way to write to existing records. It was just something that we hadn't written in. The explosion, the customer excitement around this very specific, it was legitimately a checkbox when we had spent months on this entire flow. This tiny checkbox had yielded these fantastic customer results, hundreds and hundreds of people using it because it was designed for a very specific use case. It was designed for people who are pulling data out of HubSpot and putting it directly back in, a very specific use case and a very specific audience, and those are some of our biggest wins. The reason why those wins are really big is because they didn't take a lot of time. Big wins aren't as big if they take the team months to work on and it takes a ton of energy. Sometimes the biggest wins take almost no time. The next thing, paying down tech debt is greater than most things. I said most things because not everything, but tech debt is very, very problematic for basically your team first, first and foremost, your team, and then beyond that, everything that you all want to do in the future. So if an engineer is dealing with tech debt, it's always a pain in the side. It's something that's constantly kind of like holding them down, constantly something to think about, but once you can kind of pay that down, it frees up not only the product space to work on new things, but also the mental capacity. If you think about what it's like working on split screens, you're watching a video over here and you're actually doing your work on the main screen, it's really distracting when you've got things like tech debt that are holding you down. So if you can pay down tech debt and you can do that early with your team, so it's usually a pretty good win and that's something I've learned pretty early on. So we try to do that as much as possible. It's to pay down some of that tech debt each and every week before we go out and build new features. So next one's pretty long. And I have a very specific experience around it. It's that things break, they're going to break in software and hardware, no matter where you're developing products, don't panic. You need to give your team the space and autonomy that they need to solve a problem and provide air cover if possible. I think the most important product management learning I found here from the product point of view is to provide air cover. Your engineering team, your product design team, anybody who's solving a problem is going to be focused on that problem and that problem specifically. When things are broken, I found that the best role a product manager could take is just to provide air cover. Run appropriate communications with your customers, make sure that only real problems are getting delivered to engineering and then you're not kind of poisoning the well with consistently adding new things to the fire, kind of asking questions about the status of the updates and things like that, keeping it super clean, letting the teams, giving the teams the autonomy to solve the existing problems will help those problems get solved faster and more effectively. This next one's really similar about the small features but it's more from a macro perspective. It's that if you try to solve for 100% of your customers, you'll end up solving for zero. I tweeted this out one time and I got a very specific request from one of my colleagues and she said, this is funny to me, why wouldn't you wanna solve for all of your customers? Well, I think in very specific use cases you'd wanna solve for your customers or all of them rather. But one of the things I've learned is that you can really get caught in the weeds answering every question for every specific from every single customer. So if you have even two slightly different variables of what a customer believes the solution will be, it could add months, weeks, even years to actually shipping a product and getting it out. If you can meaningfully impact 50, 60% of your customers, in most cases I'd consider that a win. It's going to help your product move faster, it's gonna help your team move faster and in the end that 40% who you were trying to solve for, they'll probably just resolve to use this new thing or you can iterate from that point. You can iterate and keep building and keep building to actually deliver that subset you weren't solving for or deliver them value. This next one's an old favorite of mine and it's deadlines spur action. I try to do this as often as possible. At HubSpot we have real milestones that are built in. We have an inbound conference here in Boston every year. We typically like to deliver a net new product at that conference, but deadlines in general are something that I try to look for in product management as much as possible. And it doesn't always need to be like the inbound conference, right? It can be smaller deadlines, it can be end of month, it can be end of week. It doesn't always need to be something as bland as the end of a sprint or something like that. Building in like seriously meaningful deadlines for your team, for yourself, for your peers, for your leadership to point to and say here's when we're gonna have this thing by, here's why we're gonna have it by then and here's why we think this is a reasonable delivery date. Those types of things will help your team rally around an event, they'll help your team actually get it out the door and they really help everybody center around what's the highest priority, right? If you're behind deadline it's very obvious that you're behind deadline with a product. So boiling those deadlines and putting them into your actual product development and when you're planning things is something I found to be pretty helpful. This next one's a recent edition I found. I was talking to a leader on our team recently. We were debating between which products or which real priority we should solve first. There's basically a debate between two features. He had a very set view, he says we should clearly solve feature A first. Like there's no brainer in my mind that your team should be working on that. And I said, interesting, do you know what else we could be working on? Kind of paused. He's like, no, what else could you be working on? So I turned it over to him and I said, how could we prioritize a single feature if you don't understand everything that we'd be de-prioritizing? So it's very easy to say like, what's at the top of our roadmap? But it's just as important to actually lay out what's low priority on your roadmap because for everything you build you have to sacrifice something else. And that's something I learned really early on I think when I first started in product management I wanted to build every feature. It was really important to me that this got developed as soon as possible. And but there were certain low priority things but we kind of just forgot them. It's really important to illustrate those. You hear them commonly referred to as omissions but they're not always omissions or sometimes just low priorities. Our product leadership loves this one and that speed is a bug and speed is a feature. You never think about speed when you're getting started in product management. You tend or at least I didn't. You tend to think about just getting a product out of the door. You tend to think about stopping for a customer use case. You tend to think about the product marketing that's related to shipping something. But you never really think about speed. It's very rarely top of mind. One of the things I learned really early on is that a slow app or really anything slow is a bug. It's just as painful to a customer as a bug. Sometimes more painful. If page load time is slow. If just like basic interactions are slow. If there's too many clicks in an experience that is just as bad to a customer as a bug. And the worst part about that bug is they don't call in to support and say, this is slow. They don't call in and say this took me too many clicks. They just get frustrated by it. And it just continues to grind down that experience. So speed can be a bug. On the flip side of that speed can be a feature. We've done a ton of research around how making our app faster would benefit the customer. And there's a ton of research out there that say if app load times are instantaneous, if they load almost no time, then customers are much more likely to stick around. And there's entire divisions at companies that focus just on load times of apps and really getting things to the customer faster. And the key to that is no matter where you are. I know a lot of folks are testing their own software locally. They're testing it at hardwired connections. They're testing it close to where their servers are. They're closing it on local connections. Like that is not your ideal or your actual customer experience, especially if you have a global customer base. Connect a JetBlue Wi-Fi and try to load your app and see what happens. That's what people all around the world are experiencing. Try connecting to your mobile phone hotspot and then load your app. Those are different types of things that you don't necessarily think of. And I certainly hadn't thought of until I was loading up HubSpot on a plane and I was seeing all this alt text and these images rendering that were just kind of background images or maybe stale from an old version of an app. That kind of stuff kind of gets thrown by the wayside. And it's important to think of that. Test on all speeds. Make sure you're testing not only your own localized environment but really all of your customer environments. All right, so that's a little bit on product development. The next section I want to run through is things I've learned about your team in product management. And this is potentially, at least in my eyes, one of the most important parts of product management is maintaining a good team, a high performing team. So there's a lot of learnings here. This first one is a little process goes a long way. I know many organizations have many different approaches but at HubSpot we tend to lean on small autonomous teams. That typically means not so much process. And that can get carried away. You think everybody's on the same page, everybody's kind of hip to the beat and everyone knows exactly what you're building in a given day or what you're working on. A little bit of process can carry your team a really long way. And I think the best way to actually feel that from your team is ask them, what's our biggest product priority this month? What are we working on next month? What are we ignoring this month? And if they can't answer those questions, you probably need to build a little bit of process into your process, yeah. You probably need to build a little process in because that's exactly what your team is going to need. It's gonna go a long way. And if you start with a little bit, just kind of check the temperature there because most folks are gonna be resistant to it naturally. You're gonna want less meetings, less stand-ups, less updates, less documentation, that's natural. But it can feel really cool to do none of that and that's when you start to get into trouble. So I found that a little process goes a long way. Our team, we started doing some stand-ups more frequently, kind of canceled those, they weren't working so well. Yesterday, today is in Slack. Things like that that really just try to keep the team up to date. Those are the things that actually keep everybody moving. This next one is really near and dear to my heart because it caused a major issue for me is that if your team has even slightly different definitions of what you're building, it's nearly impossible to get shit done. Even slightly different definitions of what you're building. If one person in the team thinks you're building a red car and one person on the team thinks you're building a blue car, it's not going to go very well, right? Even though you both think you're building cars, they're probably built for a different customer for a different reason. Those definitions need to be crystal clear up front down to every single detail because it can get you in a lot of trouble. And it certainly did for me. If you're not actually clearly defining all of that for your team and also the why behind what you're building tends to be problematic. This next one is pure product management tactic. I've had the tendency to do this all the time and I still make this mistake and it's something that I'm consciously trying to get better at. Even reading this slide makes me think of errors that I've made in the past, but passing along bulk customer feedback and just saying like I heard this thing from a customer, it means nothing to your team, to your engineers, to your design team. It needs to be synthesized, bucketed, and it needs to be actually conveyed as to what impact this has for the customer. It's very easy to take notes from a customer call and just dump them in a Slack channel. It's really easy to take a response that you got in-app and kind of send that to your designer and be like, hey, have you thought about this? It's so easy to do and it's so quick, but it doesn't mean a lot. It doesn't mean a lot if you're not tying that customer feedback to milestones that you have already planned. If you're not tying it to previously identified problem buckets in your product, as soon as you start doing that, it starts to take on a whole lot more meaning because it can be easily synthesized and taken back and actually brought into your product in the future. This next one is about product iteration. It probably only works in software, but a team that understands every product is iterative, is emphatically more powerful than one working towards an end game. We ran into this really often on a previous team I worked on. We were working towards a Facebook messenger integration with HubSpot and very early on it was like, okay, what is this going to look like? When are we going to have our own app in HubSpot? When are we going to think about us taking over, having our own hub in HubSpot? That got us into a little bit of trouble, right? Every product, especially in software, that's the beauty of it is iterative. You can build one small thing, you can learn from your customer and keep going. And when a team can fully understand that and grasp that concept, you can build, I mean, this is essentially MVP, right? You build something small, you learn from your customer, you keep going, you keep going, you keep going. It doesn't need to be perfect on your first shipment. It doesn't need to be perfect, really ever. That's the beauty of software. You can keep going, you can keep learning from your customers and making a better and better product every single day. And if you start working towards that end game, you are going to get slowed down to no end. Things are just going to become difficult because you're going to try to fine tune every single detail, every single button, every single color, every single font. And it's just a lot of work. And in the end, you're probably going to ship something that's no good for your customer. This one is near and dear to my heart because I had a team that did this and it's a team that literally will sprint at fires and by fires I'm talking about critical situations that cause your customers a ton of pain or accompany a lot of pain is like the most powerful thing on earth. We've had weekend problems, middle of the night problems and when a team can rally around that problem and fix these customer problems like just in the name of doing right by the customer, there's nothing more powerful than that. And anything you can do to inspire to create that culture in your organization is going to be the best thing you've ever done because fires happen. And when you see a team that does this kind of thing, there's nothing more motivating to come to work, say something happened on a Saturday. Midnight, everybody woke up in the middle of the night and solved a major customer problem. There's nothing more empowering than coming in on a Monday morning, recapping what was done and then focusing on the rest of what you need to do because everybody was so impassioned by solving that problem. And when you see this happen across teams, it's even better. I've seen that happen at HubSpot a few times and it's just amazing. Somebody who left that team but still had knowledge of the code base or a product manager who maybe designed the original problem statement will swoop back in, we'll see a problem and spend their nights, their weekends, their extra time half a day solving a very specific customer problem and doing nothing else, sprinting at that problem even though they have nothing to do with it. It creates an incredible culture. This one is pretty recent and it's that an excellent metaphor can be the key to explaining a highly complex problem. So software is complex, product management is complex, metaphors are difficult, but I found that really, really drilling down with the metaphor can be one of the best things you can do. So recently I was back and forth. So HubSpot, the way that we're structured is we have platform teams and I work on a platform team, I make the HubSpot CRM and you have hubs, you have the marketing hub, the sales hub, service hub and they build more specific products for those specific personas, for sales users, for marketing users, et cetera. Now I was going back and forth with a leader in the marketing hub and we were talking about how should marketing problems be brought to the platform and it was a really long winded discussion. It was, you know, we were trying to figure out like should the hub, the marketing team be bringing problems to us, the platform team, should the platform team be in tune with that marketing persona and solving problems for them? And the metaphor that we ended up landing on is pretty interesting. It was that the Hub teams or the platform teams rather, our team, we make pasta. Everyone's really familiar with pasta, right? You can add anything to it. You can add shrimp scampi, you can add pasta sauce, vodka sauce, Alfredo and we decided that the platform teams, they make the pasta. What we do is we serve that pasta to the hubs pretty plain and the hubs, they can add whichever flavor they want. They can create all types of different dishes from this pasta that we created. And from there, that's like a really conveyable message to not only between us, between the platform teams and the hubs but also to other people, people across the organization that don't really get how two product teams work together. That metaphor alone was able to do that. Our CEO, he loves to draw obviously quad boxes but also just timelines, straight lines across the board, beginning and what's it gonna take to get from here to here. Those types of things are really good visual cues but also types of metaphors that can help you get to a really complex problem in a really simple space. This next one is the most recent one I've added here is that team happiness is directly correlated to product success. One of the things I've learned really early on in product management is if your team isn't happy, your product isn't gonna be happy and you're not gonna be happy. It was explained to me once like a three, we run triads. So a product designer, a tech lead and a product manager. It was explained to me once that like you're from the product management perspective, your product designer is your wife for me and the tech lead is also your wife. And you need to keep all of them extremely happy because as the phrase goes, happy wife, happy life. If none of them are happy, your product is going to be no good and you are not going to be happy. So keeping your team motivated, keeping your team excited and everybody on the same page and just playing happy is really what's the key I've found to bring like really, really good product success. So the final section here is about the craft of product management. This is more tactic driven, day in and day out, things that you'll find or that I've found, things that I've learned in product management. Long winded, basically write and do not have sporadic conversations. This is the most effective way to communicate anything. Clicker's a little buggy. The most effective way to communicate anything is to write it down, period. Having 15 hallway conversations, it's good. It helps move things along. You can have those hallway conversations and they can benefit your team. They can inform you but at the end of the day you need to be writing things down. If you wanna go one step further, you write it down and share it publicly with your entire organization. Don't keep a private notebook, keep something up on the public wiki, pin it to your personal Slack channel, whatever you need to do. Keep things written down and keep them public because that is actually the way that people are going to consume things, be able to reference things back and things don't get lost in translation. You stop playing that game of telephone. This one came to me after a very, very long weekend of kind of getting beat up over the product and it's sometimes you're the hammer and sometimes you're the nail. For those of you not in product management yet or looking to break in, sometimes you will feel like the champion of the world. You will feel like you've just run a marathon and that you are invincible. Other times you will feel like you just got out of the ring with Mike Tyson and it just plain hurts. It's just the nature of what I've found product management is like. It's just the way it is really. But you got to kind of learn to fight through those ups and downs. One of the things that I've found through a year and a half, a very young year and a half of product management is that in the beginning, one day I was the hammer, one day I was the nail. Towards a few months in, it was maybe weeks. I had a hammer week and I was really, really excited. But now I'm noticing those are more like months or those are quarters of ebbs and flows. So they start to become more spread out. And I think that's largely a play on the emotions you feel. As a product manager, it's such an ambiguous role. And if you start feeling like those really like tenuous, those ups and those downs day in and day out, it happens. This is a very real product problem that we were having today. I was head to head with another product manager. We could not resolve on what we should do. We had a 30 minute meeting schedule. We went for an hour. We couldn't resolve, we just couldn't do it. We walked out of the room and we had a meeting later on, tried again, still could not find a way around this problem. A little bit later in the day, we met with our mutual manager and we explained both sides of the problem. And he said, why don't we do both? It was a very easy solution. Now there's a thought that because we both wanted our way because it was how we entered the conversation. It was the thing that we aimed to get out of this outcome. There was really no downsides to doing both. Perhaps a little bit of team distraction but it was certainly manageable but neither of us thought that the entire time. It was either one way or the other but you can try both sometimes. And I think that's something that can be overlooked especially with cross-team communication or really strong opinions. Strong opinions loosely held are the good way to go here. Again, on communication. This can feel uncomfortable but when you need to communicate something important, write it down, communicate it three times and then when you do it again and then when you're tired of communicating you think you've over communicated a concept and then everybody gets exactly what you're saying. Communicate it more. Because everybody around you is extremely busy and when you think your message is heard, it's not. I've fallen victim to this trap many times. Walking into a meeting, thinking everyone read the deck that I shared with them on Google Docs which doesn't have the greatest notification system especially in a flooded inbox, right? People need to be force-fed if there's very important communication. I'm not talking about everything you've ever written or every slack you've ever sent, you don't need to follow up on those. But like when something's important, you need to communicate it until you're uncomfortable and this is something I'm still learning every day. It is a really, really tough exercise to do but I find that it's extremely helpful and you're almost never over communicating. I don't think anyone's ever given feedback that you're an over communicator to anyone in any career of all time. So I think it's a really good thing to do. When it comes to getting buy-in, evidence is greater than ideas. This is a bit of a no-brainer but it comes back to that scientific method, right? If you've got hard facts, if you've got hard data, it's going to trump over ideas every single time. In fact, if someone doesn't like your idea, the first thing they're gonna say is, what data do you have to back that up? It's simple. If you don't have that evidence and you don't have that supporting reason to actually convey an idea or to get something done, it's very, very hard to win. Python is the bee's knees. I was a non-technical product manager, still am, pretty non-technical, but I learned a little bit of Python. Why did I do that? Because it helped me self-service. It helped me do things that I was otherwise asking my engineering team for. It helped me do things that to them was a distraction. So I learned how to just basically write a simple script and then I pulled that into Tableau where I'm more comfortable and it's a safe space and I would kind of do the rest of my analysis there. But this learning is less about Python and more about being able to service yourself. Being able to spin up quick mocks, whether it be in Google Slides or anywhere, being able to do that instead of asking your designer to build those simple mocks for you. Simple wireframes, things like that. Really simple Python script, SQL, things like that. They go a long way to keeping your team focused and to keeping yourself as like, not somebody who's always on an engineering team is back for doing the simple stuff. This is a really real example of that. Sitting for lunch with five people who are close to the customer every single day will fill your notebook quicker than 10 customer calls. Mainly because in customer calls, I've found that you're looking for a specific thing and this is just a natural habit that all of us have in research. So you try to direct the conversation there and it's one-on-one, right? You only have a finite amount of time, 30 minutes, an hour if you're lucky and there's only so much communication that can be done. If you bring your notepad and sit at a lunch table with people who work with your customers every single day and just listen, maybe prod a few questions in there, you'll have a more full notebook and a more well-rounded understanding of your customers in half the time. It's incredible how quickly you can start to learn from your team. Now, not everyone has the luxury of having these teams. Maybe you have a two birds and service team. Maybe you have a remote service team. The bottom line here is to get close to them. If you're able to get close to your services team, they have the insight into your customers and they're the ones who can actually provide you with the robust feedback and the best thing is they all double down on each other. So if they say this one part of the app is no good, they'll, oh yeah, and they just really hammer that one problem space and you can see that in a different way than you'd see with a customer who only has their specific point of view into something. Toying around with another potentially unrelated product to your own can be what's standing between you and a breakthrough for your own product. So I try to do this as much as possible, trying apps from the app store, apps that have to do with CRMs and apps that don't have to do with CRMs. Really just getting my experience more well-rounded in different types of software because oftentimes there will be quips in certain things that you'll learn that you can immediately apply to everything that you're thinking about at work. Because obviously you're spending 40, 50, 60 hours a week thinking about a specific problem, a very specific thing you're looking to solve. Sometimes that can be good, but sometimes you can get kind of wrapped in your own head and have a really hard time seeing the forest through the trees. So when you try another app, a lot of times you'll have that light bulb moment. I've had many of these myself of using basic filtering schema in like a gaming app. Play Fortnite and just like pay attention for 30 seconds to the way that they do selectors and the way that they do all of that kind of stuff. It's actually a really, really good way to get yourself out of your own product space, but at the same time, spur some really cool innovation. The DP, this is a bit of a no-brainer, but the deeper you go in a dataset, the more unexpected and surprisingly valuable things that you'll learn. Now that every one of us has a luxury or the time to do this, it's a really hard thing to do to go extremely deep into a set of data, but it's super interesting. When you're asking for a funnel analysis from your analyst or you're running one yourself, cross that funnel by region, cross it by language, cross it by geography, cross it by the age someone has been with your app. When you start doing that kind of stuff, the insights can be fascinating. You're not always gonna find them, but sometimes you can run a 180. For example, we were spending a lot of time thinking about the import flow into HubSpot and bringing data and bringing objects into HubSpot. We were concerned at the macro level about how this happened for everyone. We just thought, okay, how do you get from step A to step Z? It's a funnel, it's pretty simple analysis. Welcome through, we had some decent numbers. We took a step back. We crossed it by non-English speakers. All of a sudden we had lost 30%. That was super interesting. We started to cross by specific regions of different languages, different languages specifically regions of Spanish, things like that, and we learned a whole lot more. We were able to identify problems in translations, in localization, in internationalization, that we wouldn't have found if we were just looking at the overall funnel. This is certainly something that you can only do if you have the luxury of the time, but it pays dividends if you do.