What You Should Know Before Becoming a Product Owner in a Large Corporation
Five tough challenges you may run into while wearing the Product Owner hat in massive enterprises
Five tough challenges you may run into while wearing the Product Owner hat in massive enterprises
Thousands of companies are looking for people to fill their Product Owners’ positions. By doing a quick search on LinkedIn, I’ve found more than thirty thousand ads in Europe and around a hundred thousand in the USA. However, do all these companies have a shared view of the Product Owner role? What do you think?
The expectations for the Product Owner role vary dramatically from company to company. The scenarios and constraints define what a Product Owner for the organization is. And as a candidate, how do you know what to expect from each company? Well, in truth, you can’t really know until you land the job.
I’ve already been in many different scenarios. For around five years, I’ve worked at a company with more than fifty thousand employees, and I learned a lot about the particularities of the corporate world; let me share them with you. By the end of this post, you should have an idea of what awaits you in the corporate world as a Product Owner.
#1 — Following a Plan is What Matters
My first job as a Product Owner was in a large organization. I had no idea what I should do to deliver value. I thought that my job was to focus on the execution while the executives would decide which direction to take. And that’s how I worked for years; following in orders.
When I first heard the word roadmap, I didn’t know what that was all about. In our scenario, as a Product Owner, I had little to say about it. Mainly I focused on figuring out whether we could manage the chosen features in a quarter of a year while executives discussed which features would make the cut. Our roadmaps were highly prescriptive.
We precisely knew what to do, but not why that mattered.
Something annoyed me a lot. We often realized that a particular feature made no sense, but we had to implement it anyway because the executives wanted to. Customers didn’t connect to certain executives’ wishes. Yet, following the plan was all that mattered.
Sprint by Sprint, we shipped features. Unfortunately, we barely knew whether they were valuable or not because we had to keep our feature factory at full speed. The Scrum Teams were powerless to inspect and adapt. The execution was our full-time job.
#2 — A World of Dependencies
Once I had the chance to be a software developer in a small team, I felt we were progressing at a fast pace. When I talked to users and identified low-hanging fruits, I could adapt the code, test, and deploy the change in the live environment. Sometimes I did that many times a day, and users were grateful. But the corporate world is often slower than that.
I’ve observed only a few teams in large corporations that could work from end to end without dependencies. Most of the teams I’ve seen are component teams, and that makes everything super slow. Let me walk through a real example from the e-commerce world.
We were a private shop business with millions of recurring customers, and we had an opportunity to allow voucher providers to sell on our platform. Initially, I thought it would be a simple thing to do. I wish I were right. We had nine teams, and each team was responsible for specific components. Long story short, allowing our first partner to sell on our platform took us four months because of dependencies with multiple teams (shop, cart, check-out, back-end services, and marketplace).
The implementation itself was trivial, but dealing with dependencies was an exhaustive experience.
I don’t want to be unfair; not all large companies work with component teams, but I’ve seen only a few using different strategies. Dependencies hold teams back from progressing, and ultimately businesses miss countless opportunities.
#3 — Analysis Paralysis
Another aspect in large corporations disturbs me a lot: the time wasted analyzing ideas. It’s common to invest weeks analyzing something before trying it out. The discussions become pretty abstract and speculative, and yet no action is taken because certainty is absent.
“Nothing will ever be attempted if all possible objections must first be overcome” — Samuel Johnson
In Product Management, uncertainty is the only certainty we have. Yet, it’s up to us to be creative to deal with that. From my experience, investing too much time into analysis is a waste, and it ensures we don’t progress but get stuck. For me, doing Scrum is an excellent way of dealing with uncertainty. You set a Sprint Goal and work towards it. At the end of the Sprint, you will learn something, then you inspect and adapt.
Progress is made out of learning. We can only get closer to our goals once we move one step at a time. Yet, that’s often not the case in most large corporations. First, you’ve got to prove your idea is worth a shot, and for that, you better have a detailed plan and thorough analysis. I find it counterproductive to invest time into that detailed upfront analysis; it’s better to identify our assumptions and find alternatives for validating them.
“The truth is that no business plan survives a collision with a real customer. So the trick is to take your idea and set it on a collision course with reality as soon as possible.”
― Marc Randolph
#4 — Managing Stakeholders Can Be a Political Game
I dislike the word stakeholder because it’s an umbrella term for anyone involved or impacted by a product or service. Yet, in the corporate world, business stakeholders will consume a lot of your attention and nerves as a Product Owner.
Managing stakeholders is challenging. This is especially true with large corporations. You can expect pressure from all layers of the organization; everyone wants something from your team by yesterday. You may dare ignore influential stakeholders, but your boss or the boss of your boss will get an e-mail, and eventually, you will need to please your stakeholders instead of focusing on the end-users.
Not all companies have clarity on prioritization criteria. Sometimes, the one shouting the loudest gets all, or the highest-paid person in the room defines what to do. To succeed as a Product Owner in such situations, you’ve got to find common ground with your business stakeholders and establish a partnership instead of a service provider relationship.
Don’t be a stakeholder pleaser. Be a value maximizer.
#5 — You Can Be Trapped in Uncountable Meetings
Be careful with how you handle your schedule; whenever people find a free slot, they may try to place a meeting. I cannot recall the number of meetings I’ve been invited to discuss an important topic, and unfortunately, accepting them distracted me from my commitments.
The larger the company, the easier you can get distracted. Long ago, when I was a business analyst, I lived in meeting rooms. I had a minimum of six hours of meetings per day. I used to say I was a meeting analyst because I had no time to do accurate business analysis. I let all the important topics distract me because I was terrible at saying no to distractions.
You should master the art of saying no in the corporate world, even though you may piss some people off. Until you can focus on what matters, you cannot live up to your responsibilities. Blocking all the noise coming to you is challenging and yet vital to succeed in your role.
Final Thoughts
I find it particularly hard to be a Product Owner in giant corporations. Honestly, in such scenarios, I could barely live up to my responsibilities. Most of the time, I was a Backlog Owner who focused solely on the execution. I led several teams in implementing solutions, yet we often didn’t know the problem we were solving.
The corporate world can be challenging for Product Owners as political aspects and dependencies may get in your way. Still, I cannot be unfair and claim all places are like that. If you want to be a Product Owner in a giant corporation and live up to your responsibilities as close as possible, you should search for the following traits:
Product teams: the teams are empowered to solve a problem from end to end. They don’t have to deal with dependencies as they are fully self-managing.
Objective Key Results: roadmaps focus on goals to pursue instead of features to deliver. Generally, OKR is the roadmap format.
Discovery process: the company focus on validating assumptions instead of investing a long time in analysis.
