Yes, It's Your Job: Team Success Trumps Role Definitions
In the 98th minute yesterday, needing a goal to advance, Benfica goalkeeper Anatoliy Trubin did something extraordinary: he scored. This was soccer’s equivalent of a buzzer beater against Real Madrid, the winningest team in Champions League history. It sent Benfica through to the next round.
For those who don't follow soccer: the Champions League is the Super Bowl of club soccer, worth millions in revenue and invaluable prestige. This single win earned Benfica €3 million and qualified them for a match worth another €11 million. It came from the one player whose job is stopping shots, not taking them.
This was Trubin's first ever touch in the opponent's half during the entire competition. You can see his touch map below and the highlight of the goal here. Although extraordinarily rare, this was what the team needed to succeed.
The Role Trap
Product teams face a similar challenge. One of the biggest sources of friction — and missed opportunities — is how teams define roles and responsibilities. Teams spend disproportionate energy arguing over RACI matrices or designating ownership by area, as if carving up property into mutually exclusive parcels.
The result? People operate in silos. Value gets lost at the boundaries. "That's not my job" becomes an acceptable response, even when the team is failing to deliver impact.
Here's what this approach misses: everyone's most important job is to help the team succeed. If the team adds significant business and customer value, each person has succeeded. If they don't, each person has failed — regardless of how perfectly they executed the core of their narrow function.
Yes, clear roles matter. Structure enables efficient collaboration. However roles should be a starting point for contribution, not rigid constraints.
The Team Comes First
The best teams I've worked with put the team first and use roles as a framework, not a constraint:
The product manager ensures the entire team understands customer context, business constraints, and the problem being solved—then involves others in setting priorities and problem-solving rather than handing down requirements.
The designer collaborates with engineering to find solutions that can be easily validated, implemented, and maintained. They advocate for great experiences while seeking lean, incremental paths to their vision rather than arguing for a dream design in a vacuum.
Engineers understand what they're building and why — not just to improve delivery, but to offer alternate or better solutions that others haven't considered.
The data scientist informs priorities, contributes to implementations like algorithms or models, and provides post-launch feedback loops to maximize insights and improve future decisions.
Collaboration transforms a group of individuals into an actual team. If you follow sports, you've seen that having the best individuals doesn't guarantee championships if they don't work together toward a shared goal.
Sometimes being a team means taking on tasks outside your normal scope or helping others perform their roles better, because that's what success requires. The outcome matters more than rigidly adhering to a responsibilities matrix. Whatever it takes to help the team win.
Trubin's Lesson
Which brings us back to Trubin. The team needed a goal to advance and he did what it took. He performed a skill rarely called upon in a pressure situation. He did something he'd never done before, with critical stakes.
The best teams I've been part of had this mentality. Developers have proposed and hacked together critical features nobody else envisioned. A designer, dev lead, and operations manager seamlessly covered for a PM on three-month maternity leave. They didn't say "not my job." They defined their most important job as maximizing impact and winning–with no boundaries or excuses.
Start With Your Purpose
Next time you're defining roles and responsibilities, start with your team's purpose. What problem are you solving together? What does success look like? How will you measure it?
Everyone's number one responsibility is to achieve that purpose. Everything else is a means to that end goal.
How each person contributes will vary based on their skills and experience. But when the moment demands it the best teams don't check the RACI matrix. They do what it takes to win.
Need help building a winning product team? I can help you transform how your team operates to deliver stronger results. Let's talk.
