The Distance to Here

I have this theory. I haven’t been able to prove it, but the evidence is racking up, so I wanted to share it with you. It goes like this:

Article Continues Below
The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.

There are cousins to this theory, but they usually blame a generic “large organizational culture” for bad products. I don’t think that relationship is causal enough, though. See, as organizations grow, hierarchical layers are added to deal with the growth, and I believe it’s the distance that creeps in between makers and managers that makes it so much harder to build a good product.

This is not really anyone’s fault. We need executives and product leaders to set the vision and the strategy as companies grow—it’s an essential part of building a cohesive product and company. The problem is that the vision and strategy set by those leaders are often not in line with what will make end users successful. This is the arena where makers spend their days, so we have a pretty big disconnect.

Here’s how it happens. A brilliant product manager gets promoted (because hey, they’re brilliant!). The product manager continues to excel, and eventually becomes VP of Product. This is awesome, except for one issue: the VP doesn’t have time to work on the product any more. Their time is now spent elsewhere: executive meetings, customer calls, roadmap presentations, 1:1s with their team members.

These meetings and activities open the VP’s eyes to serious areas they have never been exposed to. Instead of worrying about the details of the product, they now have a new set of worries. These include things like conflict between the Sales team and the Product team, the difficult balance between monetization and end user needs, the right way to talk to analysts and reporters. It becomes all-consuming, to the point where the product strategy and vision starts to reflect these new values.

Slowly, because of the nature of a more outward-facing role, the strategy shifts from how to make the product better, to how to market the product better. This seems like a good idea on the surface, but we sometimes forget that marketing is incapable of creating a need for a product. Marketing can only shine a light on an existing user need, and how the product solves that particular problem for a user. But the press cycle waits for no person, so the VP soldiers on, determined to tell the best story they possibly can.

Meanwhile, in the trenches, the remaining (and a few new) designers, developers, and product managers continue to do what they’ve always done. They uncover user needs, they prototype solutions, they do user testing, they release and iterate. But before long they start to see some changes in their directives. The product strategy message becomes less about prioritizing problems to solve, and more about prescribing what features should be in the product (and when they need to be there, human capacity be damned).

It is at this point that The Distance officially becomes detrimental to the product. It is this moment—when you realize that you’re building features instead of solving user problems—that all the red flags should go up. This road leads nowhere good. It leads to a bunch of unfinished, fancy features that no one wants, but that plays well to the press and “growth hacking” gurus.

Lucky for all of us, there is an effective antidote to The Distance. It’s been tried and tested, and it has no negative side effects (lots of positive ones, though). Jared Spool described the antidote best in his 2011 article, Fast Path to a Great UX:

The solution? Exposure hours. The number of hours each team member is exposed directly to real users interacting with the team’s designs or the team’s competitor’s designs. There is a direct correlation between this exposure and the improvements we see in the designs that team produces.

The way for the VP of Product in our story to close The Distance is simply to carve out some time to observe real users with the product. There are a few reasons this works so well:

  • It makes it impossible to lose empathy for users. I haven’t met a human being that doesn’t feel personally affected when they see a user struggle with their product.
  • It makes it impossible to prioritize features over needs. Observational user research has the remarkable ability to elevate conversations from the weeds of features to the overarching user needs and problems that the teams should work on.

The beauty of this is that the VP doesn’t even have to do this a lot. In his article, Spool recommends a simple formula: two hours every six weeks. That’s totally doable, no matter how busy you are.

There’s this story about tuning forks that I really like. When you have to tune 10 guitars, you don’t just use a tuning fork for the first guitar, and then use that guitar to tune each subsequent one. Doing this would pass every little mistake onto the next guitar, and the last one won’t even remotely be in tune. Instead, you pass the tuning fork around, and have everyone tune their guitars to that one true source.

The same goes for product development. You don’t pass a vision along The Distance from one team member to another and hope that it comes out right on the other end. You use customers as tuning forks, and make sure that everyone in the organization is in tune with that—the one true source. It’s the only way to erode The Distance and continue to make great products as an organization grows.

3 Reader Comments

  1. I’ve just been talking about this, but focused on helping people find more meaning in their work. Creating a better product is also a useful side effect.

  2. Great! I just had some problems about organization grows, and you view make me clear, thanks!

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA