Part 1: Building the first product team at a startup
I’m embarking on a series called Growing in High Growth that covers some learnings from my time at Cedar, an early stage healthcare startup. For those who would appreciate more context, check out the overview.
There is an addicting quality to launching products for the first time, especially in a new startup. The entire company is really just a single team all working toward the same objective. The chaos from the last minute preparations only ratchets up once the product is live and real data shines a helpful spotlight on all the incorrect assumptions that were previously made.
While simultaneously prioritizing necessary enhancements and preparing for future launches, you may find yourself also being asked to establish a nascent product team. Navigating the challenges of standing up the first team requires you to periodically step back and I found it beneficial to use key questions as prompts for broader reflection.
When should I make the first hire?
I’ll start by being blunt: you’re going to bring on your first PM too late.
I’m sure there is a lucky minority that will have the good fortune to avoid this mistake. Had I been successful at hiring the first person I offered, I would have never internalized this learning, likely confusing good fortune for skill.
The reality is that there is so much working against you in timing this well:
- You’re going to be crazy busy. Your day job as a PM has picked up once the product went live and you now have all of these extra jobs (definitely sales but maybe also support, research, etc…). You will very naturally push back on the idea of adding something as time consuming as hiring to your plate. Even once you decide to start, you will likely fail to prioritize it high enough.
- You’re going to underestimate how time consuming the process will be. Even if you hired PMs before, it’s very likely you did it with a robust internal hiring team that had an established sourcing strategy and at a company with a bit more brand recognition.
- You may have resource constraints making you cautious on when you should even entertain bringing on another PM. Even if you don’t have those constraints (congrats on the raise!), you’re going to have a little voice in the back of your head that reminds you that the best product teams operate at overcapacity since resource constraints force hard tradeoffs. That voice isn’t wrong, it just doesn’t tell you that there’s a fine line between overcapacity and underwater.
The main learning was realizing that my worst case scenario of hiring too slowly was wrong. I had always believed that the cardinal sin of product development was a blocked engineering team. While a disastrous outcome, the reality is that any PM worth their salt can avoid that situation by prioritizing smaller and smaller features because you don’t have time to scope out larger, but more meaningful, investment areas.
The real problem is how easy it is to sustain this state of living a few days ahead of engineering for a really long time, not realizing you risk killing your product by death of a thousand enhancements.
The good news is you can use that tradeoff to your advantage. The very first time you consider deprioritizing a more impactful feature due to capacity is a clear signal to start scoping out the next PM hire. While the odds are still stacked against you, being proactive will allow you to set expectations with the org (and yourself) about the necessary tradeoffs in order to address the capacity problem in the long run.
When should I stand up a formal planning process?
Coming from companies with more established product processes, it felt odd to not have any type of formal recurring planning. However, given the immaturity of the product and company, each new data point had a tendency to create fairly substantial shifts in prioritization.
What I found was, like any process, planning shouldn’t be introduced for its own sake. While you should always have some type of long term perspective on where the product is heading, introducing a more formal planning process should be done when there is a clear value proposition.
At Cedar, three forces influenced the decision to introduce quarterly planning:
- Transparency and Trust. As we expanded our product to more clients, it started to show signs of strain with bugs and new use case requirements. Simultaneously, the Cedar team was growing and visibility into what the product development teams were focusing on and why became harder to communicate to the rest of the org. The combination led to a rapid loss of trust that the we were investing in the right areas.
- Differentiation in market. Beyond implementing new clients, we were also starting to sell more prospects. Not only that, the overall market was getting more mature and our competitors began to emulate our marketing language. As a result, we needed to arm the sales team with a longer term vision that could serve as a differentiator while also setting expectations on what could be done in the short term (i.e. next 3–6 months).
- Product team growth. Product was about to expand from just myself to a team of 3. As we split up the product, introducing planning helped ensure that they would feel true ownership over their respective domains. In addition, it held the team accountable to focusing on the market and longer term strategy as opposed to just execution.
Shifts in the plan, potentially dramatic ones, will still happen. At the start of the very first quarter we began with a defined roadmap, we landed a deal that caused us to not just throw out the entire backlog but also to temporarily reorganize our entire team. For that very reason, it’s important to reiterate to the company that the goal was never perfection but rather visibility into what was being considered and the rationale into how they were prioritized.
How should I evolve my role?
Bringing on new PMs is a natural signal that your role will need to evolve.
Even if you’re not on track to lead the Product function (although I address a learning with that transition in the part on Product leadership), it’s important to play an active role in that evolution. With the benefit of hindsight, two areas of investment stand out.
Delegating ownership — A feeling that I remembered dreading from prior roles was a sense that I did not truly own the domain I was overseeing. Upon reflecting on those experiences, I ended up defining true ownership as the opportunity to fail (and succeed).
There are many forces, especially in a high growth environment, that make it tempting to take back your former IC responsibilities once you’ve relinquished them:
- Failure feels particularly costly when a product is still maturing.
- You will be more efficient by virtue of having all the context on the product and market as the original PM.
- You have all the existing relationships so people will naturally ask you questions first or add you to meetings.
The problem is that each time acquiesce, you become the safety net that undermines that PM’s feeling of ownership.
Preempting that outcome requires you to be both deliberate and active during the transition. Deliberate in that you will need to think carefully about an onboarding plan that both defines the area of ownership and then gradually exposes the new PM to that responsibility. Active in that you will need to fight the external forces pulling you back in, namely guiding product questions to the appropriate public channel or PM and reiterating the PM domain ownership so they are included in the relevant discussions.
Establishing Product as a function — As the team takes on more of your IC responsibilities, one area of investment that will end up taking an inordinate amount of time is intentionally defining the function of Product. While the definition will solidify organically as the rest of the org observes the actions of you and your team, ongoing intervention is required in order to shape the narrative starting the day you join and only increases in importance as the team grows.
- Define the value of Product. There are many reasons why being a PM can be a dramatically different experience depending on the company. The type, the stage, the industry, etc… all play a crucial role in influencing where Product adds the most value. As a result, it’s important to first understand the value of Product in your particular organization. Given the specificity, I plan to discuss this topic shortly as a standalone story.
- Find opportunities to be proactive. While there are a myriad of tactics you should use (e.g., reiterating the role of Product when sharing the output of planning), one I stumbled on unintentionally was giving a new hire onboarding course on Product at Cedar. The content had to evolve along with the product and strategy but largely covered the current state of the product, the market, the competitors and the longer term roadmap. It also served as a great way to meet all the new hires, especially during times of growth.
- Be conscious about where you and your team spend (or don’t spend) their time. As alluded to above, the org will ultimately build a definition based on where you and the team invest your capacity. However, it’s equally important to be aware of what you and the team are not doing consistently (or at all). For example, I defined an APM role that wasn’t responsible for interacting directly with senior stakeholders. However, in an enterprise environment, it’s a crucial expectation from Product as a whole. Given the inconsistency, it led to confusion across the org whether or not Product was expected to be client facing.
