Part 2: Leveling up into Product leadership
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.
Product leadership responsibilities are not conferred through a title. The evolution of the product and growth of the org have a far greater impact on when and how your responsibilities will evolve.
For me, the transition occurred when Cedar had grown considerably across the following fronts: the product was now expanding into two distinct offerings, Prod/Dev was now four separate functions (Product, Engineering, Design, Data Science), and our pipeline of existing and prospective clients included healthcare providers from multiple market segments.
Another demonstration of that transition is to show a rough breakdown of my time:
One of my main investment areas focused on the operational side of how Product should function at Cedar. The transition from recipient to the one defining cross-functional processes and structures was certainly enlightening and formed the basis for many of my learnings.
That being said, I should caution that my primary struggle during this phase was whether or not this was actually the best allocation of my time. Failing to realize that there was an underlying question resulted in what I consider to be the gravest mistake from my time at Cedar.
Who is accountable for product strategy?
Of the many questions that may arise as you step into a product leader role, clearly addressing accountability over product strategy with the founder(s) is the most critical. The answer will have a profound impact on what it means to be successful in your new role and will then influence how you should invest your personal capacity.
Given the importance and the fact that I can personally attest to the cost of not driving that clarity, I would suggest two things:
- Have the hard conversation.
- Have it early.
As a product leader, you will undoubtedly be responsible for shaping the product strategy but only a single individual can be accountable for that strategy’s success or failure. The challenge is that the distinction between those two concepts is hazy at best.
One of my favorite Cedar engineering values was “Explicit over implicit”. Regardless if you believe you implicitly understand where accountability lies, remember that it’s hard for implicit understandings to scale to the rest of the org. Even worse, if you’re wrong, the ramifications can be quite extensive:
Misalignment about product investments — One of the core objectives of a product strategy is to give the rest of the org a clear signal on where long term investments will be made across all the various product domains. We repeatedly had situations where inconsistent messages were shared resulting in confusion and exasperating the already natural tendency for product-commercial misalignment to occur.
These escalations end up being the proverbial canary in the coal mine. One or two occurrences may be simple miscommunication but a repeated pattern is a good sign that you need to have (or revisit) the conversation.
General angst across the org — Not as vocal but even more problematic was the growing concern around our long term product strategy. Since it wasn’t immediately clear who would take the first pass at adapting that strategy as new inputs became available, the default assumption was that no one would.
Whether or not that was true was irrelevant. Especially as organizations grow and repeated communication is necessary for messages to be internalized, perception often is reality. As a result, it’s of vital importance that you make that accountability clear to the rest of the company, which can only be done once there’s clarity between you and the founder(s).
Personal angst about your performance — The personal toll should not be understated. As mentioned, it was impossible to know if I was investing my time in the right areas and so it became hard to evaluate my effectiveness in the role.
In hindsight, the investments I made were well suited for an operational product leader archetype. Had I been accountable for product strategy, I would have adjusted my breakdown to lean far heavier on Brainstorming and Sales Enablement.
Neither archetype is inherently better than the other. The more important exercise is to ensure clear expectations are set between yourself, the founder(s) and the entire org.
How do you define new organizational structures?
A few jobs ago, I remember it became a running joke that we would inevitably do a reorg every 6 months. In my mind, it was a sign that leadership had no clue what they were doing. At Cedar in the span of 3 years, I contributed to 6 Product/Maker reorgs and ended up shifting PMs on squads or projects at least 10 times.
Let’s just say it’s illuminating being on the other side.
The reality is that every structure is problematic for their own special reasons and adaptations are natural as the org grows. From a product growth perspective, it became clear it was particularly important to be in lock step with engineering’s growth, although other inputs like Sales growth were also important.
I found the process of evaluating the existing structure involves two key components:
- Clearly articulate the problems with the existing structure. The reality is that you are invariably going to be trading one set of problems for another since no structure is inherently perfect. Understanding the problems will help you assess if the tradeoff is worth it and enable transparency as to why the reorg is happening.
- Think about prioritization globally. It’s valuable to not just ask if the team as a whole is prioritizing the right set of projects and initiatives but if you have the right people on those initiatives. As an example, about a year and a half after launching our initial product, we started to explore an adjacent market opportunity. When assessing overall prioritization, I realized that if I had to stack rank all of our potential investments, given the strategic value of the new product expansion, it made more sense to reassign a PM from one of the existing domains (bonus learning: a key benefit of hiring for generalists early on is the flexibility of domain ownership).
Having gone through the process a number of times, we identified the following framework to help trigger evaluations of the current structure:
Defining a target team size — From the onset, our CTO established the guiding principle that 3–5 engineers was the ideal number per team and since we operated in a pod structure, a PM and Product Designer were staffed as appropriate. The rationale is that any team larger than that will start to experience inefficiency (e.g., standups where the content stops being relevant for everyone) and any team smaller won’t really be able to capture the efficiency of being in a team (e.g., known group of people with necessary context for PRs).
Using recurring planning as check ins — Since one of the main purposes of planning is to take a step back, reflect and identify changes that are necessary to meet the latest business objectives, it’s an opportune time to not just ask what objectives the teams should be working toward but if they are best set up for success in meeting those objectives.
Keep in mind these rituals serve as good check in reminders but shouldn’t prevent you from reorganizing mid-quarter. Especially early on, many of the problems that warrant a structural change to the team will likely fall out of the recurring planning cycle. One of the key benefits of being a smaller organization is the ability to adapt quickly and while the cost of those changes increases as the company grows, it’s important to maintain that advantage for as long as possible.
Part 3 will cover a few takeaways on leadership while navigating the growing pains inherent to startups looking to scale. To jump around, head back to the overview.
