the holy tripod
tl;dr
At a minimum, a Lead PM, a Lead Designer, and a Lead Engineer should form a tripod that leads the product engineering team
The tripod should meet to establish agreed-upon responsibilities and communication patterns, starting from the generally accepted roles
No member of the tripod has the final say on everything, they’re like 3 co-equal branches of product government
Product is a team sport of solving a Rubik’s cube—you can’t change the constraints, so use prioritization and negotiate with one another in a collaborative manner.
Holy Tripod, Batman!
I couldn’t resist. But in all seriousness, the product tripod is a staple in my product belief system (PBS). I believe deeply that every product engineering team should have a tripod at its helm. Hopefully, by the end of this blog post, you’ll agree with me. Although why you wouldn’t just blindly follow me I’ll never understand. 🤷🏻♀️
Introducing: The Tripod
What are the key roles?
Product Manager / Lead PM
Product Designer / Lead Designer
Engineering Manager / Team Lead
Why is it so important?
Successful products aren’t typically created from a single person’s mind, but rather through the art of collaboration between a diverse group of people. Even if your organization isn’t super, ahem, diverse (we’ll address that in a different post—I have thoughts y’all), you can achieve a degree of diversity of thought simply by ensuring these three roles are collectively leading the team.
Tripod+
Sometimes a product eng team tripod has even more legs than three (I’ve been known to call it a fivepod) if you’re one of the lucky teams to have access to one (or all) of these roles:
Data Scientist
User Researcher
Program Manager
QA Lead
It’s fairly common for these roles to either be non-existent in smaller companies, or to be shared among several product engineering teams. Depending on the demands on that person, you may find them being just as involved as the core tripod members, or you may need to prioritize the most important meetings and interactions.
The Tripod and Other Metaphors
Why do we call it a tripod?
What happens when you remove one leg of a tripod? Barring some sort of shenanigans, typically a tripod that becomes a bipod is a… laying-on-its-side-pod. A tripod cannot stand if any of its legs are out of commision. Such is the physics of a product engineering team. It requires a complete tripod to stand on its own three feet and perform to its full potential.
Is it a dictatorship, oligarchy, or democracy? (Dictatorship, right? The PM is clearly the dictator, right?)
Nope.
The tripod is both none of these and all of these. It both listens to / represents its people, but it is not a majority rule system.. It is both ruled by a group of people and gives individuals the power to make final decisions.
If you are working with a PM who’s acting like a dictator, they’re doing it wrong. Please refer them to me. If you are a PM and you’re acting like a dictator, please stop. And also come see me.
But I really, really want a political metaphor...
A much better metaphor is the system of checks and balances most Americans will be familiar with as represented by our three co-equal branches of government. A group of three working toward the greater whole, but with specific, individual areas of responsibility.
Roles & Responsibilities
Why are they doing what is clearly MY job?
The responsibilities of the tripod overlap by design. This can often cause some consternation—someone’s always convinced someone else is usurping their job—but it’s important to understand the primary roles of each member of the tripod as well as the overlapping contributions they may make.
Things I’ve thought or said out loud (to people not in my tripod):
“I just feel like he’s trying to do my job.”
“But I’m supposed to run the sketch sessions!”
“I just need us to get this thing done… AGGGHHHHH”
“But I can’t let them design a solution without my participation!”
Yeah... don’t be me.
What are the definitely locked down and set in stone responsibilities?
Not so fast, rule-follower! While I like to believe stubbornly that these roles are super widely defined and acknowledged, the truth is we are all unique humans. (I’m here for the hot takes.) While there is a general guideline for who is responsible for what, each of us brings certain strengths, interests, and areas of expertise to our tripods.
The lines between each role are bendy… flexible, if you will. They can flex to conform to your unique tripod. The only absolute constant is that you must collectively discuss and define your roles when forming a new tripod. Like any relationship, communication is everything.
What are the more-or-less generally accepted hand-wavey responsibilities?
Product Lead
The expert in target customer needs/problems/opportunities
The main representative of company goals back into the team
The main representative of the tripod out to the rest of the company and customers
The final decision-maker on overall priorities / and or scoping decisions as a result of collaborating with the other leads
Design Lead
The expert in user experience personas for the customer base
The owner of the overall user experience and design aesthetic for the product
The main representative of company design systems back into the team
The final decision-maker on implemented designs
Engineering Lead
The expert in the technical lay-of-the-land for the product
The main representative of technical capabilities, constraints, company maintenance, and technical debt surrounding the product area
The final decision-maker on resourcing and structuring implementation within the product engineering team
It’s easy to say the designer has the final decision on designs and the engineering lead has the final decision on timeline and implementation and the lead PM has the final decision on scope, but it’s much more complicated to piece this together in practice.
Tripod Decision Making as a Rubiks Cube (because we needed another metaphor)
Look, this stuff isn’t simple, so I’m just putting it all out there.
Here’s a common situation that comes up time and time again in product:
-------------------------------------
DESIGN LEAD: Here’s the best possible
user experience
ENG LEAD: Cool, that’ll take us about
6 months.
LEAD PM: Nope. Try again.
DESIGN LEAD: Ok fine we could
cut this piece or phase it in later.
ENG LEAD: That doesn’t really help
us much… PM?
LEAD PM: We absolutely have to have this
piece and this piece, but that piece we could
probably punt on. What do you both think?
[debate for awhile, and comes to shared conclusions]
DESIGN LEAD: Cool here’s a new
design.
ENG LEAD: Would you be open to
changing this design element in this
way? It would save us a ton of effort.
DESIGN LEAD: Ahh, yeah here’s a
revised design.
ENG LEAD: Cool.
LEAD PM: Cool.
DESIGN LEAD: Cool.
ENGINEERS: WAAAAAHHHHHH.
(jk jk)
-------------------------------------
The Rubiks cube represents all of the constraints that the team is working with, and you, as the tripod, have to solve the puzzle together, as a team.
Imagine that your cube has these six sides:
Problems to be solved
Resource constraints
User experience standards
Technical constraints
Time constraints
Prioritization
Now, you may have noticed that “prioritization” seems like a bogus side, and you would be correct. It’s actually a placeholder side. Constraints are unchangeable, but using prioritization we can, in fact, move constraints around to find the optimal product.
Doesn’t fit into a totally important (read: arbitrary) timeline your company has? Ok, turn some rows. Now it fits in the timeline but doesn’t have an acceptable user experience? Great, adjust some columns. Keep working that cube as a team until you’ve got it solved!
The responsibilities of The Tripod
Obviously each member has their own responsibilities within the tripod, but the tripod itself has responsibilities as well.
Ok, what do they do?
Represent a shared front to the engineers on the team
Discuss and debate team priorities on a regular basis
Discuss team performance, concerns, and develop plans for how to address any issues
Cover for one another in case of illness / emergency / babies coming early / whatever
When in doubt, unblock the engineers
Collectively take ownership of the goals and results of the team
Challenge each other in a constructive way
How do we do that?
You may find that you need to meet as a tripod on a structure basis (once a week, once a sprint, whatever) in order to stay aligned with one another. Alternatively, you may find that simply working next to each other and chatting in ad-hoc ways may work for you. Either way, it should be discussed and explicitly chosen.
