🔥Hot take: Product Management isn't hard
Companies make it unreasonably harder than it should be though.
I wrote the title and a few pointers for this article long ago — even before this Substack was live. Then I read
's article What Good PMs Don’t Do, and it inspired me to finish it.“Product management is hard” is a common trope. But here is the deal: The PM's job is straightforward. PMs need to deliver business results through products that customers love. The mechanisms for understanding customers’ problems, coming up with solutions, and validating those are not rocket science (unless you work at SpaceX). Product delivery is even less so after the release of the Agile Manifesto in 2001 (!), and all the amazing tech infrastructure and tooling we have nowadays.
Yet, Product Management feels unreasonably hard to do well. In most companies where it happens, good product management occurs despite, not because of, the company's processes and systems. PMs often do their jobs feeling like an anchor is tied to their ankles.
In other words, most companies make doing good work as a PM unreasonably hard.
Here are a few common things companies do that make good product management very hard:
1. Bad direction
It's the first because it is so prevalent, even in otherwise good companies: either there is no vision and/or strategy, or they are very fluffy and ambiguous to the point that they are not useful in making decisions. Other signs of bad direction are trying to be all things to all people or the classic “the strategy is to grow revenue by X” without any indication about the choices being made for that to happen.
This leads to conflicting priorities, with product teams being pulled in multiple directions by the loudest stakeholder or the latest burning fire. The result is a product that doesn't know what it should be to whom, which is not good for anyone — including the business.
What to do instead: Ensure there is a clear company and product vision and strategy. Evangelize that at every opportunity you can. As a leader, you have to help teams say “no” to distractions.
2. Top-down feature mandates
Closely related to “bad direction,” leaders delegate features for the “tech teams” to build. PMs become order-takers and project managers. Product development teams stop serving customers to, instead, serve the business. Features are launched but with little business results. When they fail to move the needle, the leadership pushes for another round of top-down feature mandates—because, this time, it will work. We *just* need to build X.
Why does this, often called the “feature factory mode,” not work? Aren't the leaders the smartest and most competent people in the company?
Firstly, experience shows that such an approach leads to a low 20-30% success rate. This is because no idea survives the first contact with the customer, no matter how smart one is. The key is to learn and iterate fast—the best teams do anything between 15 to 30 iterations per week. Of course, if the team's goal is building a feature, they can't iterate effectively towards the business goal behind it.
What to do instead:
If you are a leader, delegate clear problems and goals to product teams (outcomes they need to achieve) and let them figure out how to tackle them best.
If you are an individual contributor, before committing to building it, ask the stakeholders what goal they want to achieve by building the feature. Before you start the work, record what the stakeholders thought would be achieved with the feature, and then after the launch, report on the expectation vs. the reality.
3. Long output-based roadmaps
Businesses crave certainty. They want long (6/12/24 months) roadmaps that detail what features will be delivered and when. The best quote I ever saw about these roadmaps comes from Drift's founder, David Cancel:
"Either I'm going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it's not, or by changing course and having lied to you."
Product teams know the roadmap is a complete fiction. It's our best guess at the time—and if we are doing our jobs well, our knowledge will be very different three months from now. The only certainty is that it won't play out like in the roadmap.
What to do instead: Businesses are not wrong in craving certainty. We just need to be clear about what can be certain and what is instead a Quixotic quest for unachievable certainty. There are many ways of doing this, but I recommend splitting a roadmap into a short-term (1-3 months) section, where features/outputs are listed together with what outcome they should impact. Further into the future, everything is expressed as problems/goals (outcomes). You can even sprinkle solution hypotheses for those, but people reading it must understand that they are hypotheses based on our current knowledge.
This way, the business can be more certain about planning (which goals/problems we are committing to tackling) without shackling itself to a list of features that will fail.
4. Discouraging discovery
Some businesses hate “discovery,” almost as a dirty word. It implies they don't know what they are doing, not to mention that leaders tend to believe they know what is necessary (see “top-down feature requests” above). At best, it is seen as a waste of time.
Leader: — Why are you wasting time? Just deliver feature XYZ. It's *obvious* XYZ will be a game-changer when released.
Narrator: — It was not a game-changer.
There are overt ways to discourage discovery (e.g., “Product teams are forbidden to talk directly to customers; you can talk with sales; they know our customers best”) and more subtle ways (e.g., “Is that what you discovered? I knew that already. It's obvious”).
To be sincere, it is not (only) companies to blame. Many product teams have no clue what they are actually “discovering” and how to go about it. They spin their wheels and/or spend too many resources (usually time) with little to show for.
What to do instead:
If your company is allergic to “discovery”, frame it as “risk mitigation”. Businesses love mitigating risk (see the love of certainty in “Long output-based roadmaps” above).
Do not test whole ideas. Test the riskiest assumptions underpinning them.
100% certainty is too expensive. Instead of thinking about the perfect discovery and validation, ask yourself, “How could I have some evidence (not proof) that the assumption is true or false in less than one hour (or day)?” Cue to one of my favorite stories about fast validation:
The team at Google Glass had the hypothesis that the user interaction with the Glass would be through gestures akin to Tom Cruise's Minority Report:
To test this hypothesis, the team was going to build a prototype that would take 2 months to be ready. Tom Chi, then Google Glass PM, challenged the team to come up with a way to test that assumption “today”, instead of in 2 months. The team said it was not possible, it would take more than that just for the prototype to come from the workshop. But he kept pushing “how might we test this today?”
The team found a way: they used a computer connected to a projector, which in turn was connected to a rubber-band glove and a slide clicker. This way the user would have the feeling of changing the images on the screen with their hand movement. Half a dozen usability tests in, they were pretty sure that was not the way to go, because all the users complained of shoulder pains. It was just uncomfortable to the human anatomy to interact like that. Imagine if the team had taken 2 months to disprove that hypothesis instead of just one day? If they could do it with a hardware product, what is your excuse for taking a month to validate assumptions in software products?
5. Bad organizational structure
Another common way to hinder product management is using inefficient organizational structures. There are several anti-patterns I experienced firsthand:
Highly coupled teams. To deliver anything meaningful, teams depend on other teams. An example is dividing product development teams into classic front-end and back-end teams. This ensures no team can deliver meaningful things without the other, slowing everything down and leading to many alignment meetings. Another classic example is splitting it by platform (e.g., mobile team and desktop team), but with the same users using both platforms interchangeably (thus, with the same wants and needs).
Short-lived project teams. At some point in a startup's life, someone in power will be adamant that they had a great idea:
“Listen to me, this is good. Engineers are our most expensive resource. Let's make the most out of them by creating a pool of engineers, and then we staff projects based on their needs. This way, we can always allocate our valuable engineers to the most promising things.”
The idea could make sense if engineers were robots. In reality, every time a new team forms, the team must go through a “figure out how to work together” phase, which delays the start. If that is not enough, the company loses all the domain knowledge acquired by the team by dissolving it and placing it in a completely different set of challenges and code bases. Oh, talking about code base, how much do you think engineers will care about good code quality if they won't be responsible for touching the code again? The final nail is that this has all the same problems of “top-down feature mandates.”Overlapping or unclear ownership. When two people might own the same decision-making scope, it's a recipe for many hours of back-and-forth meetings, false starts, and 180-degree turns.
Unbalanced influence between UX, Product, and Engineering. The most common is engineering or product having more decision-making power over the product trio (engineering, UX, and product). The other two perspectives are lost.
What to do instead: This is a hard one. Organization structures are hard, highly contextual, and full of trade-offs. The general recommendation is to build long-lived teams that own the full scope (not shared) AND the resources to deliver everything they want without coordinating with other teams. Also, make sure that the engineering, UX, and product functions have equivalent “voices” inside the company and that no one of the functions “rules” over the other.
6. Hard to get good data
Qualitative and quantitative data are important, and product development teams need unhindered and direct access to them. However, it's often very hard to talk to customers (e.g., there are no reliable mechanisms to recruit and interview them), and/or quantitative data is incomplete or nonexistent.
The harder it is to have good data, the more likely teams are to use lots of resources for discovery (leading to the “discouraging discovery” problem) or make most decisions using gut feeling.
What to do instead: Have good product analytics in place, such as Mixpanel or Amplitude. Invest in making it reliable and complete. Also, there should be a simple way for product teams to speak directly to customers quickly. It's not rocket science.
7. Constantly prioritize the business over customers
A company needs profits, but so many companies turn into “milking the cash-cow dry” organizations, constantly screwing up customers in favor of earning that extra decimal point of revenue. The focus becomes on internal metrics, not on delighting customers. Depending on the type of business, this can last a long time (hello, dominant marketplaces!), but it will eventually lead to the company's demise.
What to do instead: At least balance long-term sustainable gains with predatory short-term gains. Hopefully, the company is in it for the long run, so there is no point in alienating its customers. As a leader, you have to be clear that customers come first (in ways that work for the business). Doing something “because you can get away with it” is a losing proposition and needs to be discouraged by the leadership—not rewarded.
8. Bad leaders
Unfortunately, many organizations suffer from poor leadership that lacks an understanding of product management principles, fails to foster a learning culture, or does not provide coaching, mentoring, or constructive feedback.
What to do instead: reward and recognize great leaders, not good politicians. Have clear standards and principles leaders need to abide by.
9. Company-wide, rigid and cumbersome processes
In the search for The Right Way© to develop products, companies start implementing all sorts of processes. Suddenly, the process becomes a religion, and to fix a bug, one must write a 6-pager PR FAQ. The most annoying of these religions I ever encountered was “Shape Up,” which, in my opinion, is a glorified “top-down feature mandate” mixed with “short-lived project teams.” Thankfully, I've never had to work with SAFe.
What to do instead: think that every time you implement a company-wide process, a panda dies. Is this process you want to implement across the org absolutely necessary? Could it be just a good case practice, and instead, leaving teams free to adopt it when they see value in it?
Closing thoughts
In conclusion, product management itself is not inherently difficult. The biggest challenges arise from the organizational environments and outdated practices many PMs navigate. By addressing these common issues, companies can make product management great again — and achieve awesome business results.
Please subscribe and smash the “like” button if you found this article useful. If you know anyone who could benefit from it, share it with them or on your social media. This is a big help!