The Most Important Job of the Product Owner
Should a Product Manager also do UX? Sure! But they must ensure they do the most critical element of their own job first.
Numerous articles have been published recently about the real role of the Product Manager, about the intersection of Product Management and UX, and whether in fact the two jobs are one and the same.
I’d like to weigh in here and say yes, they certainly should overlap, but not at the expense of the Product Manager doing their own job first.
So I guess I had better offer some substance behind that statement..!
First of all, let me say that I really dislike the title of Product Manager. I think it implies that the role of the individual is only to “manage” the task flow of the product team, and I think that greatly demeans the value of a modern product leader.
I prefer to use the title “Product Owner”, and while some argue that “Product Owner” is more helpful as a “label” than a title, I prefer to default to Product Owner because:
- Product Owner is a much better reflection of how a good Product Manager views their own role.
That is, to take ownership and decision-making responsibility of the value that the product delivers to customers. For me, the full wordy title is “Concept-to-Customer Product Owner.”
- Product Owner is a better reflection of the value that the Product Manager offers to the team.
It is of little concern to the rest of the team whether the person in question has attained the promotion necessary to be called a “Manager” or “Director,” but what everyone needs to know, is “who owns the product decisions?”
Should only one person “own” the product?
You may be thinking that every member of the team should have ownership and responsibility for the product. And you are right, I completely agree.
But in many areas of business and life, when “everybody” owns something, in practice nobody owns it. Lack of single ownership leads to indecision, which leads to delays and missed opportunities. It’s like throwing a ball into a small group of people that are all capable of catching it. Unless one person asserts themselves as the catcher, nobody will catch it.
The most important job of the product owner
There is one area where your team cannot afford to drop the ball in this way:
The most important function of the Product Owner is to create a shared understanding for the product team.
Let’s break that down a little.
The Product Manager must, on behalf of the team, own the responsibility of curating and distributing all of the information that the team needs to create a great product.
- Understanding of the customer
Who is the customer? What are their needs? How does that translate to product requirements?
- Understanding of the customer experience
What are the channels and touchpoints that the customer expects to interact through, and what are the paradigms and best practices of those?
- Understanding of the business requirements
What does the business want/need from this product or feature? What does success look like, and what are the fail conditions that suggest we should pivot or pause?
- Understanding of the technical limitations
The PO should partner with the development team to share understanding of what is and is not practically possible given the applicable technical constraints
- Understanding of progress, pivots and priorities
As the product team progress along their journey, the PO must ensure the team knows where they stand, how successful they are being, and what the most important thing for them to focus on is.
It’s about unification as well as communication
The various leads within a product team receive communication in many forms from their respective departments.
- The business lead may bring communication from the C-Suite, the customer success team or the sales team as to what value needs to be created.
- The UX/design lead may bring communication from their team on how the product has performed in usability testing. The storyboards, wireframes and prototypes UX designers create are communication in themselves
- The technical leads may wish to communicate how they have translated the requirements. Even the test scripts that will be executed communicate an interpretation of the value that is intended for delivery.
So when all these parties bring their disparate communications of assumed value to the table. Someone has to own bringing it together, resolving conflicts, deciding what is of most strategic value, and ensuring that the whole product team is aligned.
Share understanding, don’t keep it to yourself
This is not just about being the “go-to guy/gal” that knows all the answers.
Product Ownership is about proactively taking the understanding to the team, so that they don’t have to come to you.
On the Product Owner/UX debate
Getting back to the UX/PO debate, in some teams, a dedicated “Product Manager” can be the Product Owner and partner with UX, Design and Tech. In some particularly experience-led scenarios, it makes sense for the UX lead to be the overall owner of the product. After all, UX is about understanding how the customer will experience the product, which is critically important. Also, a product manager with a natural aptitude for UX has the potential to create an extra delightful product.
But beware the spin!
Together at their point of intersection, the Product Manager and UX lead need to translate the conceptual, into the implementable. That is:
- Understand and define the assumed value that needs to be created for the customer, and how this sits within the business domain. (Product)
- Deliver this assumed value to the customer through an appropriate experience. (UX)
If the two roles of Product Owner and UX lead are to be performed by one person, these two critical concerns still need to be considered separately. If not, what happens — And I have seen it many times before — is this:
- There is no single, shared source of understanding for the team
- The team tries to define and present poorly understood requirements solely through the design process
- The team and execs review the product only in wireframes and prototypes, effectively reviewing both logic and interface at the same time
- If something is considered wrong, nobody knows if it is the requirement that is wrong, or the design
- The UX team iterates on the design again to try and solve, only to repeat
- The cycle repeats, until the team spins out of control, taking the project timelines with it
Separating your concerns
“Separate your concerns” is an idiom I have learnt from by business partner, Sam Hatoum. It is a principle of software development that separates code into areas of responsibility, such that each area can be developed in isolation. This principle leads to order in the face of complexity.
It is also a helpful principle to apply to the design phase of a project, in particular separating the logic layer of the requirements, constraints and goals from the presentation layer. Agree the requirements, logic and domain first, then appraise the ability of the UX to deliver on that.
This way, if something about the UX is not liked or considered “wrong,” the team can ask which is wrong — the logic, or the design, and there is much less “spinning” (rework) as a result.
There are several techniques a product owner can use to separate their concerns and assist understanding. In my next post, I plan to share some techniques for how product owners can use these, and as a bonus, specifically improve understanding of the feature within the dev team, which leads to fewer bugs, greater actualized value and even faster delivery.
But what do you think?
As always, if you have any thoughts or feedback to share on this opinion, please do share it, I welcome it all! If you like this POV, do please click the heart and help it spread.