Design is a weird way to make a living.
One moment, you’re trapped in a room with people who think your job is to make things look pretty and they’re saying stupid things like:
“Can we just turn up the volume on this a bit?”
“I love your work, I’d just be more comfortable if you gave me three designs to choose from ...”
“Can you make it more intuitive and user friendly?”
“We were looking for something more ... blue. Did you try blue?”
The next moment, the organization is overhauling how it develops products and design is one of the three pillars the new system will be built around (the other pillars being product management and development.) Oh, don’t get me wrong, I’ll take the improved status, it’s just that I’m always suspicious that the folks in the second scenario have no greater understanding of what I do than the people in the first one.
When an organization creates a strong definition for the role of UX lead, they acknowledge that designing products people will actually use requires sophisticated skills and needs to be integral to product development. I have spent a crazy amount of time over the years fighting for that kind of positioning for design, so when the organization has already committed to it as part of the larger team structure, I gotta think they’re more than halfway towards successfully hiring for the role. Getting the right tech lead is roughly the same level of difficulty. It’s getting a good product person that’s the real bitch.
Everybody pays when a product fails, but you can bet the product owner will suffer the most and that’s a big reason they take a larger share of the team leadership than the other two leads. In addition to strong leadership skills, the product owner must also own and evolve product strategy, develop intimate knowledge of target users and actively participate in solving issues as they arise.
Product management consultant Marty Cagan describes the strength of a product person as the “combination of deep customer understanding with the ability to apply technology to solve customer problems.” That sounds like a good place to start the hiring process.
Even after the right person is recruited, I have my own list of things I need the product owner to be good at. Here’s my top five, and let me warn you in advance that they are highly personal and mostly selfish:
1. Hear what others are trying to say
I solve problems. That’s my strength as a professional, whether I’m leading a project’s UX efforts, designing screens myself, or building an entire design practice. I frequently say smart things and when I say dumb things, it is almost always a way to get myself and others to some better understanding.
When I express an opinion, which is often, I’ll work as hard as I possibly can to express that opinion effectively, but I will rarely try to sell it to others. I believe I am more valuable providing data and solutions than I am using my rhetorical skills to convince people to believe as I do.
All of this is to say that I don’t need a product owner to agree with me. I need them to hear, as clearly as possible, what I’m trying to say. I expect them to consider what I’ve said and mash it up with the things she’s also heard clearly from others and whatever else is going on inside her head at the moment.
And if a situation escalates, I need their listening skills to actually get stronger.
2. Lead by example
I don’t need to be inspired by others to do my job well. In fact, efforts to inspire me have usually just pissed me off. I want to be judged primarily on the quality of my work and that’s more than likely how I’m going to judge a product owner. I don’t care how she chooses to do her job as long as she proves to be confident in her own ability to deliver what she said she was going to deliver when she said she was going to deliver it. For me, that is the highest form of leadership (although it does make things easier if whatever she delivers is really good stuff.)
One more thing on this subject: I work for the product, but in the structures of most organizations who use the three-leads approach, I don’t work for the product owner. I don’t expect it to become necessary to explain that to any product owner.
3. Depend on other people’s expertise
I don’t expect unqualified respect (and following a cranky theme from the rest of this article, no one should expect it from me). I’m fine with a cynical-bastard-of-a-product-owner, even if she chooses to underestimate me at first, as long as I am given whatever respect I earn. Sometimes I screw up and I’m fine with losing hard-fought regard when I do. I’m confident, given the opportunity, I will end up on the positive side of that ledger eventually.
My favorite compliment to receive is when someone values me enough to assume I will do a particularly difficult thing and they depend on me doing it extremely well. A product owner with the quality team and personal skills necessary to treat others that way is going to succeed.
4. Convince others without selling
Collaboration can be the most effective way to get project team members and stakeholders headed in the same direction. Working together to build something tangible requires the expertise of those involved and encourages their empathy towards one another.
Compromise occurs at the dark end of the people-moving spectrum. Participants agree to stomach something they oppose if the others will allow them to include something they value. It guarantees that all parties will hate something in the agreement.
Consensus is in the middle of that people-moving spectrum. It is a viable approach when collaboration isn’t an available option and compromise is a loathsome one. Consensus allows each participant to get so much of what they really care about included in the solution that they can comfortably ignore whatever others are getting out of the deal.
A good product owner provides strong leadership, but actively builds consensus along the way. This isn’t about salesmanship. I need the product owner to translate seemingly disparate demands into a common language. I expect them to use that common language to transparently push forward their own agenda by showing how what she proposes will address other people’s needs.
5. Be decisive
Have you ever pulled up to a four-way intersection at about the same time as a driver at one of the other stop signs? If there was a crossing guard at the intersection, he probably signaled one of you to drive through and neither of you likely worried that the decision about who got there first was accurate.
In practice, most of the product and product strategy decisions a product owner makes are like that. The decisions are relatively minor and as long as the product owner is decisive, things work themselves out whether the decisions were the “correct” ones or not.
I don’t need the product owner to be right every time. When she’s wrong, we’ll eventually figure it out and help her with course corrections. I do expect her to be decisive because decisiveness builds a pattern. During the key times a decision is actually significant, that pattern will cause the team to look to the product owner for a decision, which minimizes chaos. Also, the familiarity of the pattern will tend to ease team members' tension.
It’s a simple tactic, but a powerful one. It requires a product owner who is willing to put their ass on the line many times a day.