Dear PM, Oga-driven development isn’t your CEOs’ fault … it’s yours

This is an open letter to PMs, specifically early-stage ones. Because I’m hoping that no senior PMs act like this.

This article will be a rant, a reproach and a resolution, all in one. So buckle up because while I’m going to try my best to be kind, there are some harsh realities that I need you to hear.

Please know that what I’m about to say is said not out of a feeling of superiority or hatred, but out of pure frustration because I know some of you are amazing and I’m tired of hearing some things in PM circles.

So here goes …

Dear Product Managers, you guys need to step your game all the way up.

Over the years, I’ve had the honour of meeting, interviewing and hiring PMs. I’ve also had the opportunity to mentor PMs. And one of the most frustrating things I hear from PMs is when they complain about what is affectionately called Oga/CEO Driven Development.

But first ….What is Oga Driven development?

Oga-driven development … or CEO-driven development is when a product team is “forced” to build something just because the HIPPO (most often the CEO) thinks it’s the best thing since sliced bread. They see a new feature on a competitor's website or (even worse) dream up a new idea in the middle of the night and the next day come to you trying to explain why doing this is going to “CHANGE THE GAME”.

They then use their power and influence to rally the entire company into building it, even when the PM (and probably everyone else in the company) thinks it’s a bad idea. Either because not a single customer has ever asked for it, or because you have existing priorities that are more urgent or you can’t figure out a way to monetize it to profitability or the fact there are more important bugs to solve or features to build (that customers are actually asking for).

No matter what the reason, you’re not convinced that you should build a feature that your CEO is asking for, but you build it anyway.

Without question…

Without challenge…

Because your boss said so….

And then when the product/feature fails you cross your arms and say (sometimes even in interviews) that it’s not your fault, you were doing your job.

But I’m here to tell you in no uncertain terms that your excuses are boring and it is your fault. Saying the only reason you built a product was because you were told to is the laziest, dumbest response from a PM that I can think of.

Because the cold hard truth is ….

Every bad feature is the fault of the PM who built it

One of the biggest misconceptions about the role of PMs is that a PMs job is to write user stories and create JIRA tickets.

It is not.

The average 10 year old with a solid grasp of language and a good framework can learn to write user stories and JIRA tickets in less than a week.

This is why training schools are churning out product management certificates but their graduates can’t get a job as a PM*. It’s because they sell being a PM as this easy way to get into tech: they sell this dream of a glamorous job, a high salary, churning out features and being a mini-CEO.

But being a PM is so much more than document creation and supervising engineers and designers. Being a PM means that you get to use every skill at your disposal to build features that customers love so much they are willing to pay for them. It’s your job to make sure that your team is building the most important thing in the best way possible.

Your job isn’t to deliver features. Your job is to deliver value. And if your team is not doing that, then you have failed. Period.

I’m not saying that every product/feature has to be a success, far from it. You should actually have tons of failed experiments.

What I am saying is that you should not be building things on the strength of “someone said so” no matter who that person is. Your job as a PM is to be a customer advocate and a fighter. You battle design to balance aesthetics over functionality, battle engineering to balance building new features vs fixing technical debt, tussle with legal and compliance over … (let me not get myself in trouble)… you’ll battle with marketing over how the story should be told, you’ll battle operations to build out processes, you’ll battle finance to figure out pricing. And at some point in your career (if you’re any good at your job) you’ll battle C-suite executives over more things than you care to admit.

And that is one part of the work the boot camps don’t train you for. No one tells you that you’ll be in the room with people who out-earn you in multiples and you somehow have to convince them that your ideas are valid. Or how you will have to speak to someone who has over a decade of experience on you and explain the flaws in their logic. Or the part where you have to look at the person who pays your salary in the eyes and respectfully decline something they are genuinely excited about.

No one tells you just how freaking brave you have to be to be a good PM.

And the worst part of it all is that that kind of bravery has to be learned. No one is born with it. It has to be carefully encouraged and nurtured. And I’ve never seen a training course or boot camp that even mentions this, much less teaches it.

And that’s the only reason I’ll say it’s not your fault that you’re unable to challenge your CEO. It’s hard to be that defiant in an organization where you don’t have psychological safety. Where you can lose your job for saying the wrong thing. Or if you’ve lived a life where you learned that defiance gets you nothing but a swift and thorough flogging. How do you challenge authority when no one has shown you how?

Well don’t worry I gotchu. Remember when I said this post is going to be a rant, a reproach and a resolution? Well here’s the reproach part.

Here’s why you fail to challenge CEOs

In all my conversations with PMs about this there are three main reasons that they don’t challenge “the boss”. They may not say any of these explicitly, but one or more of these reasons can be inferred from the conversation. Also, this isn’t an exhaustive list, it just highlights the most common things that I hear from PMs on this matter. So if you have a reason I haven’t covered please let me know in the comments.

That said here are three reasons that you are suffering from Oga-driven development

Reason 1: (You think) you don’t have the authority to clap back

This is an extremely difficult one to crack because it flies in the face of everything most of us have ever learned. Especially if you grew up in a country like Nigeria where authority is rarely challenged. You’ve been trained by your boss, teachers and parents to “respect your elders”. For decades you have been told you don’t have the authority to argue with anyone senior to you.

But I’m here to tell you that you absolutely do have that authority because it is literally in your Job Description. If you don’t believe me … please take a moment to go read the JD of a CEO vs the JD of a PM. I’ll wait …

…

…

All done? … not yet? Don’t worry, I’m patient. Please take your time…

…

Na wah oh … I’m not that patient. Come back …It have do … .

Thank you.

Did you see anywhere in the JD of a CEO the responsibility of building features or products? No? Because it’s not their job. It’s yours. Unfortunately, most CEOs were the first PMs of the company and they struggle to let go of that responsibility because it’s the one they enjoy the most.

That sucks, but if they wanted to keep that job they shouldn’t have hired you. So you have to force them to hand over the reins in the only way that you can. By being so much better at it than them they have no choice. And before you think it can’t be done let me tell you that every other discipline does it. Finance, Legal, Operations, Support, Design, Marketing … everyone has a specialized skill that they flex. And Product Managers need to do the same. And that’s where problem number two comes in.

Reason 2: You don’t have the Depth

Where the first problem is emotional, this is a knowledge problem, and that makes it the easiest one to fix. But somehow, it still shows up time and time again, because people misunderstand the role of a product manager.

I’ve spoken to too many product managers who don’t even understand the product that they are supposed to be owning. They let the burden of knowledge and decision-making rest with other people, leaving technical conversations to engineering, pricing information to finance, UX decisions to design and support mechanisms to the support team. And I can’t lie … I’ve been guilty of this as well, because the work is much. But please know that, when you do this, you turn yourself into a Project Manager. And while that is a great job … it’s not your job.

Also to be fully clear, I’m not saying that you should be doing all these things yourself, far from it. That’s actually another reason why PMs fail*.

Good product managers have a mechanism for understanding each of these areas in depth and are able to demonstrate they can make informed decisions in every area of the product.

This is what many people call having “product sense”. It’s that deep understanding of everything to do with your product that forces domain experts to defer to you. And if you don’t have this, you’ll fail to develop the trust you need for people in authority to let you make decisions.

Said another way, if your CEO understands the customer, the financials, the tech or the landscape of your product better than you, then you’ll never be able to argue with them. Being a PM is a high-trust job, and if they can’t trust you to understand the basics, they’ll never trust your judgement when it comes to decision-making.

So if you want to be able to have winning conversations with your CEO, where they won’t overrule everything you say and position yourself in a wat that they trust you with actual real and impactful product decisions, you have to know your stuff inside out.

Every time I’ve had to capitulate to a CEO about my product, it’s because they’ve operated in a capacity better than me. Which is fine, but that’s on me not them. And the times when I’ve successfully had them come over to my way of thinking; it has been because of a combination of being brave enough to challenge authority, establishing trust by having deep knowledge of my product and the final piece we haven’t talked about yet.

Making a convincing argument.

And this is the third reason you are experiencing Oga-driven development.

Reason 3: You don’t have the skill to convince anyone of anything

So you want to challenge your CEO. You have the knowledge and courage on your side. How do you actually convince this powerful dynamic human who has authority brought on by owning the company and the ability to fire you on their side?

You can’t just say “Oga I’m not doing this”. That would be … well, let's just call it unwise.

So if you can’t just say it outright … what do you do instead? Well you do what you were (supposed to be) trained to do. You lead by influence. If you want to spot a good product manager, find someone who understands how people work and is able to apply that knowledge in day to day life. Being a PM is all about changing human behaviour, so if you can’t figure out how to get your CEO to understand your point of view, how are you going to do it for your customers? This is the primary reason I think that soft skills are more important than “hard” skills for PMs*.

And while I can (and someday will) write an entire article about why as a PM you need to study and understand human behaviour* it’s time for me to put my money (or in this case my words) where my mouth is. I promised you a rant, a reproach and a resolution. So here’s the resolution part of the article.

Here’s what to do when you need to convince your Oga that no… we don’t in fact need to build that feature

Let me start by saying that this isn’t a fool proof method. It’s simply the mental model I use when I’m in this scenario and to be honest it has about a 50/50 chance of success. Some people just have very strong instincts and opinions. And I can’t lie, I am people, so these tactics may not even always work on me that is writing them. But they have worked for me enough times over the course of my career that I think they’re worth sharing;

• First: Understand their motivations for wanting this product/feature, Ask them why it’s important, what KPIs or metrics it will impact. How it will move the business forward? Why it’s important to build it right now. Your goal is to figure out what they are seeing (or feeling) that you aren’t. They may be operating on knowledge that you aren’t privy to. Try to get them to share that knowledge with you and it will help you make a better decision on whether or not you should build the thing. A lot of times if you can get them to clearly articulate their why … you’ll actually be convinced and the question isn’t whether or not you should build it, it’s when and how you should build it.
• Second: Give them options: Sometimes your answer isn’t actually no, it’s not yet or not like that. And there are lots of ways that you can help get to a better answer for both you and your CEO, because after all, you both (should) want the same things. And this is your opportunity to shine as a PM. You can run an experiment, survey customers, build an MVP. Your primary goal is to SHOW FLEXIBILITY. You’re not rejecting them or their idea, you’re collaborating with them to bring the most valuable version of it to market at a time that makes sense for the business and the team. But if you really don’t want to do any of that then you can also…
• Show them something they haven’t seen: One good way to get someone to reconsider their stance is to show them information that they may not know. Similar to how step one was having the CEO show you what you don’t know, this is your opportunity to show them what they don’t. And while many people interpret that to mean show them “data”, it doesn’t have to be. While data is incredibly helpful for making compelling arguments it’s not always available and there are often other things that are guiding your decision making that are equally valuable. Things like your existing backlog and priorities, the lack of customer demand, the differences in markets, the legal or financial implications, and sometimes it can be as simple as the impact on team morale from constantly not being able to finish anything that can change the tide. If you’re really grounded as a PM you should be able to clearly articulate why you don’t think now is a good time to build what your Oga is asking for. And just like “they said so” isn’t a good enough excuse for you to build something, “I don’t want to” isn’t a good enough reason to push back on what you’re being asked to build.

Ok so you tried all that … and you’re still being bullied to build this thing because a spirit from the heavens told your Oga that this is what is going to CHANGE THE GAME!!!

Omo this your Oga has strong head sha, but here’s what you can do when you’re faced with building something you don’t believe in. And it’s really quite simple.

You force yourself to believe in it.

Now calm down. Before you say “Temi isn’t that just Oga driven development, the very thing you told us NOT to do” let me say what I have to say. Because I promise you it’s not.

Think about the first suggestion I gave you. If you’ve done it right, then you should have a suite of reasons to build this thing. All you have to do is double down on each of those reasons and prove or disprove them. If your Oga says you need to build this feature because a key customer is asking for it, go talk to them. If it’s because there’s regulatory pressure, go read the legislation. If they are saying it will bring in revenue … test it with an experiment. AND SHARE YOUR WORK.

This process isn’t a straight line. It a scrambled wiggly and sometimes broken dance that hopefully builds a better working relationship with your CEO. But the burden of that work is on you. And if you can’t make figure out how to find a place of mutual respect between you and your Oga then perhaps you should have a conversation with yourself (and possibly the Oga in question) on whether Product Management in that organisation is right for you.

Because if you build a shitty product, it is, in fact, your fault.

*A note about this star: I use a star to indicate a topic I’m going to write about in the future.

Here’s a list of every * in this article (aka some of my upcoming articles)

• Why you’re struggling to get a job as an entry-level PM — How your product bootcamp has failed you
• Dear PM, please stop doing X … it’s not your job and it’s making you a bad PM
• Why “soft” skills are more important than “hard” skills for PMs
• Why Psychology is so important for PMs

So if you want to know when any of these drop, then …

CLICK HERE TO SUBSCRIBE.

Not only will you be notified whenever I drop a new article, but you’ll inspire me to write them even faster 😎