Lessons from Big Company -> Startup Product Management (Part 1)

I am running a virtual workshop in August 2023 for product folks considering or making the transition from big companies into startups. It’s the stuff in this article, combined with a community of supportive peers, concrete tips for navigating the transition, and a personalized action plan for helping you thrive in your new role. There’s limited spots, so sign up for yours here.

This is part one of a two part series focused on my learnings going from a big company to startup product management. For part two of the article, click here.

Hello world! My name is Vinamrata Singal. I’m about to start as the first PM at Landis, a startup that aims to help Americans with limited income achieve their homeownership dream. Prior to this, I was a senior product manager at Propel, where I launched a debit card to millions of Americans with limited income to manage their government benefits and income together. Before that, I had worked primarily at bigger companies, including Thumbtack and Google.

Propel was my first real startup job. Surprisingly, I had a significant adjustment period working there, unlike my previous transition to Thumbtack from Google. I grew a lot (PM -> Senior PM), and spent the longest time I’ve ever spent working on one product (Providers Card), and saw it go from 0 -> millions of users.

I learned a ton from my time at Propel. I’ve spent a lot of time in this two month break thinking about the things I’ve learned across product execution, product thinking, people management, and self management, especially as it differs from my experience at bigger companies. Therefore, I’m compiling this post as a way to help others making a similar transition.

Product Execution

Momentum cuts both ways: startups are all about momentum, which makes them way more exciting to work at compared to big companies. One big thing I learned from working at Propel was that momentum towards an outcome is key to a startup’s survival, but it needs to be done sustainably. This is even more challenging in a startup where there’s more external pressures from the market and/or investors.

• For example: we spent a bunch of time theorizing about what we were going to do after our initial MVP launch. The lack of active execution really lowered morale, especially on the engineering side since they were mostly sitting there writing docs or in meetings rather than pushing out code and iterating based on user feedback. It would have been better if we had picked a path and started on it (even if we didn’t have full confidence) rather than spending more time debating.

Deadlines are a double edged sword: startups often use deadlines as a way to gain momentum. I have a lot of mixed feelings about deadlines, but here’s the gist: deadlines are just one of the tools in the momentum generating toolbox, and need to be used carefully. Non-product stakeholders and leadership teams love deadlines because it brings predictability to chaos. However, deadlines are an imperfect tool:

• Deadlines can often introduce artificial pressure which creates more burnout / morale issues on the team.
• Deadlines can lead the team to make bad product decisions because the pressure to meet a deadline can impair product judgment (i.e. we decide not to go down a path because it feels harder, even though it’s the right path).
• Deadlines are notoriously tough to estimate, especially at the beginning of the project. The beauty of software lies in its ability to scale, but with scale comes challenges to build something that works with a myriad of complexities and interdependencies.

I’m not saying never use deadlines. External deadlines can work. If you think a situation calls for a strict deadline (whether artificial or externally driven), be careful about the tradeoff. Don’t just default to them just because it feels like the most predictable tool. Think about other tools you can use to generate momentum (for example: product impact, problem complexity, giving more scope/ownership, etc.)

Have a vision for the MVP: we often relied on MVP as a way to validate our ideas without having a clear definition of what “validate the idea” meant. Since V1’s rarely work, it’s uncommon to ship something and see immediate traction without some iteration. Therefore, it was often unclear if the results of what we were seeing were good or bad. It’s also tough to get alignment post shipping, since everyone had their own interpretation of the data.

• This is especially important in a startup given the “let’s MVP it” approach is the bread and butter of building product. For example, we’d often ship MVP’es of tons of different features as experiments and would often wait for the data before making a decision on what good/bad means. It created churn on the product side and led to lots of wasted time.
• The key is to be as clear as possible with the team on what success, medium, and failure cases look like, and the next step if you achieve either outcome. This all has to be done before you ship the thing, so you don’t get biased by the data.

Give engineers ownership: I took on some responsibilities during my time at Propel that typically fall under the EM, including assigning tickets to engineers and getting into the details of some of the technical decisions. I learned a ton from this experience, but I definitely over involved myself, which took ownership away from my engineering team.

• For example- I thought I would save the engineers time by documenting things in a JIRA ticket, breaking down subtasks, etc. While the engineers didn’t mind this, it subtly took ownership away from them and showed up in subtle ways. Whenever there was a decision that needed to be made with the task, they’d often turn to me to make it, rather than feeling empowered to make it themselves. It also created confusion over the role of product, and added more work to my plate, leading me to burnout faster.
• The key is for product to focus on the why and paint a vision of success for a particular project, and give more ownership to design + eng to figure out the what and how. Product can certainly help with the what and how (and should remain involved), but the more ownership you can give to your team, the more sustainable and motivated the team.

Product Thinking

Always start from a user pain point/need to find product market fit (PMF): in my personal experience, it’s really tough to invent a market for a solution. This is even more challenging for consumer products: people have short attention spans, the space is crowded, and it’s tough to get customers to care. It’s really hard and takes a long time to build a consumer product and brand that people love.

• We often did this backwards: we focused on our needs / the outcome we were driving towards, and then working backwards to the user versus starting from the user and seeing where it led us. Or we’d come up with super convoluted problem statements, but if someone is going to care about investing time in your product, the problem and the solution both need to be straightforward to understand and relate to.
• Therefore, products need to focus on a real problem to a specific customer, the problem needs to matter enough to those consumers such that they want to invest in a product to solve it, and your solution needs to do something different than the other options on the market to solve the market. That is the key to PMF.

Product is ultimately a series of tradeoffs: each product decision can be optimized for roughly three things:

• Confidence/thoroughness (taking our time to make sure it’s the best possible decision with the most data)
• Speed (make the quickest possible decision/easiest for us to ship)
• Cross functional alignment (getting as much input as possible from the team and making sure everyone is aligned).

You usually get to pick one, max 2 things to optimize for in a given decision. Most of product judgment is figuring out which of the 3 to optimize for a given decision.

• This is different in a big company- usually you can optimize for more variables because there’s less time pressure, or company culture will dictate which of the three to optimize for. At startups, this decision calculus is constantly changing, which makes doing product here often more exciting!
• It’s helpful when making a decision (or when articulating why the team is making a certain decision) to be clear on which of those three you’re optimizing for. It helps folks who might disagree with the decision to understand what’s the most important framework at this point, and helps reach alignment faster.

That’s it for part one! For more learnings on team and self management from startup -> big company co, check out part two here.