These days, it is commonly accepted to refer to a Product Manager as a mini-CEO of the product. In that sense, you are responsible for all the failures and successes of the product, just like a CEO is held responsible for the failures and successes of their business. Sounds pretty straightforward and empowering until you do a reality check.
No matter how many times this mantra is repeated, you are not a CEO (unless you are, in which case you might be a founder/co-founder), not even close to being one. What’s unfortunate, however, is that this is not a popular topic of discussion in product managers circles; we don’t talk about it much, we don’t like to bring it up. Because as with shipping bad products, acknowledging and accepting that you have no real power to determine the outcome, lack of authority or the resources needed to make a product successful, can feel very diminishing and demotivating.
Instead, when we meet we prefer to encourage junior product managers with the standard pep talk, pass along lessons learned, discuss the latest tools of the trade, and scout new opportunities. You’ll never hear how we’ve been “tasked” with shipping a “turd”, which, in fact, happens more often than you’d think. This is where not being the CEO of the product and shipping bad products go hand in hand. Why you may ask? Because no matter what you need to ship it. There are always business reasons behind this decision you, as a Product Manager, will have difficulties to fight with: expectations of the analysts, the street, and board; pressure from customers; unreasonable founder, as not all the founders are reasonable; and so on. In the words of one the brightest and most products-focused engineers I’ve ever worked with, all you’re left with is “gotta ship this turd to the world.” Does not sound like a CEO, does it?
Since this is a guide to shipping a turd, to succeed in killing the magic of a product, follow the instructions below (or ask your management to help you do so). A survival kit is to follow in the next section.
- Do not begin with the end in mind. Use the HIPPO principle to decide on the product/feature to launch.
- Make sure requirements are vague, expectations are high, resources are minimal.
- Encourage your engineering teams to cut corners and make bad decisions. The more spaghetti code the better.
- Get as many cooks in the kitchen as possible. Make it a cross-team initiative but ensure no one wants to take ownership.
- Make sure the product needs to be built and shipped fast. Time deficiency is essential to avoid any resemblance of “success”.
- Do not let anyone challenge the status quo or question decisions made by the management. Complacency is key. Plant a seed of fear in people’s minds.
- Assign a designer to a project late. Or better, do not assign them at all and expect other team members to fill the gap and improvise.
- Request as many features as possible. Feasible, usable, and valuable are words that can not describe the final outcome.
In the end, you should end up with a solid turd that does not solve your users’ problems (most likely creating even more if you followed the instructions diligently) and burns out your team.
Now, let me turn the tables and try to offer you a survival kit, a playbook to use if you find yourself cornered. When there is no escape and nothing is negotiable do the following:
- Stay sane. Prepare for a lot of stress. Seriously, get ready. Start meditating before it’s too late, do yoga, HIIT, or long walks. Do whatever it takes to keep yourself and your team positive and focused.
- Take ownership when no one wants to. There are some aspects of the turd that can be claimed before it’s too late: user experience, a few user journeys, a scope, or, perhaps a couple of interactions that can improve the final product by 80%, hence a big win for you and your users.
- Be an underdog. Try your best to reduce the scope by negotiating, convincing, and expressing unpopular opinions and user perspectives. You need something usable and valuable even if it is very small.
- Prepare to fight… and lose. Mostly lose though. Make your wins count: they should be high in quality and not in quantity.
- Be the voice of the customer, defend the user, and always highlight the value they are getting. Do not sacrifice it for features someone else wants to ship.
- Make sure you have at least one brilliant engineer on the team: intelligent, product, and user-focused, with a high work ethic and deep pride in his or her work.
- Ensure your team accepts ownership but prepare to battle in the beginning. No one wants to own a turd.
- ”No matter how much you wash a turd, it will not come clean.” Accept your circumstances, but do your best. According to Buddhist philosophy, all our suffering comes from our resistance to seeing and accepting what is. Hence, accept but don’t give up; there is a silver lining.
- Support your team. You can’t have everyone going into rage or despair, someone needs to be strong. Be that person.
- Think ahead and try to mitigate future problems before they occur. QA the shit out of the turd, know the weak cases, manage expectations.
Building and shipping the turd is not going to be your career-defining moment. Most likely, it won’t be something you’ll speak proudly of at your next interview as the best product you’ve ever worked on, however, there is a lot to learn from this experience. It’s easy and gratifying to talk about successes, how much empathy and leadership skills we as Product Managers possess; our innate ability to influence people and build the best-in-class products; however it’s very difficult to acknowledge and accept failures, not to mention take ownership of and talk candidly about them. If you can manage to take ownership of the turd and still provide value to your users, owning a gold mine won’t ever be a problem for you.
