In product development, there’s a perpetual tension between designers, developers, and product managers.
The designer presses for a product that is desirable. If users don’t love and adopt it, what does it matter?
The developer champions feasibility. If the product can’t be built or can’t sustain anticipated load, what does it matter?
The product manager strives for viability. If we can’t balance the cost of building it with the return of selling it in a way that grows and sustains the company, what does it matter?
The designer wants to spend another sprint testing and polishing the user experience so that users’ needs are met in the best way possible. The developer wants to make sure the architecture can handle scaling to the explosive demand they think is coming. The product manager wants to ship it because every day it’s not out there, potential customers are buying the competition.
So, who is right?
The truth is that great products lie at the intersection of desirability, feasibility, and viability. Unfortunately, very few organizations structure themselves to support this balance.
In traditional companies, the product manager is the sole decider — the “CEO of the product” or the “single wringable neck.” Armed with a perpetual supply of trump cards, the product manager makes dozens of good-faith decisions each day, but the long-term benefits of building something desirable and feasible still fall prey to the short-term objectives by which the product manager is measured. After all, what we measure drives behavior.
At a conference last year, I asked someone I’d just met what her role was on her team. She said, “I’m The Business. Everyone hates me.” The Business. I imagine her slinging explosive trump cards like some sort of corporate Gambit, desperate to make sure she lives up to her responsibility. (And I bet she’s right about her popularity.)
In most organizations, “The Business” is seen as adult supervision for the rest of the team. We expect developers to possess no skill, intuition, or intelligence about business matters. We expect designers to care more about pixels and perfection than profitability.
This view, which limits team members’ potential influence and impact by their job title, sells everyone short. Hard separation of duties, where no one can have an opinion about anyone else’s area of expertise, is the fastest way to ensure a mediocre product.
Putting designers, developers, and product managers in positions where they lock horns in perpetual stalemate — or, worse, where product managers always overrule the others — doesn’t get us to the results we all sincerely want to drive for our organizations. So rather than try to resolve the tension by removing it, the teams I work with have learned to embrace the tension, harness it, and use it get to better product decisions through product owner teams (a concept we first learned of from Jeff Patton).
Product owner teams bring together the three primary leaders on any software development team — the product manager, representing the needs of the business (viability); the designer, representing the needs of the user (desirability); and the lead developer, representing the needs of the system (feasibility) — to provide better leadership than any of the three could do alone. Product owner teams serve the same function as typical Agile product owners: they define the products a team will build and make sure there is a healthy backlog of user stories ready for the team to execute.
In traditional organizations, this happens in a linear flow: the product manager writes the user stories, the designer attaches wireframes or mockups, and then the lead developer then evaluates if the designs are technically feasible. This forces a dynamic where problem solving happens in functional silos. Each team member has their own function, and they can feel successful even if their peers fail. (“It wasn’t the design; it was execution.” “It wasn’t the code; it was the requirements.” “It wasn’t the requirements; it was a terrible design.” We throw each other under the bus as if a blood sacrifice will miraculously transform a failed project into a success.)
Product owner teams are charged, collectively, with delivering a product that is viable, desirable, and feasible. While each member of the product owner team brings a greater depth of experience and knowledge in their area of expertise, the entire product owner team decides on how to balance the three concerns, and the entire product owner team sinks or swims together.
Stalemates are eradicated because all three members of the product owner team are expected to have thoughtful voices about the product and its direction. If the designer wants to spend more time polishing something that the developer and product manager feel is good enough, they ship. If the developer is concerned about scalability and can convince the designer, too, then they spend some time shoring up the infrastructure.
While product owner teams work together to make decisions about the product, they should not be management by consensus or committee. The product owner team structure adds healthy friction, forcing decision-makers to slow down and ensure they’re acting in the best interest of all three concerns. Product managers still have a supply of trump cards, but when product owner teams are working well, they’re rarely played.
Product owner teams help drive healthier product decisions. When product owner teams are functioning well, team members are dialed in to the purpose and importance of their work, and they ship better products.
Product owner teams aren’t something you can just add to a process document. It requires a cultural and philosophical shift toward radical collaboration. Moving from a world where one person decides unilaterally to one where people are expected to work together — even outside of their usual roles and comfort zones — requires a lot of effort.
But it’s worth it — for the health of your products and your teams.