Product management as a discipline is continually evolving, and nascent compared to more mature company functions like sales. Despite this evolution (and sometimes because of it), building products is hard. Our team became curious whether the pains we felt were shared by others in the product management community, so we asked a few dozen PMs and product leaders, at technology companies of varying sizes, what their top pains were. Here’s a brief summary of what we found—hopefully this is as cathartic for you as it was for us.
These are told mostly in the words of the amazing folks we spoke to, and represent an aggregate majority opinion, as 100% unanimity is impossible for something so subjective. Thanks to everyone for the insights!
Summary
(1) Getting customer & market insights is hard.
Capturing input, particularly customer interviews and feedback, is time consuming. Once captured, interpreting customer input is very time consuming, and often there is no time to properly process the input (if at all), meaning that insights remain locked inside volumes and volumes of notes and feedback snippets.
“Recency bias”—the bias that we inherently have to focus on the most recent feedback or insights—is frequent. Moreover, there’s a risk of customer input being skewed towards the distribution inherent in the our customer database (and even more so, the subset of customers who are willing to give feedback). Having too small a sample size contributes to skew and statistical insignificance.
Customer input is often for the purposes of confirming ideas, vs discovering new insights and nuance. We call this “backsolving”, though another way to think of it is local vs global optimization.
Contemplating the industry around customers is also a challenge. Competitor activity is often stressful and blinding, causing either anxiety or knee-jerk reactions (and usually both). It’s also hard to stay on top of market events—there’s just so little time.
(2) Planning is challenging and short-lived.
Planning is great—when it happens. Product planning is time consuming and reduces the speed of shipping product, so it’s frequently abbreviated or abandoned as a “nice to have”, despite how critical all stakeholders say it is.
Product plans themselves often leave something to be desired. They regularly start at the solution instead of the need (see above on “backsolving”). They are painful to coordinate, given they require input from many functions, and when they’re done, they’re difficult to explain, which reduces transparency and makes it hard to get buy in from those same functions! Beyond the cross-functional nature of plans, planning is hard because prioritization is hard—especially when we have to quantify and prioritize something as uncertain and subjective as “customer needs”. Sometimes, plans undo the work of previous decisions and progress, just because we forgot or didn’t consider them—leading to lots of rework, and that funny feeling of déjà vu (“didn’t we already discuss this?”).
And then, at the end of the day, we can’t help but feel a slight lack of confidence in what we’re building or have built—it’s a doubt at the back of our heads, an itch, and it’s hard to avoid when creating something in an environment of uncertainty. (Raising a $30M Series B is a nice way to sweep that doubt under the rug.)
(3) Keeping track is hard.
Planning and executing are not enough—we need a sense of progress, both of what we’re building and what we’ve built so far, and in that realm lurks much pain.
Knowledge of the product is vast, scattered, undocumented, and not easily transferable to new hires or transfers—good luck onboarding new PMs. It doesn’t help that the product is constantly evolving and getting more complex.
Communication and status updating are very time consuming. And maintaining accountability is hard, with metrics either too narrow to have an impact, or too broad to be actionable. This leaves leaders between a rock and a hard place: either you micromanage, or you have no clue what’s going on.
(4) Tools & processes are lacking.
Despite all of the frameworks and methodologies, there is little consistency in product processes. Every framework offers different pros and cons, and it can take a lifetime of product management and leadership to figure out “your approach”. The product communities out there are very supportive, and make great cheerleaders—but when it comes to processes, everyone has strong opinions on one method or another, with a wide range of quality and applicability.
As for tools, a shocking number of PMs and leaders use spreadsheets and homegrown tools. And it’s not for lack of education! Existing product planning tools are either insufficient or bloated (or both). And they can feel like they are encroaching on the core role of the PM: to turn inputs and insights into product direction.
(5) New products are risky.
Product building does not exist in a vacuum—it serves a core function for a company, and it consumes resources. At the company level (that is to say, the executive level), building a product is also viewed as painful, regardless of the company size and maturity, and regardless of the industry. Product building (f.k.a. “research and development”) is a massive risk—it requires upfront investment, has unclear profitability impact in the long run, and may take many years of investment to begin paying off.
~~~
Golly. Why do we build products again? Ah wait, because [all the reasons]. But understanding the common pains felt in product management is important. It’s the first step to us all finding solutions—allowing us ultimately to spend more time on the truly differentiated and innovative work we do.
Our mission is to increase everyone’sinnovative output, so we’ve always been keeping a close eye on ways to eliminate redundant pain in product development and beyond—that’s where Sapeum comes in, to reduce pain in product discovery and strategy. We love pain—because we love to eliminate it.
This is a cross-post with our parent company, Gaussian.
