PM Cheat Sheet: Succeeding in a Startup After Big Tech
Lessons learned as a startup PM
Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.
The startup (un)learning curve
While working at Big Tech, I’ve taken many products from 0 to 1. During my time there, I believed it was “like being at a startup.” But now that I work at one, I’ve realized it was nothing like it.
As a PM who spent about 7 years in Big Tech (like FB and Uber) before making the jump to startups, I’ve learned a fair share of tough lessons. It took some time for me to learn which habits and working styles seamlessly transition from one environment to the other, and which I should leave behind. Here’s a cheat sheet of some of them.
1. Don’t worry about scale off-the-bat
In Big Tech, you learn to think about the scalability of solutions very early on: how to design a feature such that you can add additional options or controls later, how to architect a system that’s future-proofed for new use cases, etc.
When building in a startup context, there’s not much value in building for scalability on Day One. There’s no guarantee that what you build will resonate with customers and even be around in 3, 6, or 12 months. Your best bet is to take the fastest path to an MVP that delivers true customer value and figure out the “scaling” step if/ when you need to.
After all, a feature taking off and the team scrambling to figure out how to scale it is the best possible failure mode - what a great problem to have!
At Statsig, we’ve seen this play out not just in the product, but in many of the processes we run. Here are a few examples.
Dedicated support for customers
To this day, we still spin up dedicated Slack channels for each and every Enterprise customer who comes on our platform so that we can work with them directly to debug issues, field feature requests, and discuss best practices for data-driven development.
I also include a link to my personal Calendly in our activation email drip campaign to offer customers an on-demand, live help session if they’re getting stuck setting up Statsig. (Yes, even our Free customers who will never pay us a dime can schedule time with me!)
Being involved in every deal cycle
Of course, at some point when something works you do need to start thinking about how to scale it.
A great example is PM owners of new product lines at Statsig are often involved in every single deal cycle for that product early on. This gives them good insight into what questions and feature requests a customer has and where they’re getting hung up on the product and its positioning.
However, being involved in every single deal for a popular product line eventually becomes unscalable. In fact, this involvement can hinder the Sales & Sales Engineering teams’ ability to ramp up on understanding and selling the product themselves.
This is the point where the product owner will build a comprehensive suite of sales enablement materials (conveniently based on their learnings from all those deals they were involved with early on!), and run sales team training sessions, slowly weaning themselves off of being involved with all but the most strategic deals.
Building for scale should come after product-market fit, not before it
Investing in scalability once you already know the product has product-market fit and will be around for a long time to come is high ROI, but doing it on Day One will only lead to extended launch timelines and wasted time/ energy.
At Statsig, we now scale to customers with 100s of millions of users like Flipkart and OpenAI, but we didn’t build features to work at that scale before we knew they were useful.
2. Embrace ambiguity and failing fast
In established companies, unless you’re the CEO, there’s always someone above you who is setting higher-level strategic direction that you can leverage to guide your own product area’s vision and strategy. Furthermore, you’re likely operating in an established, proven business with relatively clear immediate next steps for each business line.
On the other hand, at most startups, nobody knows with 100% certainty what the company should be building or investing in next. Everyone (including the CEO & leadership team!) is on the journey of discerning this together.
The good news is that this can actually be very freeing because it gives you permission to fail fast, and fail often. There are a few examples of where we’ve had to fail a few times before we found our way.
Iterating on our pricing & packaging
We didn’t just fail at this the first time, we’re still continuing to iterate and figure out what works.
Fun story, for our first-ever enterprise customer (a popular web-based productivity tool), we initially quoted them 10x the price of the final contract we signed with them and 5x the price someone “more established” quoted them. Luckily they had the grace to laugh and work with us on finding what worked, instead of walking away. We’re both better for this bet.
Needless to say, we learned our lesson and have approached pricing much more carefully ever since. Pricing is hard to walk back once it’s out in the world, so consider starting at a more conservative offering (it’s much easier to get more generous over time, and significantly harder to take things away!)
Reevaluating our position against competitors
For many months in 2022/ 2023, we watched a new competitor with a warehouse-native model increasingly enter our deal cycles and, slowly but surely, start to beat us out with this novel new deployment. We initially disregarded them and this new model, championing the advantages of our Cloud-based product.
However, with each additional deal we lost, it became increasingly obvious that this competitor had created something the market wanted and we needed to swallow our pride and play catch-up. In mid-2023 we launched our own Warehouse Native deployment option and saw immediate uptake.
The lesson? Have humility, admit when you’re wrong, and constantly be re-evaluating your assumptions.
3. Reset your expectations of what career growth looks like
In bigger companies, career growth at more senior levels almost always correlates with growing teams under you. Initially, you manage ICs, and then grow to manage managers at the Director+ level.
But startups don’t need big teams with multiple layers of hierarchy. In fact, they need the opposite: very few, highly scrappy, high-throughput ICs who are singularly focused on solving problems and driving impact.
The reality of PM work at a startup
So if you’re coming into a startup as a PM hoping to grow your skills as a manager or high-level strategy setter, you may want to reconsider. No matter how senior you were in Big Tech, once you make the jump to a startup, most (if not all) of your time will be spent doing IC work.
Many people love this (I know I do!)- they’re excited to get back to building and being close to the product day in and day out. But for others, especially more senior folks used to being in a pure management role, it can come as a shock.
Similarly, it’s good to be cognizant of what you hope your next career move will be and whether working at a startup will unlock that for you. If, for example, you’re a mid-level PM hoping to get management experience in the next 12-24 months, going to a startup is likely not an optimal move – you’re better off staying at a bigger company where more management roles are needed.
When considering making the jump to a startup, it’s important to know what you’re looking for and be realistic about what your day-to-day will be spent actually doing.