Breaking into startups: 0-1 product management

Are you a product manager with dreams of joining a dynamic startup, but struggling to make the leap from a background of working only at large, mature organizations?

Don't worry, you're not alone. 😮‍💨

In the past few years building out product teams at early stage startups, I've encountered countless candidates on the same path who have inevitably stumbled. Transitioning to a zero-to-one (0-1) product development culture can be a challenge, because it feels like you've been operating in a completely different environment and it's difficult to demonstrate that you can in fact do the job. In this post, I'll explore the key pieces to include in a compelling narrative that showcases your transferable skills and sets you up for success in the world of startups.

So how is 0-1 product development different?

Let's start by making sure we understand why 0-1 product development is different. First, you're starting with a completely new idea or concept, which means there's no existing product to build upon or improve. This is pretty different from inheriting a product that's already achieved PMF, scale, and hit revenue targets which require you to maintain and to improve over time.

Since you're starting from scratch, it also comes with a whole lot more uncertainty and risk. There's no guarantee that your idea will be successful or that your product will resonate with your target audience. This means that you have a lot to prove early on whether you're operating as a standalone startup or as a brand new team within a larger organization — you need to demonstrate that continued investment makes sense.

Shipping fast becomes crucial is this situation. While all product development involves iteration, the frequency of iterations is much higher and often more significant in impact. You're leaning on this speed and iteration to test your riskiest assumptions — you're failing fast, learning and shipping again.

And finally, you're also faced with a reality that you have limited resources, time and funding. Each team member is likely going way beyond the role they were hired to do (or are knowledgeable about) while trying to get things done as quickly as possible to prove value.

You'd make an incredible 0-1 PM!

That's what you want to hear, right? Now that we know just how different it is to operate in this environment, let's make sure you're ready to build these attributes into your narrative - it should shine through your resume, your application and your conversations during the interview loop. Of course, this assumes you're also including what's normally expected of a product manager — user obsession, strong and succinct communication and an ability to collaborate with cross-functional stakeholders — so I'm focusing on dimensions beyond this:

1. Scrappiness

2. Driving clarity through ambiguity

3. Prioritizing impact

4. Visionary mindset

Scrappiness

Arguably, this is the most important quality and also the toughest to prove. I'm looking for someone who is both able and willing to roll up their sleeves to get something done whether or not it's in their job description or if they know how to do it — I expect them to figure it out, creatively. When you're operating at a large organization, it's rare to have the need or opportunity to flex this muscle simply because there's likely a dedicated role for every part of the product development process. This is where I see candidates fall short — they walk through their accomplishments just as it happened as if it were a walk in the park with a fully funded team.

Instead, focus on the challenges and roadblocks your team faced. Was there ever a situation when an initiative was blocked because the engineer was working on something else? What about data that needed to be pulled by analytics or a mockup that needed to be created by design? What did you do in that situation instead of just waiting? Of course, the ideal is that you took some action here but it's still helpful to talk through the hypothetical as it shows that you know what the right approach is and are self-aware enough to reflect on the experience.

Driving clarity through ambiguity

0-1 is completely uncharted territory which means you'll encounter a lot of ambiguity. This manifests across both the role itself (ie. how product management functions at X company) as well as the product offering and problem space you're operating in.

This means that you have to demonstrate an ability to think on your feet when given something brand new and be able to distill that information into something that can be communicated clearly. This is usually evaluated by a combination of looking at your past behaviors but also through how you react to new information provided to you during the interview process. How were you able to take a lot of customer insights and cut through the noise to determine the actual customer problem that was feasible for your engineering team to work on? If you needed to build out a product team within the company, what are the key considerations you'd think about?

Prioritizing impact

There's no shortage of opportunities tackle when you join a startup (or a brand new product area within an org) — that's the reason why it was started to begin with. So the critical skill set here is the ability to look at all the possible user problems and figure out which one will be the most impactful to the business at any given time.

This doesn't have to be about frameworks, there's no shortage of these that can be simply regurgitated. It just needs to be a methodical approach to determining what's important with a clear link between that decision and the business priorities. You should be naturally including this element within all your storytelling responses, highlighting the reason an initiative that you worked on as a PM was critical to the business and your customer base at the moment in time and what impact it had once delivered. At the same time, you'll need to be comfortable breaking down how you're making the decision over prioritizing one hypothetical problem, feature or product over another. The goal here is to show that you're not a PM who's just going to complete a laundry list of busy work with nothing to show for afterwards.

Visionary thinking

Finally, at this stage, the most important thing is not getting things perfect on the first go or making everything efficient in the process. It's absolute chaos because as mentioned above, the speed of iteration and execution needs to be like lightning. This means that it's the PM's job (often alongside the founders) to establish the anchor for the team — corralling all cross-functional teams and have them centered and motivated around the same vision end-state. Everyone on the team should live, breathe and believe in the vision and strategy which allows them to all operate in the chaos and ambiguity.

This is usually closely correlated with how you tell your story. When you talk about the problem and why it's important to solve, are you also painting a grand picture of what the future state is beyond the initial few iterations? What is the ultimate end goal that you rallied the team around that could take several years if not longer to actually achieve? That's why I want to hear alongside what you actually ended up shipping.

What's next?

Breaking into 0-1 product management is challenging because it's starkly different and requires a whole other level of skill and mindset but that doesn't mean you can't build those up at a larger organization, you just have to be intentional about it.

If you’re on this journey right now or are planning to explore in the near future, feel free to drop a comment or reach out - I'd be more than happy to help. This is just the beginning of an incredibly exciting journey in startups so if you proceed, you’ll probably want to read this other post too!