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.
PMs for big consumer tech platforms that serve millions (or even billions) of people have a wealth of approaches to choose from. Facebook, for example, has teams of UX researchers that they deploy all over the world to do extensive, original qualitative research on how different populations use their product. Focus groups, surveys, A/B/N testing, the whole gamut. Google, true to their reputation for data-led optimization, practices some extremely sophisticated multivariate testing to constantly optimize their page layout, ad schemas, and even typefaces and colors, right down to the pixel level. Twitter’s product team grapples with many of the same issues, but with added technical difficulty stemming from doing anything there globally, in real-time, and at the scale of 6,000 tweets/second. 😳
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
The most obvious route to planning your product development is to ask your paying customers what they want, and then go build that thing. And hey — if they will then pay you more for whatever that thing is, and it helps you acquire lots more customers, then we’re pretty much done here. Cheers!
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.
Knowing your industry and market cold is a must for any good PM. But I’ve met product people before who sort of… slip into cruise-control mode after a while. They stop learning, searching out new perspectives, or trying to validate what they already “know.” It’s no secret, either, that this is more an enterprise software thing than consumer. (Though I find it much less common than the stereotype suggests.)
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.
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
At SAS, we build and sell the best business intelligence and analytics tools in the world, full-stop. Our Research & Development organization is filled with thousands of the best software engineers and analytics pros working in technology today. Folks who don’t live in North Carolina might not know that SAS literally built its own feeder pipeline for computer science, mathematics, statistics and analytics talent from next-door NC State.
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
Ultimately, a big part of an enterprise PM’s job is fundamentally understanding how her/his product fits into their customer’s business. Does it make your customer’s work easier? More effective? More impactful? Does it do these same things for your user? Can you sell it? Understanding and answering these questions is what makes product management an intellectual and operational challenge. If you’ve got the privilege of being in the position to do so, enjoy the ride. And let me know what works for you.
👇🏻 Recommends much appreciated. 👇🏻