Feature Prioritization & Internal Strife

For a number of reasons, product isn’t always the most trusted, influential, or understood function. And with uncertain outcomes and rising pressure from investors or a looming cash-out date, absolutely everyone — from executives to customers to VCs — can be seen suggesting, asking, or demanding something from product. PMs can often find themselves grappling with some major power struggles internally. Who decides what you build next? Does data reign supreme or does intuition and vision trump what little data may exist to a startup? Are the developers in charge? Sales? The founders? Just the CEO?

It’s an extremely complex problem that can lead a product — and those managing the product — down a bad path or too many paths.

At one of our monthly Boston Product breakfast’s 20 or so local PMs shared their experiences facing this common problem.

Sizzle or Steak?

Christopher O’Donnell, HubSpot’s VP/GM of new products, told the group about a time when his CEO, Brian Halligan, said to him, “O’Donnell, you’re all steak and no sizzle.” He took that as a compliment, saying he likes to focus on products that people will actually use and features that make the product stickier, reduce churn, help close sales, and so forth.

But more often than most of us care to admit, upper management, investors, and even customers push product managers and development teams to create features with more “sizzle.” These ideas sound fun, fancy, or broad enough to justify high company valuations, but they may not directly affect the product and may break from longer term product roadmaps.

“Sizzle is a way to get attention, and that can work,” said Phil Costa, VP of product management at Brightcove. “But you don’t retain people with it. So maybe these feature requests are useful but don’t wind up as part of the product. Maybe it’s part of a marketing campaign. Gimmicky features are just that — gimmicky. Usually it’s just a matter of time before people figure that out.”

Michael Sheeley, co-founder and CEO of Chef Nightly, added that the reason people initially buy or adopt a product can absolutely be different than why they stay, like a party that advertises free beer to get attendees but winds up succeeding based on great conversation and connections.

In other words, some of the more sensational ideas that feel hollow can, in some cases, become assets in driving adoption.

Thus, the trick becomes balancing the sizzle and the steak — on one hand, the features PMs know will help customers and, on the other, the requests they get from various colleagues in a seemingly unending but ad hoc way.

Three Keys to Effective Prioritization

According to the group, product managers can become great at this balancing act by doing the following:

1. Create an agreed-upon roadmap, leaving space for what may come from various stakeholders.

Rob Go, co-founder and partner at NextView Ventures (and former product manager at Ebay) cited a blog post from Adam Nash, the CEO of Wealthfront. Nash smartly divides product planning into three buckets: customer requests, metrics movers, and customer delight.

In attempting to balance all the internal and external stakeholders they face, great product managers are adept at crafting a roadmap that takes into account (and clearly defines) these different types of priorities. This should then be put into writing and circulated to keep everyone marching forward coherently, according to what was discussed. All future deviations must then hold up against that roadmap.

“That kind of balance is always hard,” said Fareed Mosavat, VP of product at RunKeeper. “I always fall back on top-down strategic planning to solve that sort of problem. From a high level, for the next three months, what are the things we need to be successful as a company? It’ll be a combination of three things: move the numbers, move the vision, and an unknown something else — there’s always a something else that will crop up, like performance or user experience or executive requests.”

He went on to say, “It’s always a balance between what current customers want today and you playing for the future. You need to leave part of the roadmap for the longer term track-laying that won’t return results today but that you expect will eventually make a meaningful contribution.”

2. Have a process, and be prepared to explain that process to others.

Christopher O’Donnell addressed this idea of process first.

“I got great advice from our board once,” he said. “They told me, ‘Anytime you get any feedback from internal stakeholders on what they think you should build, remind that person, whether it’s a CEO or support rep or anyone, that you have a process. Ask if they can help introduce you to some customers to put through that process to gain their perspective. If you can validate the things your coworkers are saying to be true, then you might be able put that into the product.”

He advised the group to level-set with colleagues who come with requests. Ask for 10 prospects or customers to talk to and respond with a positive, “Thanks — that sounds like it’d be fun to build if we can validate it!” This is better than shrugging them off and saying no, since some of the best features could come from outside the product team.

According to Christopher, his team’s goal is to do the light, lean approach to product development, then iterate. His goal is to get a handful of customers trying a feature for free before ever showing it to upper management. And once there’s buy-in, his team begins to determine the fate of that product or feature: Will it be free forever? Is the purpose therefore distribution? Or should it be freemium, with the ability to turn them into paying users? Or does a particular product require longer explanation and require an inside sales rep or team to close customers?

He went on to talk about a fellow product manager that, at first glance, never seems to fail. He wondered why that was until it hit him: She fails a ton, but she keeps those failures small. She fails with a set of five customers, learns, and continues to test and build, until the final feature or product for which she advocates stands a higher likelihood of succeeding.

3. Be confident (but humble) in owning your domain.

I offered my own two cents here, which is to remove personalities and subjective preference from the equation — a tall order.

At Aereo, I remember a roadmap meeting with myself and members of the executive team as we debated which features to prioritize. It wasn’t the first time we’d debated these features, so everyone had started to develop biases and favorites for the different ideas and we weren’t making any progress. I tried something new: I drew a Venn diagram on a whiteboard where each circle represented different business goals (e.g. retention, acquisition, efficiency) and we started to plot features in the Venn diagram.

I was genuinely surprised by the feature that ended up in the very middle. It wasn’t at all what I was most excited about, but rationally we agreed it’s what we should build because it was best for the company and our users.

Christopher chimed in with a metaphor for this idea of owning your domain:

“Don’t be an attorney. Be a judge. Be the best listener, and every time someone makes a case, state it back to them and say, ‘So your idea is XYZ?’”

He continued, “Then think of the counterargument, and just be really good at seeing and arguing both sides. At the end, be the judge and say, okay, this is what we’re gonna do.”

He said that those upfront efforts to plan and define the roadmap also help define your “box” that you own. As a PM, you need to “own and crush that box.” You need the ability and autonomy to make the final call within your predefined area.

Avoid Inventor Syndrome and Seek Out Others Instead

At a startup, it’s up to the product manager to launch experiments and discover product-market fit, then continue to iterate to create enduring, successful, scalable products. As such, PMs need to avoid “Inventor Syndrome.”

“It’s not about you,” said Christopher. Everyone around the table immediately nodded. “If you’re [record producer] Rick Rubin, maybe sometimes you’re inventive, but it’s about surrounding yourself with the right people. He doesn’t walk up to Jay-Z and say, ‘Here’s a lyric!’ No way! Jay-Z is like the software engineer — they’re the real artists, and you’re the producer.”

So, in the end, not only is it common to have a variety of opinions pulling you in many directions — it’s ideal. Then it’s up to you, the product manager, to sift through the noise, be that judge, define the product plan and process, and ultimately remain confident that you own your domain.

[Note: This was originally published by Jay Acunzo on the NextView blog.]