How can a Real-World Product Owner Escape the Build Trap?
- Danielle Downs
- Aug 22, 2022
- 15 min read
Updated: Jul 23, 2024
The labels “empowered” and “feature” teams have been bandied around the product community a lot in recent years. The former typically being associated with innovation and agility and the latter generally denigrated for valuing process over product and unquestioningly delivering against someone else’s roadmap.
If you find yourself in what Melissa Perri famously terms “The Build Trap”, developing feature after feature with seemingly little to no empowerment, what can you do about it, without having to leave your job or or change the culture of your entire organisation?
Firstly, I'll explore those labels, which I personally find somewhat unhelpful, then describe 10 practical steps a real-world Product Owner can take to escape the "Build Trap".
Contents
What is an “empowered” team?
The Agile XP and Scrum frameworks describe the Product Owner as the sole person accountable for setting and communicating the product goal and prioritising the team’s work.
The 2020 Scrum Guide says:
“For Product Owners to succeed, the entire organization must respect their decisions… The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”
The self-organising team, including the fully empowered Product Owner, agrees on a sprint goal that will contribute to the product goal and regularly release iterations of working software. They then use feedback and data from each iteration to inform and prioritise future product development (the Product Backlog).
Other stakeholders may attempt to influence the Product Owner but he or she is fully empowered to make all decisions about what to build and the development team are fully empowered to decide how to build it.
What’s a “feature” team?
I have heard this term used to describe a team that is either responsible for a specific component or feature within a larger product or, at its most extreme, one charged with churning out features, conveyor-belt style, with little knowledge of or input to the product strategy.
In both cases, the team’s work is generally defined by an overarching product roadmap with a planning horizon of 6–12 months. This is often predetermined by a more senior Product Manager, someone from the “C-Suite” (a “HIPPO” or Highest Paid Person’s Opinion), a committee of stakeholders, or even a few VIP customers; but rarely by the Product Owner. The PO may input to the creation and even ordering of roadmap items, but is not fully empowered to make independent product decisions or prioritisation calls at a macro level.
From what I’ve seen and heard over the past decade, this is fairly typical in (but not exclusive to) most medium to large enterprises.
As Roman Pichler rightly points out in his blog post, Six Types of Product Owners and video, The Role of the Product Owner, when a product scales, many organisations employ a vast array of “Product Owners”. Each one is responsible for a specific feature or component with varying degrees of autonomy but, for the main part, the roadmap (what to build) is determined elsewhere and the PO is fundamentally responsible for implementing it. Pichler describes these individuals as “Feature Owners” or “Component Owners”, which may be more accurate, but they usually have the job title Product Owner.
Despite what some Product Owners and Managers may tell you about how much power and influence they have in their organisations, I personally believe that truly empowered product teams are in reality quite rare.
Given the proportion of businesses with multiple Product Owners reporting to a Product Director, CPO,CIO, CTO or CEO, I find it highly unlikely that the majority of Product Owners are “empowered” to the extent evangelised by thought-leaders in the agile and product communities.
Furthermore, based on the increasing levels of derision I see levelled at “not fully empowered” Product Owners these days, it would hardly surprise me if people are indeed ashamed to admit to the reality of working in a product role anywhere other than in a start-up or on a greenfield product. I’ve seen so many articles on professional networks and forums, all with attention-grabbing headlines reinforcing the notion that, unless you’re the true “CEO of your product”, you have no business calling yourself a Product Owner and should instead have the title Project Manager, Business Analyst, Story Writer or even dare I say Barista (order taker).
It reminds me of the Instagram effect, where celebrities are portrayed as ever-smiling, beautiful and flawless; leaving susceptible teenagers with body dysmorphia, eating disorders and poor mental health. The more the utopia of autonomy is evangelised, the less comfortable regular Product Owners are speaking up about the empowerment challenges they face, resulting in a snowballing echo chamber of proclaimed perfection, where the vast majority are left feeling somehow less worthy and wondering if it’s just them. I’m sure this is a significant contributor in the well-documented epidemic of imposter syndrome within the product management community.
While this post was a work in progress, I stumbled across this article from April 2020, shared recently by someone in my LinkedIn network. It staggered me to think how many organisations overhauled their IT departments in pursuit of Spotify’s “empowered teams” model, where Product Managers are allegedly fully empowered “mini-CEOs”; while former Spotify employee Jeremiah Lee claims it was only ever partially implemented and even then failed to achieve its intended objectives as the organisation scaled! If this is true, it may have been the most influential propaganda coup in the history of Agile (although some may argue this title is still held by the creator of SAFe… but that’s a debate for another day).
A recent Product is Hard webinar by Marty Kagan also brought it home to me just how big a gap there is between the Agile product purists and the real-world Product Owner. In the webinar, Kagan joined some of the world’s most successful product leaders, such as Steve Jobs, Jeff Bezos and Steve Blank, in citing the reason many “good” product organisations “go bad” as being that the role of the PO role gets diluted and their expertise undervalued as enterprises scale, resulting in them becoming delivery managers, or “just another cog” in the production process. I do believe this to be true and sadly almost inevitable as organisations grow but, all too often, I find that the webinar, article or book focuses too much on the organisational problem and barely scratches the surface of finding a real solution.
The ‘expert advice’ I’ve heard from so-called thought-leaders ranges from the nebulous, “focus on adding value”, to the ridiculous “change the culture of your organisation”. Neither of which have ever resonated with me as practical or realistic.
Once caught in its grasp, it can feel like the only way out is to leave your current organisation and start afresh somewhere else, only to find yourself once again burned by the heat from the lightbulb you keep flying towards like a doomed moth in the night, convinced it will be different this time. Trust me, I’ve been there and know many others who have done the same.
How can a Real-World Product Owner Escape the Build Trap?
Step one: believe in yourself
l firmly believe that the change has to start from within. It might be a cliché but you first have to believe in yourself. Either stop reading all those articles on the internet about empowered product teams, or at least stop taking them to heart and start believing in your own experience and skills.
Step two: stop seeing yourself as the victim
Stop thinking of yourself as the passive recipient of product-related decisions. You probably have more influence, or more potential influence in your organisation than you realise but thinking you have no power will effectively ‘switch off’ your creativity, making it easier to think of reasons why other people’s ideas won’t work, than to come up with new ideas of your own. This will only force you yet deeper into the trap.
You may feel like the roadmap is being dictated “from above” by your CEO, CPO, Product Director, or some other HIPPO but, in reality, they are just stakeholders like all the others you have no doubt encountered and managed throughout your career. Realising this is probably the most crucial mindset shift you can make.
Stop thinking of them as your superiors and start interacting with them as you would any other stakeholder.
Step three: identify key decision makers
Think about those people that currently decide what goes on your product roadmap. Talk to them. Find out what their problems are. Most people are more than happy to talk at length about things that are worrying them. Listen to them. Take copious notes. Treat them like any other stakeholder.
Step four: go on a ‘scavenger hunt’
Gather as much ‘treasure’ as you can about your organisation, product, or the feature / component that you manage.
Speak to your customer service function.
Find out the answers to these 3 questions:
How satisfied are your customers with your product?
What’s your Net Promoter Score (NPS) or equivalent, if you have one?
What are your current customers’ pain points?
If you have a ticketing, case management or CRM system, find out if you can generate automated or on-demand reports of issues, bugs and feedback relating to the product or feature you manage. If this doesn’t exist in your organisation, ask why not and suggest it. Failing that, ask your customer service team to let you know if they receive any feedback or feature requests relating to your product or feature.
Once you’ve got this data, look for themes or quick-wins that could make a huge difference to how customers feel about your product. This irrefutable data will be a huge boon when coming up with and being asked to justify your priority recommendations.
Meet with your sales team
Ask them these questions:
What objections do they encounter when trying to sell your product?
What’s the one thing all prospects are asking for right now?
Do you have it?
Can you make it better?
What are your competitors offering that you don’t?
Where does your product sit within the market?
Talk to your Designers:
They may also feel stuck in a rut because “things have always been this way”. Ask them, hypothetically, if they had total free rein, what would they change about your product or feature and why?
Chat to your Lead Developers and Architects:
What technical constraints are holding them back?
What do they wish they’d done differently?
What new technologies are available that they think could be valuable?
It’s wrong to generalise but development teams don’t always have the skills or confidence to put a business case to senior management and it sometimes therefore falls to the Product Owner. Very few other people in your organisation are going to advocate for the repayment of “technical debt” but sometimes that’s what’s necessary to unlock the future product potential of the organisation, unpopular though it may be.
You may need to be the one to bring the ‘inconvenient truth’ to the attention of the Powers that Be; helping them see what everyone in IT may have thought obvious for months or years but been too afraid to mention. The key is doing it in terms they will understand. Most C-suite stakeholders' eyes will glaze over at the mention of technical debt but tell them how many developer days it will save and equate that to a monetary value and they'll suddenly be all ears.
Invite yourself to key meetings with current clients and prospects.
All too often, Product Owners don’t have access to real-life customers or users and this is a key factor in disempowerment. How can you add value and make prioritisation calls if you don’t know what your end-users and potential customers are thinking?
It is however probably one of the harder challenges to conquer, as it requires confidence and the right level of assertiveness, without coming across as pushy or overstepping. It might be a question of timing, or approaching the right person, but what have you got to lose by asking “Would it be ok if I come along to that workshop / session / meeting to get a bit more context about our clients / customers / users?”.
Your sales team or account manager may initially be apprehensive about letting a Product Person (gasp!) speak to their client, but some may appreciate having someone with in-depth product knowledge on hand to answer some of the more detailed questions about your product or roadmap.
If you find you get push-back, offer to stay quiet and just observe the first meeting. Even if you don’t get to interact directly with the customer (which is unlikely), you will absorb a lot of valuable insights just by being in the room (or on the Zoom call!). They will in turn get used to having you ‘ride along’ and your participation level will undoubtedly increase over time, as your confidence and their trust in you grow.
Just be mindful of stepping on any “landmines”, such as contradicting the salesperson if they do voice any inaccuracies about your product. I have (in the past!) known salespeople not to let reality get in the way of a good sales pitch, but correcting them in front of a prospect could be damaging to both your relationship with Sales team and their chances of closing the deal! Do however take them aside after the meeting and gently ask them why they said what they did. There may be an opportunity to resolve some unspeakable flaw with your product, or they may genuinely lack knowledge. Either way, it will foster better alignment between Product and Sales, ultimately resulting in a better product and more appropriate expectation setting, leading to a more satisfied customer overall.
Step five: do a brain dump
Put all the findings from your “treasure hunt” on a page (or Miro board!) and do some good old fashioned cause and effect analysis.
As enterprises grow, they typically become siloed and one business unit might not know or truly understand what’s going on elsewhere. Join the dots for them. Think about your organisation as a whole, not just ‘your’ product area.
What’s stopping it from being really great?
What’s stopping you becoming the market leader in your field?
If you're already the market leader, how can you be sure to retain your market share?
What could be the next disruptor that kicks you out of the game? What could be the Netflix to your Blockbuster?
Draw a fishbone diagram, do some SWOT analysis, whatever it takes to get you to a point where you know what should be the top priority on your product backlog and why.
Step six: make it visual and keep it simple
Boil all the above down into a few key slides that really illustrate the current situation for your product and organisation. Generally speaking, I’ve found that the higher up the organisational ladder somebody is, the more they value pictures over words and detail.
The ‘C-suite’ may not be from an Agile product management or development background so avoid jargon (especially the term “technical debt”!) at all costs. Don’t ‘preach’ agile principles. Stick to language they understand: profit, loss, time to market, the competitive landscape, what can happen if you don’t do ‘xyz’, but make sure you have the more detailed facts and figures to hand to back up your assertions if asked.
Step seven: share your thoughts with your boss first
They won’t thank you if you go over their head without speaking to them first and may have some useful insights and feedback, but don’t be discouraged if they appear dismissive at first. The chances are they’ve tried do to the same thing in the past, but don’t let that put you off. A lack of confidence at this juncture may be why they didn’t succeed where you’re going to.
Step eight: meet with the key decision makers
Schedule 45 minutes to an hour to present your findings to the key decision makers identified in step 3. If you don’t feel comfortable going straight to the ‘C-suite’, start with some middle managers and try to gain some allies, who may be able to get you time with the higher echelons, or at least influence them with your ideas instead of only their own.
Use short sentences and repeat memorable “sound bites” that your audience will find themselves repeating to others.
Think about politicians and advertisements you’ve seen on TV. What do you remember and why? “Stay home, save lives, protect the NHS!”, “Washing machines live longer with Calgon.”, “Bang and the dirt is gone!”, “Points make prizes!”. Remember to use ‘business’ language e.g. “X will increase conversion”, “Y will increase our profit margin”, “Z will make our product more scalable”.
At the start of my career, I used to be enraged by managers taking credit for my work but I now see it as the most sincere form of flattery. If you don’t like the idea of pulling the strings from “behind the scenes” and want exposure, you can always send your slides round to a wider group, including the more senior stakeholders, after the meeting “for info” (or for those that couldn’t make it), ensuring everyone knows where the ideas really originated, without making you look like a ‘smart ass’.
During the meeting itself, don’t get dragged down a rabbit hole and spend too long debating any one point. Say it’s very important and worthy of further discussion but politely ask to come back to it later, or offer to arrange a separate session on the topic, because you have a lot to cover today. Most importantly, speak with confidence and authority. Remember your experience and all the research you put into your presentation. Use data and facts to back up your arguments. Put references and sources in your notes so you can easily cite them if asked.
Step nine: allow your seeds to germinate
Some of your findings may have been a surprise to some of the audience, or they may have been taken aback by your candour and confidence. Tell them they don’t need to make snap decisions today but that you’d like to regroup in a week or so to discuss the ideas further.
Step ten: ask for feedback
Speak to the people to whom you presented your findings individually and informally. Just ask them what they thought. Identify your “allies”, who broadly agree with your thinking vs. those that may require more convincing. Understand what their no-go areas are and be prepared to compromise, or to delay a decision until the “last responsible moment” to avoid a conflict now. A lot can change in a few weeks or months, so there may not be value in pushing something that could change or ‘come out in the wash’ later. It sounds like a cliché but pick your battles — only risk contention when you feel it is absolutely necessary to avoid making or repeating a costly mistake that cannot be rectified later.
You may find that drawing a stakeholder matrix (see below) or a "battle map" (also known as an Influence Diagram!) helps. This video on Battle Maps from Geoff Watts is really useful.
These 10 steps should put you well on the way to having greater influence in your organisation. If nobody appears to be listening, don’t give up. Speak to your “allies” and find out why your ideas aren’t being well-received.
It could be that there are other business priorities right now, in which case you will unfortunately just have to bide your time, but it could also be that the Board are awaiting budgetary approval before considering new product ideas, so you’ll know when to pitch your recommendations again. Alternatively, there might be political sensitivities that you weren’t aware of, which need to be overcome. This may require you to tweak your proposal to make it more palatable, or spend more time with certain key stakeholders, to help them see things from your point of view.
So many people over the years have told me to “make x think xxx is their idea”. This has always grated with me because I find it disingenuous and manipulative but they just see it as using their emotional intelligence! I’m still on the fence about that but I do find that starting a discussion and providing objective material and data for thought goes a long way to getting people round to your way of thinking, without needing to resort to mind games.
It might take time but persistence may eventually pay off. You don’t want to be the one sitting back when someone else happens to swoop in at the ‘right time’ because you’d already given up. This happened to me a few times early on in my career and I got overlooked for promotion twice because I was either afraid to speak my mind, or didn’t sufficiently “socialise” my ideas with the right stakeholders; stubbornly believing I should have full control over my own roadmap, without having to consult with or influence anyone else (perhaps I’d read too many of those purist articles!), while others were prepared to swallow their egos and put in the groundwork.
If it goes well, in 3–6 months, you could be influencing other stakeholders and starting to gradually take ownership of the roadmap, delivering value in iterations instead of predefined features and using feedback to inform future development.
Over time, you may be able to ‘shrink’ your product backlog from 6–12 months to 3–6 months and perhaps only define the next 1–3 months in detail; retaining the flexibility to adapt the content of each sprint as you gather data and feedback.
Conclusion
Unless you work for a start-up or on a greenfield product, the chances are there will always be people ‘above’ you that have an influence on your product strategy and roadmap. The key is to not let them define the boundaries of your role, or you will dig yourself and your organisation ever deeper into the infamous “build trap”.
Keep in mind that senior stakeholders and "HIPPOs" are no different from other stakeholders, with whom you might consult when developing and prioritising your roadmap. Being influenced by other stakeholders doesn't make you a more junior or less empowered Product Owner. Conversely, it makes you a better informed, more empathetic and ultimately therefore more empowered Product Owner or Product Manager.
By working with those perceived as senior to you in the hierarchy, instead of having an "us" and "them" outlook, you can claim yourself a seat at the metaphorical table and begin to influence the product strategy and roadmap from the top down, rather than constantly trying to "push up", which can be both exhausting and demoralising.
Contrary to the apparent opinion of many purist thought-leaders (and propaganda!) out there on the internet, the change doesn’t have to happen at an organisational level. It is possible to change it from within, starting first and foremost with your own mindset.
Commentaires