On architecture and interfaces, for product orgs
This post is primary geared towards product leaders seeking to scale how they operate at a portfolio level
I have often observed budding product leaders (PM leads, Group PMs…) struggle to navigate two unique characteristics of the product leadership role:
As a product leader, you oversee a portfolio of products and bets. Vision, strategy, goals, resource allocation etc. all become more complicated and nuanced when you have to balance what maybe globally optimal at the portfolio level vs. what maybe locally optimal for any specific product or bet. You will need to make difficult tradeoffs, and it’s inevitable that at least some subset of your portfolio and team will be a challenge to manage.
As a product leader, you must lead the leaders & influence the influencers. Your wider role & broader purview as a product leader and manager of PMs comes at some cost of depth, expertise and direct ownership of the product (re: an earlier post on the sacrifices of PM leadership). Your ability to lead through influence becomes more paramount than ever before. And to scale your influence, you must “teach folks how to fish” vs. doing the work or making the decisions yourself.
There is a real “what got you here, won’t get you there” element to navigating the challenges above. PMs typically develop in their early-to-mid careers leading a single product or feature area, and a singular product team. But too often, organizations promote talented PMs into leadership roles without emphasizing enough that they are, in a sense, signing up for a new and different job. Without that perspective, it can be a real crisis when PMs see their typical playbooks fall flat and normal tactics not scale well as leaders.
Folks in this situation may need to hit pause, and consider product leadership from a fresh, first principles lens. In my management and coaching experience, I’ve often found a metaphor such as the one below to be helpful for them to go back to the drawing board:
Imagine your product and team running on top of an invisible, underlying operating system. This operating system needs to integrate many loosely-coupled components to function as a cohesive unit. It also needs to continuously act & react off a large set of inputs & outputs. Some of these inputs & outputs are internal, while others are external in nature. You are the creator, designer and owner of this system. Then ask yourself:
For my product organization’s operating system…what architecture & interfaces do I need to design…for it to operate optimally & scale elegantly?
On “architecture”
The structure of your product portfolio & teams are the architecture of your system; the blueprint you are setting forth to achieve the long-term vision of your product. As with real-world construction, your architectural choices really matter - perhaps more so than anything you build on top of it. Architectural decisions simultaneously enable your creative possibilities, while introducing constraints on what you may achieve.
As you consider the optimal organization of your product portfolio, consider a few paths you may take as inspiration:
Should you opt for a monolithic structure a la the Pyramids of Giza: as strong as granite & limestone, derived from a single unifying identity, comprised of numerous tightly integrated bricks and blocks and presented with a sense of integrity and finality?
Or do you opt for an eclectic structure a la La Sagrada Familia: whose beauty stems from its many diverse components (or ‘micro-services’, should you prefer) that blend together, with serendipitous interplay of its facades & features, and presented to all with a sense of organized chaos and endless possibility?
Or perhaps you may opt for an alternative, custom & bespoke architectural approach a la the Guggenheim Bilbao - a style that bucks trends and seeks to liberal us from conformity, while being tailormade to suit the very specific needs of the product?
Every architectural choice has implied tradeoffs (ex: designing for reliability & consistency vs. creativity & flexibility), so it behooves you to make the effort to clarify & internalize the why behind yours. And to debate and align those with your cross-functional leadership peers as well (ex: your engineering and design partners may have different opinions about the pictures above :)).
Once you determine your architecture, document it. And evangelize it. The clarity of your blueprint is essential to ensure that every team member in your organization knows exactly what they are building towards in the long-term future.
On “interfaces”
Excellent product leaders have excellent judgement. And excellent judgement comes from the combination of deep product expertise with rich context (of customers, company strategy, your teams…). But how can you build that judgement, expertise and context - when you are often at least one degree of separation away from the day-to-day real work?
The answer lies in having excellent feedback loops - interfaces - with the many constituencies of your product org. These interfaces should span the gamut of functions you need to build & ship great products ex: user research, analytics, sales & marketing, support & ops et al. Not to mention, your team of direct reports, key cross-functional peers, leadership, etc.
I will posit that every product org out there has some processes in place to establish these feedback loops. Some orgs may be structured & process-intensive; others may be running on an unstructured internal network of 1:1s and slack messages. Regardless of your culture, the art of a product leader is to ensure they have the optimal set of interfaces (a la ‘APIs’ or ‘service calls’) established within the organization to:
Convey the primary expectations of the product & org. Expectations at this level may range from high-level strategy & goals, to cultural norms, to the quality bar of the product you ship, to the roles & responsibilities across functions & levels, etc.
Distinguish clearly between inputs vs. outputs - and how you intend to engage with them. Inputs are the actions being taken across the product (ex: product strategies, decisions, execution) and outputs (or outcomes, if you prefer) represent the sum impact of those actions in the real world (ex: metrics, user feedback, etc. ). Together these represent the context, the shared consciousness, of the product organization.
Create space for ‘exception handling’ if & when things go wrong. Exceptions in this case could range from site outages to personnel issues to major strategic pivots/shifts in plans based on new information. For example, perhaps you may need to implement some kind of ‘rate limiting’ for teams that are overwhelmed, or a ‘reboot’ for product bets and teams that are struggling.
Many leadership faux pas and heartaches can be traced back to interfaces that are either missing outright or poorly designed. For example, I’ve seen many product leaders struggle because they only convey their expectations post-hoc (ex: reactive feedback in product reviews). Even more commonly, I see newer product leaders have a tendency to seek out and control every input & output they can - which is a fast path to burning out & frustrating micromanagement. These are both patterns that are either less present or less problematic as IC PMs, but can be deal-breakers when it comes to effective product leadership.
Map out your org’s interfaces, the essential suite of APIs you need, to build a successful product organization. Document them, prioritize them and share them so your teams are equally invested as you in making them impactful. And iterate on them as you run your org.
On “version control”
It often surprises me just how impactful it can be for a product organization when its leaders are clear and opinionated about the architecture and interfaces they need. Time and time again, I’ve seen such systems establish deep alignment, unlock higher velocity, nurture a happier team and lead to new creative bets that would not have materialized otherwise.
But I’ve also observed a tendency from many leaders to approach this area with skepticism, or even dread. Talk of architecture can be perceived as a path to rigidity, whereas talk of designing interfaces can be perceived as process & overhead. These concerns are valid and worth addressing - primarily by allowing for things to change, and thus the concept of version control.
At any meaningful scale, product orgs are complex systems. Complex systems are fluid and dynamic in nature, and their points of equilibrium can shift over time. For product organizations: shifts in market dynamics, competitive landscape, technological evolution (ex: as we’re seeing with AI today), or changes in leadership & personnel can all motivate the need for a new operating system - or a new version of the current one. Whatever architecture you put in place today may need to be rearchitected (reorg’d) to achieve newer goals, and whatever interfaces you put in place today may need to be refactored to suit a new team with different people or maturity.
My advice is to approach ‘version control’ with:
Clarity about the expected time horizon of your org’s architecture and the interfaces you put in place. Some changes are temporal and short-lived, while others should be more durable.
Understanding of the tradeoffs of your org’s operating system. Keep tweaking it to make it more valuable, and mitigate its limitations over time. Learn and iterate based on feedback from your teams and other stakeholders involved.
Urgency - when you need to do a major re-architecture or refactor, make it the priority. Ensure that any major changes have clear motivating benefits and are solving clear problem statements that have risen. Seek to understand the downstream costs of any changes you will need to absorb (ex: time & energy you will need to ‘migrate’ folks away from the ‘legacy system’ post a reorg).
I wish you all the best in your leadership journey - onwards!