Thoughts on Product Team Structure
I wrote this originally in order to clarify things for my (then) new team... and then ended up sharing it a bit more broadly before getting a nudge to finalize it as a post. It's intended to read as "what my experience has taught me so far" as opposed to any universal truth.
There are a lot of ways to structure a product org. As with most things, there’s a few ways that usually work and some that are nearly destined to fail. In between there’s a ton of variation that is useful and necessary depending on what you’re trying to accomplish, what the culture is like, how distributed you are, how complex the product is, etc.
This is not “the right model”-- this is the model I like and have seen produce predictably good results for both agile and waterfall shops. It can and should be molded to whatever the business needs, but if you do so you should have a clear idea of why and how to balance the factors that this model is known to handle. A lot of it is about achieving the right degree of specialization and then creating and maintaining healthy tension across functions. The latter of which is relatively synonymous with the “checks and balances” government types like to talk about.
Product Management (PM) | Why, Who & What
Why
PM is responsible for explaining the rationale in clear terms everyone can readily understand. Usually this does not mean setting the biz strategy (this is done by the executive team) but translating it down into what it means for the portfolio or a specific product. For example, “This product is squarely aimed at helping customers discover assets and vulnerabilities, from the smallest to the largest environment” or “The feature’s goal is to streamline setup such that customers on average only require 1 minute to be up and running with basic functions.”
Who
The PM should have a clear grasp of the customer personas and be able to articulate this for a product and feature. Ideally they have a few customers on speed dial who reliably give great feedback. A key part of the PM role is to bring in the customer feedback to the team-- but to do this not by documenting and sharing but by establishing and brokering the conversation with the customer. What I mean by this is that when an idea is being vetted, the PM structures the interview question and picks the customers, but then invites Engineering (Engineering Manager, the Design Lead, etc.) to join the conversation. PM is not responsible for proxying the entire conversation back to the product team-- only making sure it happens and translating it down into the “What” (plans).
The PM role is much bigger than just translating customer needs and feedback-- there are many other inputs (e.g., biz needs such as margin improvement, new market entry or proving out total addressable market in advance of an IPO) to their decision making that needs to be weighed and considered.
What
PM owes the rest of the org a clear description of what is being built that is detailed enough for anyone to understand-- but not so detailed that it crosses over into exactly how the feature is built. The rationale for the departure from complete specificity is that others want and need the freedom to design and build freely— they need a plan, not a recipe or a blueprint.
This starts with a hypothesis around the MVP that is vetted with customers and other stakeholders. The PM leads the vetting process engaging with customers, internal stakeholders (Sales, Finance, AR, etc.) and anyone else that makes sense depending on what the initiative is. PMs are not the only ones who can do this-- if an effort is tech infrastructure it may be led by engineering with a PM helping out as needed… or not at all. But for customer facing capabilities, this should nearly always be a PM. Further through the process, the PM steers the effort as demanded by the needs of the initiative, adopting more or less of an active role based on what’s required by the project at hand to meet its objectives.
Importantly, it is not the PM’s job to be right, but rather it is the PM’s job to lead the organization to the right answer. Hence, presenting a few well-researched options (with pros/cons and a recommendation) is always better than a single “here’s what we should do”. Why? The best plans are created when all brains available are harnessed and even when there’s a clear recommendation people will buy-in more completely when they have a choice (versus an edict). Buy-in is essential to execution. Execution is how things get built and launched effectively. So the PM’s job is not to just “do their job” but to galvanize the organization with clear direction to deliver as the whole team understands the problem, not solely one person. The need to harness the intelligence and enthusiasm of all necessary parties is what makes PM hard-- not the pressure to be right every time, which is impossible and entirely too much pressure for anyone.
Engineering | How
Engineering’s role is not nearly as often confused as others so I’m going to keep this short-- Eng is responsible for designing, building and deploying the product.
Since the word “design” can be contentious, it requires clarification: the work done by others in the product org to define features or entire products cannot be so detailed it stifles the eng team’s ability to be creative and arrive at the best solution to meet the defined needs for an initiative. The PMs are responsible for creating enough clarity and direction for eng such that they can design, build and deliver. That’s it. Anything more can compromise buy-in or constrain the team. Eng is equally responsible for not going into a black hole during the process-- they have to maintain a dialogue with others (e.g., via scrums, ad hoc channels, etc.) to make sure the team stays aligned. PgM helps with this too by creating the structure which makes maintaining comms and alignment easy for Eng.
Great products are built by the functions working together with people “swimming in their own lane” and respecting role differences-- not by tossing things over the wall when their part is “done”. Everyone is accountable for the success of the initiative and/or product-- not just the PM. I prefer not to use the term “product owner” for this reason-- I want the team to own it and especially the functional leaders assigned to the effort.
This begs a question about Design or User Experience (UX)-- it can sit either in PM or Eng without a problem though I prefer UX has a place alongside PM and Eng— they need an equal seat at the table. Why? A healthy UX team is doing customer research alongside PM and also walks the line of designing enough so that the intended feature is clear without being unnecessarily constraining for engineering. This can mean wireframes and style guides, but not handing over a finalized, complete UI which would disenfranchise a skilled, engaged front-end engineering team.
Program Management | How & When
First off, Program Management (PgM) is not project management. It’s much more than that-- PgM is responsible for making sure the entire product development lifecycle (PDLC or SDLC) is well-defined, well-documented and running as efficiently as it can be. Efficiency demands both measurement (metrics) and continuous refinement. Hence, PgM is the one team that sits both inside the PDLC as they help run it but also sits *outside* the process so that the science of how the process is working receives the right level of attention.
Imagine a manufacturing process where the designers handed over the blueprints to the engineers to build the product but no one bothered to design the manufacturing process itself-- how pieces flowed from one step to the next. And no one bothered to document it. Or measure it. Crazy, right? Think about Chipotle-- what if the food arrived with the menu to the franchisee and then the workers were simply told to “build it” without the clearly defined and carefully tuned process moving from tortilla down to the cashier. Burrito mayhem would ensue and your food would suck. You get the gist-- you have to pay an equal amount of attention to the process of *how* things are being built as you do to the design of the product itself. PgM owns this and the best of the bunch are enamored with the science and relentlessly improving the process. They are simultaneously priceless, annoying and absolutely essential.
The more distributed the team, the more dependencies to manage, the more change… the more PgM you need. And the reverse is also true in my experience.
How
The PgM team leads the answer to how we build products-- they lead the definition and continuous refinement of the PDLC itself (as opposed to the design of a product or feature). The clearly do not do this in isolation but much like PM, they drive the design leading scrums, retrospectives, postmortems for incidents at times, etc. The daily execution of the PDLC is led by PgM but when it’s spinning like a top little guidance is required from PgM for routine efforts. People know what to do and they do it. Processes work.
PgM is often responsible for the portfolio tooling used for scheduling and tracking initiatives such as Confluence. They also maintain PDLC metrics wherever is most appropriate.
When
PgMs are not responsible for setting dates (Eng does this, PM picks launch timing), they are instead responsible for driving the process by which timelines are set and communicated. How does this work? If the agreed upon protocol is that the team is to pick a quarter given that it is early in the process, PgM makes sure they do so and do not change the quarter when no one is looking. Further along, they push the team for a month. Then a specific date. They make sure the launch process is followed when appropriate. They help run the ship room if one exists. When they do their job right things are clear and boring… it’s unfathomably cool.
PgM calls status— red, yellow, green— and pulls the team together for working sessions when things go off the rails. The often see problems first and are expected to proactively drive resolution.
PgM is oftentimes the voice of reason, pushing back on PM when they get too aggressive or prescriptive while delivering a healthy nudge to Eng when they’re sandbagging or not following process. They are often not loved but if they do their job right, they command respect across the organization.
PgM will often be expected to capture notes and action items, but their job is not to take notes for others or simply perform admin tasks for the team. In fact, oftentimes they are running the meetings and are the worst choice to record key points and AIs.
