Product Management at a Startup 101 Talk Notes

An idealized transcript of my talk for the Builder's Studio at Slush 2022

I recently had the amazing opportunity to speak at Slush on a stage devoted to tactical company building. (As a side note, I highly recommend going to Slush generally, as I thought the attendees, speakers, & events were top-notch.) I thought I’d share my talk’s slides and written commentary — think of it as being a better transcript of my talk — in the hope it could be helpful for others not at the conference. I discuss my learnings from becoming the first product manager at Scale and from working with portfolio companies growing their product teams & product-building processes. These tips come from both my own trial-by-fire experience as well as from an amalgamation of resources I learned from as a PM, the main ones noted on a slide at the end.

Hey everyone! So excited to be here at Slush.

I’m Leigh Marie, currently a principal at Founders Fund investing in mostly enterprise software companies across stages, with a particular focus on dev tools as well as data & ML infrastructure and applications. Before that, I was one of the first engineers at Scale and then transitioned to becoming Scale’s first product manager. I was at Scale for around 4 years, as we grew from a handful of engineers in a tiny office with few customers, to a company of hundreds of people last valued at $7 billion that serves many people doing ML in production today.

My talk today is titled “Fostering Product Driven Culture”. So, what does ‘product driven’ culture even mean? Honestly, was hoping such a mysterious name intrigued people to come to the talk. Jokes aside, I want to share some tips that I’ve learned from living through a product management “trial by fire” to help you create and maintain a culture that creates excellent products again and again. Of course, I’m anchored to my own experiences both at Scale and working with portfolio companies, so I can’t give advice that will apply to every type of company in every situation. Successful companies build products and product teams in many different ways. However, they have things in common - they are obsessed with their own team building, the customer’s problems, and measuring success. They are ultimately obsessed with learning. Thankfully, there are patterns to how to implement these obsessions within your company, and I’ll be talking about some today.

I’ve ordered the talk in the same order as you would encounter major decisions around your product-building processes & product team while building a startup. First, we will look at the earliest days, building from “0 to 1” - when companies are founded and hire engineers to build the very first versions of their product in pursuit of product market fit. Next, we’ll address a question I get asked all of the time from portfolio companies & angel investments - when do I hire a PM? How should I evaluate them? What are the tradeoffs here? Then, we’ll get into mistakes early PMs commonly make and how to combat short-term thinking. Most of these are from my own personal experience, so ideally you can learn from my mistakes. Lastly, I’m going to share some factors to consider when growing the product team rapidly. 

There’s lots of inspiration from other product leaders that I learned from in creating this presentation. I’ve included the names of ones whose material I referenced heavily as a PM in my day to day at the end of the talk for further reading and highly recommend you check our their blogs, twitters, or podcasts to learn more.

The earliest days of a startup are some of the most exciting and the most precarious - many decisions are life or death for the company. I remember feeling very energized as an engineer but also slightly terrified. You only have so much time to build a product that customers need and to create a business that will sustain itself. Chaos is a feature, not a bug, especially at this stage. You need some entropy to achieve a crazy outcome.

As a result, to move as fast as possible when the whole company can fit in one room or zoom call, there needs to be a source of truth & product vision for the company, and more often than not that’s the CEO. Other technical founders & tech leads likely define the product requirements & manage engineering workloads, but frequently (though not always) the CEO will be the “product manager” - or the one making most of the high-level product prioritization decisions - as they are the one with the most in-depth knowledge of the company vision, the customer, & the overall business. The singular focus should be finding product market fit.

The first 10 or so engineering hires will should be self-sufficient enough to make small product decisions within their day to day work – ultimately I’ve seen that hiring early engineers that require micromanaging is likely more trouble than it’s worth, as no one has time to over-specify each task. Similarly, engineering contractors can be useful for self-contained tasks, but given the velocity of changes & need for individual buy-in at the early stage, contractors should be hired smartly & selectively. Best case contractor hires are people you’ve worked with before or that have contributed to related projects.

Engineers will likely be chatting directly with customers to understand pain points & should relay feedback & personal opinions that can potentially change the roadmap, but the CEO/PM will ultimately make the final call if needed. This is why I tell people considering working at a very early-stage startup that they must have extremely high trust in the founding team – there shouldn’t be many checks and balances to rapidly iterate at this stage. A common saying goes, “great products aren’t built by committee”.

One last thing I’ll mention here - this is likely the stage where in-person vs. remote matters the most. Post PMF, it matters less. Pre PMF - communication - between the team and with the customer - is paramount. If you are remote, this will naturally be harder, so - make sure to have a really good reason for being remote, like particular necessary talent reasons. It also helps a lot if the team - especially the founders - have worked together before. The fewer barriers to communication, the faster you can iterate in the early days.

One great example of a company that had engineering do product management for the first 5-ish years after its founding is Stripe. The founders & engineers were doing traditional product management tasks even past finding PMF; I think they didn’t hire their first PM / have the title until after their Series C & the 50th employee mark. This was enough of an anomaly that CEO Patrick Collison wrote a piece justifying why they didn’t have PMs for such a “long time”. He writes that “the engineers manage products themselves” and cites numerous successful product launches as completely managed by engineers. So this approach in the slide before can work for a long time, especially if you hire engineers that enjoy figuring out what products should do vs. the product implementation details only.

In Stripe’s case, many of the engineers were former founders or had previous experience in design, partnerships, and bizops. They were able and excited to talk to customers, identify opportunities, and think through details like willingness to pay, competitive landscapes, and business models. Also, Stripe’s initial target audience was developers, giving their engineering-heavy team an unfair advantage building for that persona. In fact, half of the engineers Stripe hired at that time had already used the main Stripe product before joining the company.

Though hiring PMs have plenty of advantages that we will chat more about later, it’s important to remember there ARE tradeoffs. PMs put another step in the communication chain - if the same person is defining product requirements and implementing that product, no information is lost in communication. Inherently, involving a PM makes product development slower, and for product-minded engineers with micromanager PMs, less “fun”.

 So let’s say you’re thinking of hiring a PM - great! What exactly they should do is different, depending on if startup has found product market fit or not, and how many products you’re building. 

If you’re pre-PMF, there’s a good chance you don’t really need a PM. However, maybe the CEO is too busy to project manage product development, maybe there are a few concurrent product bets and the engineering manager can only optimize the execution of one of them, or maybe the engineering team doesn’t want to or can’t communicate all of the product updates with customers. All of these reasons might be enough to hire a product manager early, but they aren’t going to be a product manager in the traditional sense of the word. They’ll likely be the project manager supporting the CEO’s/founding team’s vision - running engineering processes including testing & launching, coordinating customer feedback, and creating very simple analytics & documentation. They aren’t writing a long vision document or planning years out - or really even a few months from now. They are extremely detail and velocity focused in pursuit of finding product market fit. I’ve seen startups hire more junior people for this role, or transition someone internally, or hire more senior people with the understanding they will become a “true product manager” when it’s appropriate. Tradeoffs to either - in the first two cases, they might not really understand what a product manager really needs to do post PMF & always be too focused on project managing. The latter might butt heads with the CEO over product decisions pre PMF.

Once you’ve found PMF, you can likely find use in having a more traditionally defined product manager. I’ll define PMF as when your product’s users are using your product in a mission critical way & ideally paying for it; even better if you’re bringing those users in for a lower cost than their life time value (or have a line of sight to good unit economics). Founders & engineers now have more responsibilities and the team is growing, creating a higher risk that people lose product & customer context. A PM can unify the team by clearly defining the customer personas, product use cases, & business tradeoffs and communicating with all stakeholders to make sure everyone’s voice is heard and everyone (including the customer!) is on the same page. My favorite simple way of thinking of a product manager’s responsibilities - to the credit of Silicon Valley Product Group - is as a subset of general product risks. There are 4 main product risks - value: will a user buy it? ; usability: can a user use it? ; feasibility: can we build it? ; & business viability: does this work for our business over various dimensions (for example, compliance)? Product managers primarily address value and viability, engineers primarily feasibility, and design primarily usability. The product manager should work with leadership, customers, and cross functional teams to decide on problem themes & business goals that EPD (engineering, product, & design) should own over some timeframe, and work with engineering and design to translate those into a roadmap and ultimately a fine-grained prioritization of tasks. 

Naturally the next question is WHO should be your first product manager. There are benefits to transitioning someone internally, as they will have a lot of context from their previous role. On the other hard, if you hire someone more experienced externally, they could have more knowledge of product management best practices from their previous roles. Have seen both work! In any case, it’s important for product managers at early stage startups to know how to deal with uncertainty and believe they have the agency to make change (which is a personality type or skillset). At Scale we called this “running through walls” or having a “bias to action”. Ideally, a product manager should have great product taste, be able to prioritize & execute quickly, know the basics of strategy, understand the importance of metrics & iteration, and create efficient processes for communication. In practice, you’ll probably need to identify an individual who spikes in one of these areas with a passion for learning about the others. Ultimately, you want to hire an empathetic learner who will we able to become a worldwide expert in their domain, and they’ll likely be able to figure it out. 

Once you’ve moved to “growth”, or scaling the core business and expanding your product offerings, you’re going to need to scale your product team; a good heuristic is 1 product manager from every 10 or so engineers. More technical products may need less product managers and more project managers. You’ll start to hire more specialized PMs with different backgrounds in business, tech, design, & growth that will complement each other and work on more specific teams. You might also think about hiring product executives, like a CPO. The founders will still define the long term vision, and might have strong opinions about the  short term product development, but product managers - especially product executives- can help with defining goals in the medium term. 

I’ll talk through my own journey from engineering to PM as an example of how an early engineer can become the first product manager. I knew after doing my first product management internship during college that I wanted to be a product manager, but Scale when it was sub-10 employees didn’t need a product manager, as Alex the CEO was technical & product minded. So, I started as an engineer and took on an increasing number of product responsibilities. Early on, this looked like project management, but as Scale grew, there were more opportunities to talk to customers, learn about the autonomous vehicle industry as a whole, understand labelling product competition, help the support & sales teams, & write product documentation. Finally when Scale achieved product market fit with their image annotation product and needed a product owner for the 3D (LiDAR) annotation product, it made sense for me to begin to transition over. It probably took 2 years before I completely stopped coding, but having engineering context for a technical product proved useful. I was able to learn the product management basics through peers & resources outside the company as well as a lot of trial and error. 

Another thing to note about Scale - for the first 4 or so years of the company, almost all of the product team was transitioned internally, from engineering or operations. This gave the product team a big advantage context-wise, but unification of processes and best practices was difficult. Now, there’s a mix of experienced and new PMs, which likely helps with this.

As a first-time PM, I made a lot of mistakes, and my peers have told me they’ve learned from similar issues. These mistakes aren’t just relevant for PMs in title, but even for CEOs or engineers as acting PMs as well!

My biggest early mistake was not communicating enough context to engineering, and having to micromanage product development as a result. My intentions were good - I wanted to shield engineers from unnecessary requests and minimize context switching - so, I tried to make myself the single source of truth. I quickly learned that involving all stakeholders including engineers in customer feedback and product specs led to more productive brainstorming, faster velocity, and ultimately a happier EPD team. The product manager shouldn’t be the single source of truth; that said, they should frequently they should be the directly responsible individual, which is different. The DRI is responsible for reporting status and pushing goals & projects toward the finish line. DRIs work with others and involve them in product development, but are ultimately responsible for results.

Another common mistake is when PMs mistake motion for progress. It’s challenging but worth it to create an environment where PMs are valued for saying “no” and focusing on the core business. PMs have a tendency to jump at creating new things, when in actuality that is not the most pressing need of their customers. Great PMs will force customers to stack rank their pain points, and make sure new features or products are addressing acute needs and make sense from a holistic business perspective. Sometimes this means iterating on existing features to make sure the intended metric or outcome is achieved, sacrificing short term revenue, or ignoring shiny objects.

Lastly, I didn’t realize processes SHOULD change and be audited on a regular basis to ensure they are working. No one process fits all, or even the same company 6 months later. PMs are responsible for creating and running many processes including customer calls, prototypes, beta testing, design & engineering sprints, longer term planning, team onboarding, launching, & pre/post-mortems. The best companies revisit these processes as they grow to make sure teams are productive and successful and to minimize chronic issues (for example, tech debt slowing velocity). Ideally, processes are as lightweight as possible and operate sustainably until they need to be changed.

As the business grows, chaos will continue to reign, which is a good thing. You’ll have to make a lot of decisions on how to set goals, design the EPD organization, involve customers, and place new product bets to ensure long-term company success. Steven Jacobs has a great talk later today on the specifics of how to do many of these things, and I highly recommended attending. I’ll talk about them at a higher level. 

For goal setting, introduce a frequency and format that makes the most sense for your company, but make sure you do it and revisit how it works. You might start out with task tickets, then move to one pagers, then more formal product requirements docs, then quarterly objectives and the key results that both the company and individual teams are delivering on. Bias processes towards being more lightweight, building before perfection, & iterating quickly. The important thing is having North Star metrics each team recognizes and is held accountable for, and opportunities to discuss what went right and wrong. Depending on the product, you might use historical performance or external benchmarks to set specific goals. At some point it’s also good to have a vision doc for the company and each product, addressing the industry, the customer, the pain points, and the unique solution & moat of the company.

Org design should also be iterated upon like processes, and perhaps regularly to minimize surprises. Having an EPD team that reports into each other (e.g. PMs report to engineering directors) has pros and cons - you might move faster, but perhaps in a way where all voices aren’t equally heard or there are blind spots. You don’t want walled gardens of product, engineering, and design that sloppily hand off projects to each other, but you also don’t want any team to not feel empowered to make the decisions that they should.

I don’t think anyone would disagree that customers should be very involved in product development, but it’s important to be intentional and prioritize time regularly to talk to them directly and observe how they use the product. Creating detailed customer personas can be helpful for ensuring the entire team knows who the product is for precisely, how they will use it, and why they will care without making assumptions. Another strategy for keeping customers close is creating an advisory board or a more public roadmap, though expectations need to be managed that not every specific request will be done. Great PMs will combine quantitative feedback from launches with qualitative feedback from customers to make better product decisions.

Lastly, it’s very important to always be thinking about the next act. As many of you know, if you aren’t thinking about product expansion very early, you face existential risks later on. There’s a careful balance that needs to be done of devoting a small portion of your team to more speculative bets without losing the core focus on the company. As the saying goes, "if everything is a focus, nothing is really a focus”. Scale did this well - from day 1, Alex the CEO emphasized the importance of being an ML data platform, not just a data labelling solution.

For the mechanics behind doing new product bets well, I’ll point to another portfolio company Rippling. Even as a larger company, they organize as autonomous small teams. There are over 50 startup founders at Rippling, working on various initiatives. Their modular architecture & lightweight processes enable independent projects and promote rapid expansion of the company.

Drew a lot on these peoples’ writings! Highly recommend you check out for more details and templates on most everything I talked about today.

Thanks so much for your time, and I hope this was helpful! You can email me and follow me on twitter here, where I discuss similar content.