When I began my career in Product 10 years ago at Facebook (yes, it was Facebook back then,) I had a clear plan:

I planned to spend 2 years at a big company learning the fundamentals of Product Management, and then I would jump from big company life to starting something of my own. Simple.

Well, as with most things in life, you lay a detailed plan and life laughs at you.

A self-proclaimed “startup” person, I fell in love with being part of something bigger—working first at Facebook and Instagram on video and early growth initiatives, and then jumping to Uber to build out the company’s international presence. All in, I spent almost 8 years at what you would very much define as “big tech companies.”

And here’s the thing: I LOVED it. I thrived on the scale at established companies that have found product-market fit and were in growth mode. I loved that you could go anywhere in the world, tell people where you worked, and it was instantly recognizable and often met with an anecdote of how something you’d had a hand in had touched their lives in a meaningful way. There was a feeling of truly changing the world, like you were part of something bigger. There was pride. I embraced my newfound identity as a Big Company PM, and leaned into building a career within the well-defined structure of Big Tech.

As the years progressed, and these companies found increasing success and scaled headcount, the joys of building at scale started to be overshadowed by the harder realities of building at scale. More coordination overhead, multiple teams working on competing initiatives, and the micro-politics of fighting for meaty scope became a core part of my day-to-day.

And so in late-2020, I decided it was time for a change. One heuristic that had served me well in navigating both the choice to join Facebook and jump to Uber was something I called the “people-to-problems ratio,” or optimizing for situations where there are lots of problems to solve and too few people to solve them.

Double-clicking on this heuristic, I realized that it was pointing me back to my roots, to my original “plan” of working in a startup environment. After 8 years, was it finally time to take the plunge?

It definitely wasn’t how I had envisioned my “startup era” would begin- we were in the depths of a global pandemic, everyone was WFH and news publications were proclaiming that “in-person work is dead forever.” How was a startup going to work in this new world? Images of The Social Network and Silicon Valley flashed through my head, with teammates working late hours into the night on a shared mission. Was now really the time to make the jump?

I decided it was. And so began my mid-career transition from being a quintessential Big Company PM to re-learning how to build businesses from the ground up at early-stage startups.

Here are three of the more surprising things that I learned along the way

People are everything

The Statsig people

On the surface, this one doesn’t sound particularly surprising, but I believe it’s more important than ever in the context of a startup.

At a big company, while your immediate team is obviously very important, in reality you’ll likely be working with lots of folks cross-functionally and in ancillary roles, meaning you literally interact with more people day-to-day. Accordingly, the odds that you’ll find folks you really love and jive with increases.

At an early-stage startup on the other hand, you’re likely joining a team of 10-30 people and those people are the only people you’ll be interacting with. And not just during the workday, but often late into the evening and on weekends (yes, startups often require grinding just that extra bit harder).

These are the people you’re going to be in the trenches with, solving hard problems and working through existential, company-defining moments together—so you really need to get it right.

How do you do this, especially given limited data points during an interview process? In my experience, I’ve found that it’s often the “unscripted moments” that provide the most clarity on the types of people that make up a company.

For example: Statsig—the company I’m at right now—was only about 20 people when I interviewed.

While the interview process was great and I enjoyed everyone I spoke with, the thing I remember most about the day was lunch. Everyone stopped what they were working on and gathered around to eat together, making inside jokes and laughing at something that had happened on one of the work chat threads. The noise level in the office jumped noticeably.

You know those work lunches where it’s silent and awkward and you’re counting down the minutes until it’s over? This was not that. Conversation flowed naturally and clearly because people truly knew one another. They knew about each other’s lives outside of work, they asked questions, they cared.

I decided right then and there that this was a culture I wanted to be a part of.

Always be taking shots on goal

As a product manager at any company, you’re responsible for building a roadmap.

When you’re at a big company, this is typically the roadmap for your team and as you become more senior the scope of the roadmap you influence and drive increases.

At an early-stage startup, however, you may be the only PM, or one of 2-3 PMs who are jointly responsible for setting the product direction for the whole company. This can feel intimidating at first. After all, there are no VPs or more senior product leadership above you setting the strategy and defining an OKR framework that you’re operating within.

Now that I’ve been a part of two early-stage startups, I’ve learned that a specific, project-level quarterly roadmap is great, but realistically will change by day three of the quarter.

Customer inputs, shifting market conditions, an unexpected competitor move, all these factors, and more, will influence the product roadmap and shift priorities in real time. The best companies are those that can be nimble and are willing and able to adapt to new inputs in real time.

That said, one thing I’ve learned that you can control is whether or not you are prioritizing solving the biggest problems your company faces. I’m not talking your run-of-the-mill product optimizations, but the big, hairy, existential problems your company faces.

When it comes to product strategy and roadmap, my only rule is “Ensure you’re taking at least one shot on goal at all times.”

What do I mean by this? Most early-stage startups are pre-product-market fit. They’re still cracking sustainable customer acquisition levers, understanding the limitations of their pricing models, and trying to broaden their customer use-case footprint. And none of these problems can be solved by grinding out another set of funnel optimizations, or iterating on your paid ad copy. These problems need truly creative, 10x-type solutions—things that will meaningfully bend the curve and change your company’s trajectory on a critical axis.

These are also the hardest problems to solve, and often require the most attempts. Accordingly, I’ve found that if you’re not actively seeking out and prioritizing one “crazy,” curve-bending bet per quarter, you’re probably not doing it right. I call these “shots on goal,” and the reality is that most of them don’t pan out.

You have to be ready and willing to fail a lot in this game, but at the end of the day you only need one that sticks.

A recent example of a “shot on goal” we took at Statsig was making one of our core features (feature flags) completely free. We just decided to stop charging for it—plain and simple. We observed that feature flags are a core need for pretty much any company that writes software, and are something that most companies overpay for today.

While we could easily price this functionality in line with competitors, we really didn’t need to, and if offering useful functionality completely for free meant we could start a conversation with significantly more companies, it would be worth it for us.

Done is better than perfect

At a meeting early on in my tenure at Statsig, our CEO Vijaye mentioned that he was working on our formal cultural values, but they needed a bit more polish.

Half-jokingly, I retorted, “done is better than perfect,” and he stopped in his tracks. “You know what?” he said, “you’re right. I’m going to publish these right now, just as they are” and a notification for a post in our company chat flashed across my screen.

The next day when I arrived at the office a new poster was on the wall that read, “Ship it before it’s done.”

“Well that’s an aggressive take on ‘done is better than perfect’” I quipped. “Did we really have to go that far?” Vijaye explained that he tweaked the oft-used phrase to intentionally be more controversial. He wanted to highlight the very real tension that exists between moving fast versus waiting until something is perfect.

I think about this experience often in my day-to-day. In my time at Uber and Facebook, I would have been mortified to think that I was sending across PRDs with placeholders for details I didn’t have yet, or aggressively paring back key features from an MVP product launch.

I have always been a perfectionist, and the idea of getting comfortable with things not being perfect on day one has been something I’ve had to wrestle with as I’ve transitioned to startup life. Especially as PMs, the products we build become an extension of ourselves, a reflection of our taste and attention to detail. If they aren’t perfect, will it reflect poorly on us?

The reality is that, at a startup, you need to balance launching the perfect thing with launching a thing, and then another thing and another thing. It may take multiple shots on goal before something sticks, and fortune favors the team who moves fast.

The faster you ship, the faster you can learn, and the faster you can course-correct if needed.

They’re both posters now

Bonus insight: Make sure there’s actually a role for you!

Joining an early-stage startup as a PM is like “Startups: Expert Mode.” This is because founders are often either product people themselves or have a very strong product vision for their company.

I’ve lost count of the number of PMs I’ve known who have joined early-stage companies in a Lead PM/ Head of Product role, and have realized that they don’t actually have any ability to influence product strategy or direction. They have been hired to execute on the founder’s vision, and essentially project manage a roadmap set by the founder. This is especially true when the CEO is a former PM.

Of course, it doesn’t have to be this way! There are lots of companies out there with founders who have a background in Engineering, Sales, Marketing, or Ops. Oftentimes these founders are keen to partner with someone who can bring product chops to the table, including partnering closely on product strategy and roadmap. These sorts of companies present a great opportunity for PMs looking to “level up” their career and have a front seat in building a company from the ground up.

My advice for any PM considering a startup, especially in a leadership role, is to quickly “suss out” whether your skillset will be complementary or competitive to what the founder(s) bring to the table.

Ideally, you do this during the interview process. Oftentimes the best way is to simply ask team members you interview, “How is the product roadmap set today? Where are there gaps in product strategy?” The question you’re trying to answer: Is there a gap to fill and are you the right person to fill it?

That said, an honest heart-to-heart with the founder(s) about what role they expect you to play in setting product strategy versus simply executing on their product strategy is the best way to get to the heart of the issue.

Trust me, your future self will thank you for having the hard conversation and aligning on expectations up-front.

In closing

I’m now two years into my rebirth as a startup PM, and am having more fun than ever. I love working closely with a small, scrappy team of people who truly care about one another, taking shots on goal to build a business we all believe in.

It hasn’t always been the smoothest transition, and I’ve had to learn to overcome my perfectionism and get comfortable “shipping before it’s done,” but I am confident that everything I’ve learned these last few years will only serve to make me a better PM, wherever my career takes me.

So if you’re considering making the jump from Big Tech to a startup, I couldn’t recommend it enough. You’ll come out a better PM—no matter what happens.