The 5 Dark Arts of Product Management

What do you mean “not best practice”?

As a product manager, you will be judged on whether you make a meaningful impact to the business, which depends on building the right solutions to solve the right problems. You may be tempted to cut corners to achieve your goal, but need to understand the risks and long-term consequences of doing so.

In this article we will be discussing 5 ‘dark arts’ of product management, which we’ll define as risky or questionable techniques to achieve a worthy goal, as well as alternative ways to achieve the same goal. We’ll focus on practices that may be harmful overall but serve some benefit to your team, and are specific to product management i.e. not just general toxic workplace behaviours.

Yes yes, I know I’m mixing up my Harry Potter and Star Wars references

I’ve witnessed or used all of these techniques in the past. Mostly, they cause a lot of harm. Occasionally, they can be useful. Ultimately, you need to learn judgment in balancing short-term vs long-term benefits, or ends vs means. As that luxury watch quote goes, To break the rules you must first master them.

🕵️‍♂️ Deception

This technique involves telling people different versions of the same story, often saying something that you know isn’t actually true (i.e. lying). For example, you could tell a random stakeholder that you’ll work on their feature request next month, when you know it probably won’t happen.

This technique can be helpful for buying some breathing room for your team while you figure out some details. Telling people what they want to hear is a great way to get them to like you, or at least get them to do something for you. And tailoring our communication to different people is beneficial at a mild level — you shouldn’t communicate the same detail on a proposal to your CEO vs a customer vs an engineer.

It can go so wrong though. You have to keep track of exactly which stories you have told to which people so you don’t lose consistency. And if you constantly say things you don’t mean you’ll eventually get caught out and break trust, which is a death sentence for such a relational job role.

The alternative is harder, but sets you up much better for the long-term, and it’s to be honest with people even when it causes discomfort. In this example, you could simply tell the stakeholder that you won’t work on their feature request because it doesn’t fit in with the product strategy. There are of course better and worse ways to communicate truthfulness — talking respectfully, giving constructive feedback, offering alternatives, not making it personal — basically, try not to be an asshole about it. (My favourite book on communication is called Difficult Conversations by Bruce Patton, Sheila Heen, and Douglas Stone — check it out).

And if you receive strong negative pushback when telling the truth, try to remember that you are not your role, that people aren’t upset or angry at you in your innermost being/deepest childhood self — they are upset that a Product Manager has told them something that causes them difficulty at work. Being deceptive can lead to much worse reactions in the long term, because being lied to feels more personally hurtful than being told an uncomfortable truth.

🎲 Gaming your metrics

This technique involves picking and optimizing a short-term metric to win praise for yourself or your team (min-maxing for the geeks). It’s more common at larger companies, especially those which have bought into a framework like Objectives & Key Results, and are sufficiently data-mature to actually measure success.

A few examples here:

• If you are measured by input metrics like number of features delivered or tickets completed, you can split your projects into smaller and smaller increments to make it look like you are busier than you are.
• If you are measured by an output metric like checkout step conversion, you can optimize it by making another part of the process worse i.e. add a hard signup requirement or relax fraud requirements.

It’s key here that you don’t do or share more detailed data analysis that would disrupt the nice neat narrative you want to tell. Those around you will also want to hear about successes, because the alternative is harder and sounds like more work. This technique is helpful for making your team and yourself look good — after all nobody can argue with results, right? It may buy you more autonomy because you are seen to be performing. And sometimes it really does result in a short-term revenue increase for the company.

The consequences should be familiar to us all — products get worse over time. The user experience becomes bad, and internal tech debt and bureaucracy pile up. Cory Doctorow talks about this process as enshittification — here’s a quote from his Wired interview on the topic of platforms:

Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die. I call this enshittification, and it is a seemingly inevitable consequence arising from the combination of the ease of changing how a platform allocates value, combined with the nature of a “two sided market”, where a platform sits between buyers and sellers, hold each hostage to the other, raking off an ever-larger share of the value that passes between them.

It’s actually a hidden consequence of the overall positive shift to data-driven decisionmaking — that unless you’re careful the data will tell you what you want to hear. The alternative involves investing more time and effort in your data — pick thoughtful metrics (and counter-metrics), set up careful experiments, and report the results accurately. Drive a culture of healthy discussion about results, and don’t tie performance evaluations purely to project success metrics.

And sometimes, you need to acknowledge that some things cannot be easily measured but nevertheless have value. In the absence of (gamifiable) data, you’ll need to rely on fuzzier principles, like empathy, product vision or rational arguments (eww, I know it’s gross). For a fuller treatment on this topic, read Be good-argument-driven, not data-driven by Richard Marmorstein.

💣 Shipping a broken product

This involves deliberately shipping a product with known bugs or untested functionality. Sometimes it’s an edge case that could cause a crash, or even a button that doesn’t actually work which you hope nobody presses.

This is a tricky one because a core skill of product management is scoping features down into smaller increments, which means leaving out some requirements that aren’t essential. It’s part of the fixed time variable scope principle of Agile, which says that you should commit to whatever you can deliver within a timeframe, rather than committing to the full set of requirements and taking as long as you need to achieve it. You should be trying to ship small meaningful increments often so that you are getting feedback on whether you are building the right thing, which is often called the minimum viable product. The key word here is “viable”, i.e. it has to work.

The consequences for shipping broken stuff can be catastrophic and reflect really badly on you/your team. You could cause users to churn, an outage in production, or cripple the long-term adoption of the feature because you created a bad first impression. It’s a sickening feeling releasing a new feature and then watching the bug reports come in, and leads to a lot of stress for your engineers as they scramble to reverse the rollout or release a hotfix to prod.

The alternative of not releasing anything that isn’t perfect is a bit too strict, because velocity will slow down and projects will stretch out. Instead, you should strive for a balanced approach, with a few rules in place:

1. Define minimum release standards — write down a set of criteria for release and if your feature doesn’t meet all of them then halt rollout until you have fixed the problem. Some things to include here are: unit tests, integration tests, X days on a staging environment, security flaws, and bugs on the critical user journey. (You can ship with some cosmetic stuff not fixed, but make sure you know about the issues through testing first.)
2. Document the limitations — make sure all the potential failure cases are written down and communicated internally in advance, and share this with users if you can.
3. Communicate level of certainty on the feature i.e. private preview/public preview/general availability — this helps to align expectations on the quality of the software being released.

🗡️ Sabotage

Ah, this is a classic. Let’s say your team is responsible for a certain system within the company, e.g. the communications platform, and that occasionally you get requests from other teams to make a change to the system to support one of their projects. You can simply refuse all such outside requests so that your team doesn’t get distracted, no matter how important or beneficial the request would be. Bonus points for: poaching engineers from other teams, sowing distrust for other product managers and withholding key information that would be helpful to another team. I wish I could say it wasn’t like this, but organizations can be just like kids’ playgrounds, replete with tantrums, bullies and petty feuds. This pattern is more common in a company with a lot of autonomous teams and poor/disengaged leadership.

As with all these points, a low amount of this can be healthy. You need to fight to keep your team free from distractions, and you need to prioritize your own projects so you can actually achieve your goals. Not all feature requests are reasonable, especially if they come from a non-technical stakeholder where a simpler solution could suffice. Don’t try to avoid all conflict by saying yes to everything (see my previous piece 3 things to avoid saying as a PM).

However, if you take this approach to the extreme, two things could happen in the long-term:

• Silos — other teams learn not to ask you for anything, and everyone starts to develop their own workarounds rather than integrate with an existing system. Thus, standards and systems proliferate and the product becomes a confusing mess.
• Reciprocity — You might need that other team to make a change for you in the future, and if you’ve burned your bridges then good luck getting that feature shipped.

The alternative is to have a more grown-up conversation about tradeoffs and priorities across the company — it really helps if you have invested in relationships with other teams so you can bargain from a place of trust and mutual respect. If it is a recurring issue, then escalate to higher management and ask them to prioritize. Ultimately a lot of this cross-team conflict can be due to Conway’s Law, where the structure of the teams is not aligned to the projects you are delivering. In this case, the company should consider a reorganization to reduce dependencies.

🔥 Being a Hero

Being a hero involves stepping in to do tasks for other people, or going above and beyond the call of duty. You work longer hours than everyone else, you never say no to a request for help or support, you get involved in every possible meeting and initiative.

This may seem like a strange example to include — isn’t it a good thing to work hard? But my definition of a dart art involves gaining a short-term benefit at the expense of a person or a group of people. So who is harmed in each case?

• Deception: Everybody
• Gaming your metrics: The company
• Shipping a broken product: Users
• Sabotage: Other teams
• Being a hero: yourself

If you’re working continuously at maximum pace, you are setting yourself up for failure in the long-term, with three major consequences:

• Burnout — we’re not made to work flat-out without a break. Our ancestors were unparalleled endurance hunters, jogging after prey for many hours until the target would literally collapse from exhaustion. We weren’t the fastest kids on the savannah, but we knew how to set a steady, sustainable pace to achieve a goal.
• Reduced productivity — knowledge work is not shift work. More time doesn’t necessarily equal better results, in fact you may be doing more harm than good by staying at your desk. Studies of East Asian working cultures show that long working hours are correlated with low productivity. Ask yourself if you’re still doing your best work after 10+ hours at your desk, or if it can wait until the morning.
• Learned helplessness — the more you step in for others, the more you encourage them to ask you again in future and not learn to help themselves. Beware the saying “If you need something done, ask a busy person to do it”.

The alternative is to learn to say no, which is a useful signalling mechanism for other people to reflect and change their behavior. And if you have a lot on your plate, delegate tasks (graciously) to others, knowing that they might do work differently to how you would have done it. It’s hard — I believe as product managers we often have a natural inclination to take responsibility and get involved, but the better long-term strategy is to build up a team and a system capable of delivering results, rather than relying on your own heroic efforts. Plus, it’s more scalable.

So these are the dark arts of product management. Hopefully you’ve learned why they are useful, what can go wrong, and how you can achieve the same result through safer / more sustainable means. I’ll leave you with a quote from our boy Aristotle discussing the Golden Mean, where he argued that “the virtuous course of action is always the mean between two extremes of excess (too much) and deficiency (too little).”