‘Product vs Design vs Tech’: A Partnership, not a Battlefield
What high performing Product Teams actually look like
This is something that comes up often for me — I get questions like:
“What’s the difference between a Product Designer and Product Manager?”
“There seems to be a lot of overlap between Design and Product Management? Who does what?”
“But if there is overlap who’s ultimately accountable? Who owns which part?”
All valid questions but they all have one problem.
They are all coming from an individual perspective, not a team one — I’ll illustrate what I mean this way.
Consider this common venn diagram depicting the typical triad of Product, Tech, and Design.
As we know these triads are very common in product as each team member, in essence, represents one of the corners of desirability, feasibility, and viability (often called the ‘three lenses of innovation’, widely popularised by the design thinking process).
These three lenses have also commonly been abbreviated to the ‘business’, ‘users’ and ‘technology’. Martin Eriksson, founder of Mind the Product used this terminology and a similar venn diagram to define Product Management.
But going back to the roles themselves, if I was to apply your traditional ‘roles and responsibilities’ approach of creating clearly defined boundaries and individual accountabilities to ensure there are no overlaps between them. Then the diagram would rather look like this.
What typically happens when you do this is it creates gaps between each role. Gaps where knowledge is lost and require additional overhead in coordination and handoffs to bridge.
Another problem with this picture is, imagine if the Product Manager is off sick for a couple of days — or a designer has abruptly had to take compassionate leave — suddenly no one has any clue what they were working on. As a team you're now faced with a hard decision, do we start again or continue forward knowing that there is now a large gap? Neither is a great position to be in.
I often find this situation is created by our desire for instant gratification. This tends to lead people towards tactical solutions, in this case, local-optimisation (i.e. optimising for how many lines of code a developer punches-out or the number of designs a designer produces).
But there’s an alternative, you can be strategic. This is what high performing product teams do — they run a marathon, not a sprint.
The best product teams I’ve been a part of are much more strategic. They look at the full end-to-end product development process (also known as a value stream) and optimise for that.
In these teams, the lines between the roles start to blur and in practice the diagram starts to look a lot more like this.
Having overlap is deliberate and a good thing. It helps create shared accountability and remove any bottlenecks or single-points of dependencies.
In the former world, with clearly separated roles what often happens is that everyone starts in their corner as the “voice of blah”. We then have three different “voice of” all fighting for their side of the fence. An argument ensues which we call “making trade-offs”. Finally, at some stage, we find a middle ground and move forwards.
But in my experience, it’s seldom that simple. Often the “trade-off” is not a true tradeoff. It becomes skewed by whoever has the loudest voice, or by the HIPPO effect (highest paid person’s opinion).
Unbalanced tradeoffs in product are dangerous. We know that great products are built at the intersect and an unbalanced team will lead to building an unbalanced product — this is why equity is so important.
But even if you have equal voice in the team, the whole process of starting at different corners and negotiating your way towards the center is sub-optimal — why not bring each person in the team closer to the center to begin with? This is exactly what the best product teams do.
There really shouldn’t be any “tech vs product” or “product vs design”. A product team shouldn’t be a battlefield, it’s a partnership — a team of people all working off each other’s strengths and weaknesses to achieve a common goal.
How this looks in practice
I’ve been fortunate enough to have worked in product teams that have operated this way, where everyone in the team is at the intersect — all focused on that midpoint of desirability, feasibility, and viability. Where no one was trying to chase the best design, nor the latest cool new tech, rather everyone was simply focused on trying to do what’s was best for the product.
This means that designers pair with engineers to do what my good friend Luca Strazzullo calls ‘Design in code’ — where a designer and engineer pair together to refine product designs live, in code, in real-time.
It also means engineers participate in customer interviews. They are out there just as much as anyone else, having constant and continual contact with their users.
It means that as a Product Manager you facilitate decision making over being the decision mak-er. You co-create with the team, involve them in decision making, strategy, defining the roadmap, etc. Because you want to cultivate a sense of ownership — to make everyone in the team co-owners of the product.
“As Marty Cagan said: “If you’re only using your engineers to code, you’re only getting half their value.” I would argue that is true for all of us — if you’re only using your designers to push pixels, you’re only getting half their value. If you’re only using product managers to groom backlogs, you’re only getting half their value. Etc.” — Martin Eriksson, Your Team is Smarter Than You Are
This doesn't mean that the team becomes a bunch of ‘yes’ people all in agreeance. Nor does it remove all semblance of tension. Healthy tension is still extremely important. The difference is that the tension becomes much more constructive — it is no longer say an argument about why refactoring is so important, or why a certain experience is ideal, it goes one step deeper. Conversations start to be about the nuances of those things — do we refactor now or later? Which part do we refactor first? This design is ideal but what about this part of it? Would altering this section, in this way make it easier to build?
Nor does this mean that we don’t have roles or specialties anymore. They still exist. But the difference is that no one is being measured on the consistency of design or automation code coverage — these individual accountabilities create friction in a team and hurts the product in the long-run.
Rather in high performing teams, each individual has a deep sense of responsibility to the team and ownership of the product. They participate and yearn to understand more about the different aspects of product development.
This helps build both appreciation and empathy for each other's roles and the end-to-end product development process. It also creates greater shared understanding and more continuity, along with removing bottlenecks and any single points of dependencies like those mentioned earlier.
As a result, it's much easier for them to leave their ego at the door and put their personal preferences aside. Each person simply brings their expertise and strengths to the table, not to make their side better or make sure it isn’t “forgotten”. No, they do so to find ways to work as a team to do the best thing they can for the product and their users.
This is what real teamwork looks like.
Teams are more than just a group of individuals
The next time you’re thinking about clear and separate lines of accountability or removing any overlap, I’d implore you to reconsider.
If you find yourself going down the path of arguing about whos going to be accountable for what, perhaps it’s time to call timeout. Perhaps you’d be better of shifting the conversations away from roles and towards the work — what work needs to be done and how can we do it together. Share the burden, help each other, work off each other’s strengths.
I get it, it often makes total sense from an individual point of view, but is it the best thing for the team overall? Is it the best way that as a team you can serve your customers? Or will it create silos, bottlenecks and potentially dependencies on key people — i.e. only the UX Designer can do that…?
Ultimately the best Product teams I’ve worked in, everyone was seen as co-owners of the product, not divorcing parents arguing about whos gets to keep the cat.
Be a team, not a group of individuals.
📣 FYI: I’ve increased my availability for virtual 1:1 PM coaching. If you’re interested — perhaps you’ve started a new role, looking for guidance or want to level up your PM skills — get in touch at antmurphy.me
I’m also launching an online learning platform with deep dives into specific PM topics, like Stakeholder Management, Prioritization, Product Strategy, etc.
Get updates at productpathways.com.
