Part of a series of posts about getting to PMF
Product management at an early stage (seed, Series A) is very different from product management at growth stage which is different from product management at established companies with a steady user base. This is why I’m often troubled when people read about product management online and try to apply what they read to their startup journey. It just won’t work. It won’t work because a startup is dealing with a completely different set of constraints.
You have fewer people: At an early stage, you probably have less than 10 developers. You can’t afford a product manager — one of the co-founders is probably the product manager. Best case scenario — there is maybe one product manager in the company. This product manager is also the designer, the analyst, the customer success expert, and the project manager. So net-net, limited resources.
You are pre-PMF: This makes a world of a difference. When you are pre-PMF, you are unclear about who your customer is. You are in search for your customer, your market. It is harder to decide what to build next — roadmaps aren’t as straight forward. If you know who your customer is, you are so early that you have very limited data to know what will drive PMF.
There are challenges at all stages of a startup, but early-stage is just dark! There is very little you can control, you have less capital, fewer resources, and a difficult (or unknown) customer.
So what does all of this have to do with “product management”? Well, I strongly believe that running an early-stage startup is like running a “sprint”. It isn’t a marathon. Whoever gets to the finish line or PMF first, is likely to get funded and startups that take longer to get there might even struggle to raise capital if there are other well funded, more advanced players in the market. Note, I’m not saying raising venture capital is the only way to succeed. But in case that’s a path you choose for yourself, you are essentially sprinting and you are not likely to get a lot of time to catch up if you fall behind. So unlike a growth-stage startup (that has more capital, more resources, more experienced leaders) or established companies (that have a known, loyal customer base), you need to learn a ton about your users, very, very fast! You need to break more stuff more often. You need to experiment and execute a lot faster. How do you do it when the cards are stacked against you?
Let me take a stab at busting a few myths about “product management” — rules that simply don’t apply at early stage (IMO).
PS: This post might feel more specific to consumer products but I’m guessing some of these points would apply to enterprise solutions as well. In addition, this is just my PoV and it has served me well in the past. You might have a completely different approach and it might work just as well — if that’s the case, chime in. I’d love to learn!
About PRDs: When you have a team of 100 across tech, QA, marketing, and other functions working on a single product or product feature, you need to be thorough and write near-perfect PRDs. The cost of a sub-standard PRD is high. This document is essentially how you communicate with your team — that’s how these 100s of people know what they need to implement. You can lose significant time if you try to change the spec later. Your changes can delay the rest of the roadmap. But at an early stage, when you are communicating with 10 people, if you need a detailed PRD to align everyone, there is something off about the culture. Early-stage PRDs should essentially fit into a whiteboard — pick the size of your whiteboard. You should improvise as you develop, you should overcommunicate with your Devs and QA to solve for corner cases. Note: I’m not saying don’t think through what you want to build. You absolutely should. But you don’t have the luxury, the time to spend 2 weeks putting together a beautiful spec with a detailed PoA for everyone. Product specs at this stage should be a well thought out, but rough outline of the MVP — let your dev teams get started — speed is of the essence.
Feature completion: Unlike larger products where features are iterated on multiple times and they are on a continuous improvement path, early-stage product management is about launching several MVPs one after the other in rapid succession to have a large impact on the overall product. You may choose to leave features as is if they are doing 60% of the job and go after other features that will have a large impact on the product instead of taking the 60% to 100%. This also has a huge impact on how you write your specs. You want to design something that “gets the job done” and not necessarily something that “does the job perfectly”. Reality is that if something is working, you’ll know very quickly when you talk to your customers. If the first version of whatever you build doesn’t evoke some customer love, it is unlikely that minor tweaks and enhancement to the feature will. If your MVP is designed right, early signals will be evident.
About prioritization: With the availability of resources, perfection becomes an option. But early-stage prioritization is a lot about making changes and implementing features that will cause large shifts in user behavior rather than incrementally improve a metric. Prioritize features that are likely to have a very high impact on key output metrics rather than features that have an incremental impact on second or third order metrics. Early-stage is not the time when you prioritize features that will take a month or more to implement. This is a phase where you throw more at the wall more often, to see what sticks. You want 80% of the output from features that take 20% of the time.
Roadmaps: I honestly think that at Seed/Series A when you are pre-PMF, roadmaps don’t mean much. You and your team should be nimble enough to respond to the market as you learn more about it. Planning for 2 weeks (maybe 1 month, at max) is the best you can do.
Phased rollouts: Just don’t waste time doing this. At an early stage where you have a few thousand users, you need as many data points as possible and while you are pre-PMF there is little you can do to break the product. Optimize for speed. Roll out often and to the entire base.
Measuring what works: Your base at early stage is so small, that metrics probably won’t reveal a lot unless the metric that moves is growth and you start getting an influx of organics. So measuring what works is literally about talking to your customers every day more than it is about looking at dashboards. While at growth stage, customer discussions can be reactionary, and a lot of times data can reveal a ton, at early stage, there is no other choice but to talk to customers very very frequently!
Metrics that matter: There has been a lot of debate about what matters at early-stage — growth or retention. The unfortunate answer is, both. While organic growth is an indication of pull or need, retention indicates that the product is satisfying the need. At later stages, metrics get more granular and feature specific — monetization, or perhaps, frequency of engagement becomes important. But by Series A if growth and retention have not been solved for, there is no PMF. At the very least, you want to see retention cohorts moving in the right direction.
PS: With consumer products in India, one might argue that proving monetization early on might be critical to PMF, but my point of view on this is still evolving
Authors
