Data, demand & delight
3 ways to set the right priorities for your team
“You were wrong.”
When you’re in charge of a team you’ll probably hear this at one point. User testing will prove that the changes you suggested are absolutely stupid. Metrics will show you that the functionality your team slaved on for months isn’t actually being used. Twitter mentions will tell you how much trouble users are having with that beautifully designed crisp feature of yours. As much as you try to have the right hunch, being wrong is part of the job.
The trick here is something successful managers have known for a long time: communicating a decision is better than just making one. Sharing why your team should give something priority is as crucial as how or when. Having a transparent framework for making a decision helps rally people to get it done.
I’ve always liked the way Adam Nash described this problem and I’ve adapted it in the following way. Each priority for a product can be looked at and debated from three basic dimensions.
1. Data
Hard numbers are pointing to a specific direction that’s difficult to ignore. Other similar features of the product could for instance be showing that it should theoretically work. Maybe there’s an A/B test or a prototype that you’ve successfully tested that’s really pushing it over the edge. The numbers are super supportive, and it’s hard sometimes to put that to the side.
The caveat is really in the interpretation of metrics, which can be at times misconstrued. It’s hard to measure what you don’t know how to accurately measure just yet. Also, what might influence metrics on the short term might have different unforeseen consequences in the long run. Are you convinced they’ll hold up?
2. Demand
Your inbox is full of customers complaining about a fix for a particular problem. The support team is going nuts and it seems obvious to them that this should be fixed. Others in your team might feel the same way, like an itch that some of your team members or even your CEO would love to scratch. Everyone wants this to happen.
Sounds like you should do this, right? That depends. Demand can be blinding. Users can ask for one thing but actually need something completely different. “A faster horse” and all that. And what you think is important as a team might not be high on a user’s wish list at all.
3. Delight
This one is really hard to argue for. It describes a feeling, a subjective emotional state of mind your user is in while they consume what you’ve built. Using something delightful sucks you in. It plays with your imagination. It makes you giggly and excited. You’ll know it when you see it. It becomes something that you feel is right, just because it gives you so much personal joy or makes your product just that little bit more polished. And maybe that’s true for your customers or users too?
Be careful though. Delight can be a slippery slope in a discussion about a product. Often it comes down to a personal, irrational preference. But in my opinion delight is something so overlooked that you need to specifically call it out in a discussion about priorities. If you don’t, you take the life and wonder out of a product really fast.
Overlap
When you consider all three sides, there’s bound to be some overlap.
Got 1?
You might be missing some background. This is usually a good indicator that you need to think about the problem a bit more deeply. Time to talk to your customers, your team, anyone, and start testing and learning.
Got 2?
That’s good. Now you have the ammunition to go forward. Just be aware of the one that’s missing and the risk that comes with that.
Got 3?
It’s a freaking unicorn! Yay! Go forth and sprinkle that magic priority dust across your team. (Just don’t get it in my keyboard.)
If this happens once in the lifetime of your product, that’s a miracle. And you did check all these three dimensions thoroughly, right? Right?
Transparency
This is not a super power. Thinking across these three dimensions won’t save you from screwing up. Even a calculated hunch can be a wrong one in the end. But it does make it transparent for everyone involved how decisions were made, what influenced them, and possibly even why you ended up being wrong. It’s the quickest way to motivate your team around a common goal.
So ask yourself: does everyone on my team know why we’ve made this priority? If not: take a breath, walk around, and look at it from three sides.
Thanks to a bunch of friendly product managers, fellow Googlers, and folks at ProductCamp for their feedback. Have you bumped into similar situations where these three dimensions worked for you? Let me know.
