Ask forgiveness, not permission
Anyone who’s worked with me as a product manager has probably heard me say at one point or another that it’s better to ask forgiveness than permission. While that makes for a cliché, easily quotable philosophy, there are important nuances that I want to talk about, since it’s not something that should be applied in every situation without careful consideration.
I recently finished Marty Cagan & Chris Jones’ book Empowered, and a particular quote near the end of the book stood out to me (emphasis mine):
Up to that point, very few of the senior stakeholders had had much (or any) visibility of the work. It was a decision I’d taken deliberately, though not lightly, early on. I’d secured agreement with my technology director and with [editor-in-chief Alan Rusbridger], that in order to take advantage of this opportunity, I would need to move unusually quickly. I would have to seek apology later.
This is a quote from Jon Moore, referring to the rapid development of an iPad app for The Guardian, and it made me realize that I’d left out a critical piece of guidance when asking forgiveness.
“Ask forgiveness” doesn’t absolve you from doing your homework
The product manager is often referred to as “the CEO of their product.” But even CEOs don’t make decisions in a vacuum. They listen to the feedback of their executive team, and they defer to the wisdom of the board of directors. They consider the impact to the business and the customers. The best leaders are decisive, but they do not make decisions without first weighing options and collaborating with their teams.
“Ask forgiveness” is mostly a tool for circumventing bureaucracy when you have a high integrity commitment. Especially in large organizations, getting approvals to move forward on a project can be laboriously slow for a variety of reasons. Sometimes you only have a short amount of time to deliver, and deliberation and approvals would be meaningless since the deadline will have passed before you come to consensus with your stakeholders.
Make sure that before you employ this tool, that you know exactly why you need to do it. Sometimes you may get away with it unscathed, but at some point it will cost you social capital in your organization (and possibly your job), whether the product initiative succeeds or not. The value needs to be there, and the agility has to be absolutely necessary to getting to market, otherwise it’s not worth it to circumvent typical business processes.
In Moore’s example above, his team had only a few weeks to deliver an iPad app that would be shown at an Apple presser, and it had tremendous potential value to the business because of the visibility it would create. He made a very calculated decision to move forward without approval because the pressure was there and the benefit measurable.
Pictured: me asking forgiveness after the business value rolls in.
A few things to consider
Before moving forward in an “ask forgiveness” scenario, here are some things you should do.
Never, ever use this as an execuse to bypass discovery. You will have no idea whether or not there is a payoff to asking forgiveness unless you know the stakes and if it’s even feasible. Maybe there’s not enough time even if you bypass approvals. Maybe you’ll find out it’s not feasible to build it anyways. Maybe you’ll discover the value you thought was there is not as great as it first appeared. In any case, always do your homework. This is a tool to go fast, but going too fast will lead to disaster.
Consult with your product leader. Never surprise the person you report to. This is a great topic for a one-on-one where you can go over all the reasons why you want to move forward and what you see as the payoff, as well as to solicit advice on whether the move is warranted. You never want to surprise the person who is most directly responsible for your future at the business. This also gives them the chance to do the same with their boss, and so on, so when you go to ask forgiveness later, everyone will potentially be warmed up to the idea already.
Include your team. Most specifically your tech lead and product designer partners know what’s at stake and why you want to do this. You’re ultimately accountable, but you’re putting the entire team’s reputation on the line.
Be prepared to defend your decision. Don’t forget that the “ask forgiveness” part of the equation will come up at some point. Make sure you have your data and your talking points ready to go when someone asks why you did what you did. This is another reason not to skip discovery.
Prepare a demo before go-to-market. It may seem counterintuitive, but the time to show your hand is right before you launch. Once the product is ready to go, make sure to demonstrate it to those that have the power to tell you “no.” Make it clear that you plan to launch immediately, but give them the opportunity to stop you before it goes live. Again, this is in the philosophy of not surprising the important people in your organization. Chances are, though, that once it’s already built and ready to go, and you’ve prepared your defense of your decision to move forward without seeking approval before the work started, they’d rather see what happens in the market than cancel it.
Don’t overuse this technique. Getting a reputation as a maverick may sound cool, but you will at some point undermine trust with your own leadership and stakeholders.
Quick book recommendation
Since I mentioned it as the genesis for my idea on this post, I suppose I would be remiss if I didn’t recommend Empowered (non-affiliate link) if you’d like to learn more. This book and its companion Inspired have been key in motivating me to rethink my model of modern product management in the tech space.