 Hi. Welcome to Succeed as a startup PM when you've only worked at big companies. I'm Justin Neckhouse, and I'm going to walk you through this. First, a little bit about myself. I am a product leader, startup advisor, angel investor. I started my career as an engineer and then moved over into product. I've been doing product management and leadership for about 20 years at companies such as Amazon, Airbnb, CBS Interactive, and a variety of startups as well. Currently at Amazon, working on bringing podcasts to the Amazon music app. I'm based in the Bay Area. All right, let's jump into it. Before I tell you best practices for how to migrate on that path from a large company PM to startup and find success, I want explain some of the high-level differences. These are just a couple of the thematic ones. Of course, there's a million little things, but hopefully this gives you a big sense of is this the right path for you? First of all, product market fit. At a big company, unless you're starting something brand new, likely you have found some product market to fit. At a startup, depending on the stage, you might not have any product market fit. You might not have launched your product at all. This can be a pretty big difference between iterating on something that's working to optimize it versus starting with a blank piece of paper. Next up, scope. At a large company where there's a lot of product representation, maybe you're working on just one feature. Maybe it's a big feature, but still a feature. Sometimes it's a group of features or a small part of a really large feature. At a startup, especially early stage, likely your scope could be the entire product, the entire company, depending on, again, the stage that this is in. Scope can vary a lot and could seem overwhelming, but also could be fun. Impact. At the big company size, you may be focused on one or just a few metrics. At a startup, you may be responsible for the success or failure of the entire product or company. There can be a lot on your shoulders, but also you have the ability to create huge impact in what you do on a daily basis. Process. Larger companies have probably gotten to where they've gotten because they have some established process. As you scale, process becomes more important and people more and more want to throw process on there and quickly can become a large part of your daily job. At a startup, you typically start with no process. You really have to choose what is the right process. How much do we need? Can we go with less? It's rough and it's minimal. A lot of that, frankly, is by design resources. I know at big companies, we all feel like we never have as many resources as we need, but in comparison to a smaller startup, you have a lot. You have people potentially to look at BI and to do project management and to do all different facets of product, whereas a startup, you have very few and oftentimes really have to be a jack or jill of all trades. Data is the last piece that I want to talk about on the data front at a large company. You usually have a lot of data to go on. Maybe you have bad tools or it's hard to get at, but normally because you have customers and because you're more mature, you're tracking many different things and you can report on many different things. At a startup, if you haven't launched, you may have no data. Maybe you have some user research, but typically you have to get very creative on how you go about using data to make decisions or just making decisions without data. Now that we understand some of the key differences, let's talk about how to be successful in a startup environment. Product fundamentals and hopefully find this a bit reassuring. Product fundamentals for a startup are really the same as for a large company. What you are going to do to find success with what you already know is to really shift where your priorities are, where your time is spent. So for example, on your mission, your vision, your strategy, these are really worth your time. These things are super important and are going to really set the stage for success for everything that comes after that. What comes after that is your tactics, your roadmap, your prioritization, your metrics. So again, you're going to spend time on this, but probably a lot less than you typically spend at a large company because your tactics are a best guess based on hypothesis or based on small amounts of data or no data at all. And so we want to make sure that we're not spending a lot of time on these things and rather really setting ourselves up to sort of find that product market fit and try a bunch of different things out. But remember to sort of lean back and remember that you have spent your career at a large company and learned a bunch of product fundamentals that will apply, just need to shift how you apply those. So what's your job as a startup product manager? A couple of different things I want to say here. So we throw around this concept of CEO of your product a lot. You hear that written in articles. A lot of people reject that. And I think at a large company, it definitely is not exactly the right metaphor to use because a lot of times at a large company, although you are responsible for your product or your feature, so much is out of your control. So much is handed down to you. You don't have the ability to impact resourcing decisions nearly as much. At a smaller company, at a startup where maybe you're the only PM, this can be a lot more true. And I think it's important to embrace this and feel like the success or failure of the company is your job, not just the feature, because oftentimes you're a one product company and oftentimes a one PM company. And so to start with, really think of everything that determines the success of your product as your job. So you can't just build a good product. You need to either be the product marketer or work very closely with the product marketer to figure out what is the pricing and positioning going to be like. You need to validate that sales is on the same page with you about how your product is going to be discussed with customers. What is the value prop they're presenting? Is that resonating? Can you help adjust that if it's not working out? I encourage you go out sales as much as you can, both to sort of see how sales is presenting things. And if that aligns with what your vision of the product is, but also so that you can get close to the, so we talked about product marketing and we talked about sales research, oftentimes you don't have a researcher and it's sort of up to you to find the research that you need to do need or go out and do the research if it doesn't exist. BI is again another thing that sometimes you have, sometimes you don't, sometimes you just got to get some cheap tooling in there to do it yourself, expect to write sequel in the early days. You may not have someone to do that for you. You'll go for partly a joke, but partly it's true. I can't think of a startup that I have been at where I have not gone out and bought lunch or dinners for people to continue forward momentum. Recruiters are the last thing here that constantly sort of being evaluating, do you have the right team to make your product successful? And if not, even if you're not the CEO or you're not the recruiter, get involved and figure out how do we get the right people on. That's the right sales team. Do we hire a consumer sales team when we really need an enterprise sales team? Are these people not the right people to represent the product? Is the designer delivering what we need to be successful? So really, I want you to take on a lot more than you typically do in product at a larger company and this is why you need to really adjust your time investment with other things like the tactics on the roadmap where you might otherwise invest significantly more time today at a larger company. So continuing on that theme, you want to keep things light, keep the process light, but don't skip steps. So we talked about this a bit before, but I just want to emphasize and sort of explain more about what that means. So product process is product process, right? You start with your mission, vision, strategy, objectives. Again, to emphasize, you really want to spend time there because these are important and this sets you up for success in the rest of the process. And you want to run the process all the way through QA and release and looking at success of the product once you release it and iteration, but you're going to spend your time a little bit differently. So your tactics and your roadmap look differently from a large company, especially if you don't have product market fit. And what does this mean? This means that, for example, on your roadmap, you want to spend some time on it, right? Because this really can inspire the organization and set up a North Star for where you went ahead and may totally change very often. So what I recommend is spending a fair amount of time on the current or next quarter up and doing a full year roadmap, but doing it at a more thematic level after the first quarter, just knowing like you want to set a direction of where you're heading, but you don't want to spend huge amounts of time in detail going quarter by quarter because likely that's going to shift a lot. So I also want to emphasize that you want to plan for success. So don't hedge too much, but that you don't want to overinvest. Again, so keep in mind that a lot of the tactics or items on your roadmap are going to fail or they're going to have minimal impact. And so you don't want to overinvest and assume that everything's going to work there. You really want to embrace the MVP, the Lean startup methodology. If you haven't read the Lean startup book, I recommend highly you read that and think about what is the least that you can do to test your assumptions, your hypothesis about your product, about a feature that you're going to release and set that up so that that works as a test, but is not sort of a fully functional feature. You're just looking to sort of say like, how do I test my hypothesis here? And this is often a very uncomfortable place. I encourage you to find the MVP and think again, what can I do that's even less than this? Ask other people for input there because it's uncomfortable, but almost always you can pare it down more and more to really answer the question of, well, is this finding traction? Is my hypothesis true or not? Had a big company, I know this can be very uncomfortable to do, but it's really sort of a mind shift that you're going to have to make to be successful at a smaller company. You're really looking to build yourself what I call a learning machine. And this is a product that is certainly about finding product market fit and success with customers, but it is about learning every time you do a release and adding to what you know, which will add more certainty to prioritizing the roadmap. A framework that helps a lot with this is called GIST, which I've linked here and really helps build this sort of learning framework. So every time you're releasing, you're set up to learn more to make future investments more certain. Prioritization is a bit different as well. So what you want to use is a lightweight prioritization framework because you are not going to start with a lot of data, a lot of knowledge about what's going to work. I like rice. And if you do have really some data, rice is pretty nice. It looks at the reach and impact versus the effort of any given feature and helps you prioritize in sort of an ROI type of way. If you don't have any real data, then any sort of numerical-based framework can be difficult. In that case, I recommend a consensus-based framework. Pandora invented a pretty unique one where you basically have a team come together and put money down that corresponds to the resources you have to choose what the most important thing to work on is. So take a look at that. So on actual sort of day-to-day tactical approach to things, agile works. So you're probably doing agile now. Hopefully you're not doing waterfall. How you do agile maybe is a little different. Maybe you're doing scrum-based agile today. That can work. But again, make sure you keep it light. Evaluate do we want our sprints to be three or four weeks instead of two weeks so that we have less overhead. Another framework that I like that's part of agile is called Kanban, where you really don't have sprints and it allows you to sort of really shift a lot. It basically is built off a system where you just, as soon as your developers finish a ticket, they go back to the board and just pull off what's next. And so at any time you can sort of reprioritize that. So Kanban is it's worth looking at to find a framework that works to allow you to really shift and pivot a fair bit without incurring a bunch of sort of debt or overhead. So take a look at Kanban data. So I mentioned that data is very different in a startup. You may not have much at all. So what do you do if you have little to no data of your own? This is very often true of a sort of pre-launch startup. You may have some research. If you don't, I would say let's go find it. So where do you find this? You can go and look for market data. You can look at competitive data that's out there that you can sort of just Google for that maybe is findable on YouTube through presentations that people have posted from conferences. There's often a lot of data there. Talk to customers, right? So customers are an amazing source of data about needs and wants and behaviors and motivations. So you really got to make your customers your friend and you should be talking to them on a regular basis to really find out what's happening in the market that they know what's working and what's not working for your product, what new problems have they started encountering with their job that maybe you can go out and figure out how to fix. The flip side is that your non-customers may be more valuable than your customers. And so again make your non-customers those who have said no we're not buying your product even better friends and figure out why not. And is there some point that you can build in the value that they need that will convert them to be a customer? And so important to sort of really pay attention who has to sort of convert a specific customer and more to really find value that's going to apply to a bunch of different customers or a new segment of customers. So you're going to find that A-B tests are usually not possible in the early days of startup. This is especially true in enterprise businesses. So what do you do? Well, you got to look at other ways to test. So we do this thing called pizza testing or what I'm calling pizza testing. And that's where you literally bring in friends, family or potential customers of the product and give them free pizza in exchange for sitting down and walking through some user testing. So build out some scripts, have them test your product out, see what's working, see what's not. If you're pre-launch another thing you can do is do test your competitors products. There's a great way to sort of learn about what's working and what's not working with their product and find potential opportunities or things that maybe you don't need to build in your product. And so you can do that again with sort of the pizza testing. You can also use online testing resources. So there's a lot of online testing available that is a very sort of inexpensive way and quick turnaround way to get user testing. Another thing that I think is worth looking into is how you track within your product. Tracking is very different on these early launched products because you don't exactly know what to track. So we definitely put in some tracking, right? Put in Google Analytics or one of the other analytics software that is cheaper, free, and get you to the basics and track things that you know, but also realize that you're not going to really know what to track on the early stages or it's going to be very expensive to track every single thing that you want to. So what I recommend is user session recording software. There's a lot of fairly inexpensive good ones such as InSpecLit or Full Story that will actually sort of track the user session as a recording. And so you can see everything that happens and get a sense of how people are using their product, your product, where they're getting frustrated and both take that in to iterate on your product, but also to instrument tracking later based on the pieces of your flow that end up being important. So smoke and mirrors and not scale. So scaling obviously is something that you're going to need to do to be successful in your startup, but don't get ahead of yourself. I want you to sort of embrace what I'm calling smoke and mirror. So you want to spend your time where you create differentiation and don't prioritize work that you can cheaply buy or fake with people. And when I say do things that don't scale, what does that mean? That means early on your job is not to scale is to find product market fit. So talk to customers one by one. Don't send mass surveys and expect great data back. Talk to them one by one. Do stuff manually. And this means you may want to automate every part of the app or whatever you're building, but do you really need to do that? Or can you do some stuff manually until you've proven that you found product market fit or the feature is going to work? Buy stuff. So we'll talk about this more later, but think a lot about the build versus buy decision. As you're doing things that don't scale, one thing to be careful of because you're going to be out there talking to customers is don't lose focus and build a feature that's just for one customer to solve one customer's problems without evaluating if it has wider appeal. So this is a trap many people fall into because you're talking to a customer, they have a real problem, and you're like, oh, I could definitely solve that with this. But if that's not going to be valuable to a large segment of your customers, then you're going to start building custom software and that is never going to scale. So really be careful here and think about can I generalize this problem into something that applies to many different customers. You're going to want to spend your time wisely. You're going to want to focus your time on things that people can see. Think about how do I build delight for my customers? And so what does this mean, things that people can see? This means your UI for sure. So investing in great design is super important. Great design builds trust with customers, even if you haven't really earned it. Customers see something that looks great on the front end and they have trust that your back end and the rest of your organization is built in in such a careful way as well. So really putting out a product that looks great is super important. So don't skimp out there. This also means that you need to spend time building where people can see on the back end too. So don't spend a lot of time building, say, some kind of a package that you could just use Excel for in the short term. If that is not important for your customer, customer isn't going to see that. You want to focus your time on table stakes, for sure, if you're entering a competitive space, but on the table stakes that matters, you want to focus only on the table stakes that matter so you can spend more time focused on the differentiators that are going to truly find a place in the market for your product. So table stakes, what do I mean by focus on the table stakes that matters? That means that a lot of your competitors may have a wide feature set, but their product may have been first released 10 or 15 years ago. And so maybe a lot of those quote unquote table stakes are not table stakes anymore. And so you really need to figure out which of those are true table stakes and which of those you can leave out or shift even how they work because the way they were thought about a decade ago maybe doesn't apply anymore. And this is where that user testing of your competitive products can really help. Buy, buy, buy. So early on, you don't want to build anything that doesn't add value to your product. You don't want to build commodity things. You want to build where it counts. And so software is actually pretty cheap for startups most times or even free. There's a lot of startup packages or credits that you can get as a startup. And so really take advantage of that and use external products to integrate your product to bridge functionality rather than building it yourself. Maybe later on you'll replace it or you'll build a better version of it. But really think about what are my differentiators? Spend time, build those and buy or integrate anything else that you can on the early days when you're really trying to find product market fit and figuring out how do we sell this thing and how do we build a product that customers want. And then finally I want to talk about doing things manually and specifically ops teams. And ops teams typically can be fairly inexpensive especially if you find them in lower cost labor markets and they can fill in a lot of product holes. And so you definitely want to look into can we use people to do something that maybe will automate later when we're looking for scale but is less important early on when our goal is to find product market fit or test a hypothesis about a feature. Until you're really certain you don't want to invest in total automation here when ops teams can potentially do it with the current scale that you're at. So those are some of the high points of how to be successful as a startup PM when you've only worked as a big company PM. Thanks so much for your time. If you have any questions feel free to reach out to me on LinkedIn or my site below. Thanks so much.