A perennial question for product managers: how do we decide what to build?

There’s no easy answer that I know of. (And anyone who says there is, is probably selling something.) But here’s some stuff I’ve observed, learned about, and practiced.

I’m glad those aren’t my problems!

In enterprise software, we don’t share all of these exact issues, but we’re constantly asking many of the same questions: how do we decide what to build, and just as importantly, what not to? There’s no clear-cut answer to this question, but here’s how I approach it.

Listening to customers — the double-edged sword

But of course, it’s usually not that simple. We’ve all heard Henry Ford’s quote about how if he’d just asked people what they wanted, they would’ve said, “a faster horse.” Likewise, Steve Jobs didn’t just build a better Palm Pilot or Blackberry. Google didn’t just build a better version of Hotmail or Facebook a better Friendster. Breakthrough product “evolution” is really more like Intelligent Design.

Breakthrough product “evolution” is really more like Intelligent Design.

Enterprise software PMs need to understand, and often contextualize, their customers’ needs. Those companies feel acute pains, of course, but most often envision incremental changes to address them instead of systemic ones. They want a better web logs reader, or different ways to organize email threads. Customer feedback is a critical source for incremental product improvements like these (and we should always be making our products better!) — but it won’t always lead you to transformative, innovative changes.

Market Surveillance

I met this guy once at a gigantic conference in Vegas. Our interaction went pretty much like this.

The industry press is one obvious and long-standing source of market intel, but as anyone knows, it’s… well, imperfect at best. Industry press outlets, and the tech media in general, are heavily influenced by marketing spend, professional “thought leaders” looking out for their next consulting gig, and the big blind spots of “access journalism.” All of these information sources are still very valuable. But just like the political and sports press never saw Donald Trump or Middle Tennessee State coming (respectively), their confident pronouncements are rarely the whole story.

(Let’s just say analyst reports sometimes work in a very similar way. 😉 )

Industry conferences can be great — with some caveats. Recently, I attended the MarTech 2016 conference. (I learned a ton — you can read my first reactions here.) What I loved about MarTech was that it wasn’t nearly as vendor-driven as you often see, so we heard a lot more from actual practicing marketing technologists. Yet even at vendor conferences, like Adobe Summit or Dreamforce, there is a ton of golden insight to be mined, as long as can separate them from straight vendor pitches — which are often pretty telling too. In fact, I actively seek out other vendors at conferences and let them pitch me on what they’re doing/selling.

Personally, I’ve found Twitter to be an invaluable source of insight on my market. Doing so has taken a lot of curation, searching, list-making and interaction, but those efforts have been worth it and then much more. (Plus, the process of doing so has made me an expert, like everyone else, at what ails Twitter.😄) LinkedIn is fair at best. Medium is gradually becoming a great source of perspective as well — but it’s still very often a Bay Area-dominated echo chamber.

The competition

Obviously, what your competitors are doing is important in any contested market. You must pay close attention. But I hear lots of PMs focusing more on every specific product advantage or gap than on their competitor’s strategy more broadly. In my digital analytics days, for example, we used to scramble every time Google Analytics released a new feature or update (which was, and remains, constantly) to understand how it squared up — until we realized that, in the long run, it didn’t actually matter so much. Google is an advertising business, and GA helps them sell more ads (a LOT more ads), so they continue investing in an extremely high-quality product that will remain free. That’s a very difficult proposition to compete with, and we had to come up with a radically better overall solution — a step change — to answer it. Lo and behold, we (I was then at IBM) acquired Tealeaf, and later, Silverpop.

The team you’re competing with is almost certainly made up of lots of smart, hard-working people just like yours

Because we’re usually so deep in the weeds of our product(s), enterprise PMs tend to overreact to competitive moves. You should watch your competitors’ product releases, but not freak out about them. In fact, the best enterprise PMs already have a pretty good sense for what their competitors are going to do. This is borne out of not just understanding your competitors’ strategy, but by developing respect for them. The team you’re competing with is almost certainly made up of lots of smart, hard-working people just like yours, who feel the same mix of confidence and worries about their product that you do. Internalizing that helps me put myself in their shoes and anticipate their moves.

The hardest question: Can vs. Should

All of which is just to say: could SAS build a great web search engine or mobile OS? Eh… probably. But we’re not going to do that. I don’t think I’m letting any cats out of bags on that one.

Lots of teams, particularly in engineering-led company cultures, don’t strike the right balance between what they are capable of building (which is a lot) versus what they should build to capture a bigger market share — or even create a new market altogether. In deciding what should be built, Product Management has to not only understand what’s technically possible, but what their larger organization can actually execute with. After all, great enterprise solutions do not just sell themselves. They are sold, bought, implemented and adopted, wherein lies the graveyard of so much opportunity.

A perfect example might be electronic health records (EHRs) — or, actually, huge swaths of the entire healthcare sector itself. There is enormous and acute need for improvement in how healthcare is administered, resources are allocated, people are trained, information is shared, and so on. (Indeed, satisfaction with the state of our healthcare “system” is usually inversely proportional to one’s exposure to it.) American healthcare completely sucks today — but not for lack of our ability to build technology solutions for it! Rather, it’s because those solutions can’t get to buyers and users. There are market barriers at every turn: government regulation, insurers, managed care groups, various entrenched interests, and more.

(Sidenote: did you know we’ve literally spent tens of billions of dollars on EHRs in the last decade, but have little to show for it? True! But that’s outside the scope of this post.)

Look at the public sector or higher education, and you’ll see many of the same dynamics at work. Of course, we in technology (including SAS) do sell software solutions to many of these sectors, but far less than what we could build to help them function better. The barriers to adoption there are just very high. That is partly why we see more innovation in burrito delivery today than in how healthcare and public services are distributed — which is a damn tragedy.

In deciding what to prioritize, PMs need to know not just what the engineers can build, but what marketers can differentiate, sellers can sell, architects can implement, and customers can adopt and use. That doesn’t just call for a meeting — it means understanding how each function in this process works in your company. It’s hard, and none of us do it perfectly. But it’s important to at least understand what those steps are.

Okay… but relax

I’m on the twitterwebs.

👇🏻 Recommends much appreciated. 👇🏻

Product at Salesforce. Holder of strong opinions. I mostly write on my blog, BlairReeves.me, but occasionally post here too.

Product at Salesforce. Holder of strong opinions. I mostly write on my blog, BlairReeves.me, but occasionally post here too.