Sometimes you just know that your project could have been planned better. Like when Bloomberg calls it a $6 billion embarrassment. Or when you have to disinvite Angela Merkel, not to mention 10,000 other guests, from a launch ceremony because, well, there’s simply nothing to launch. Or when it’s making a laughing stock of an entire country. Known for its planning prowess, no less.
Just ask the people who’ve been in charge of building the Berlin Brandenburg Airport. They have quite a story to tell.
Once set out to welcome nearly 55 million passengers a year, “Europe’s most modern airport” took fifteen years to plan and another six to turn into a never-ending national fiasco. To date, the grand opening has been postponed six times (and counting) and the estimated project costs have exploded to €7.9 billion from the original budget of €5.4 billion.
What’s gone wrong, you ask? Some point to different stakeholders, including the government, the city mayor, the airlines, the passengers, the workers, the city residents, plus two other Berlin airports, all pushing different agendas. Others blame poor communication and hush-hushed glitches. And the ever-sprawling project scope sure hasn’t helped either.
Let’s face it: these are typical pitfalls of any development project, be it an international airport or a new mobile app. If there’s one thing we’ve learnt over the last nine years, it’s the importance of having someone on board on the client side who makes sure people don’t get their wires crossed. Literally or figuratively. Enters the agile product owner and saves the day. Let’s see how.
But who’s this mythical product owner, or PO, to begin with? In the Big Book of Agile, it’s the role where business meets development. A PO – or POs, depending on the project’s size and complexity – aligns business needs and stakeholder wants, facilitates decision-making and gathers information to make and keep delivery a success. Business savvy is their forte, closely followed by communication and project management skills. Ideally, they’re no strangers to design thinking and have a solid UX mindset, which serves them well in prioritizing backlog items to achieve the most while doing the least.
All in all, a PO in agile project management is the person who knows all the whats and whys from the business side of a development project – and matches them with the hows and whens on the delivery side. They supply, support and supervise, all the while keeping their eyes on the prize: product value, maximized. Do they know what formula to use or what code to write to bring results? No. Does it bother them? Not really. What they need to do is define and communicate what results they want and for what end, and make sure everyone understands and remembers them.
POs make the world go round
A seasoned product owner takes a load off the development team by sitting down with the right people and asking the right questions on their behalf for a better, smoother workflow.
So what happens if there’s no PO on the client side? Imagine the Berlin Brandenburg Airport but with software. Think stakeholders who go rogue and start coming up with ideas, concepts or features that serve no purpose whatsoever, except that they sound nice. Or they want the right features, but in the wrong order. Better yet, they have the right features in the right sequence, except no two stakeholders’ wishlists are ever the same. None of the above spells happy ending for a development team. More often than not, the only outcome of these scenarios is a money pit that wastes the client’s resources and everyone’s time.
Going into the development phase without a product owner can be especially risky for huge organizations. Thanks to bureaucracy, technology challenges and power struggles in these environments, the flow of business-critical information is still sluggish at best and paralyzing at worst. No wonder that fast and efficient decision-making is not something behemoth corporations are big on. In a recent project of ours, business demands, priorities and schedules changed so many times during the process that we ended up developing the same feature three times over.
How to deal with a no-PO situation?
If you’re a client: Get one. Or more. Find that self-starter in the team who’s well-organized, inquisitive and plays well with others, and give them the opportunity to shine. Remember: your ideal candidate is not necessarily someone who knows all the answers. It’s someone who knows all the questions, and who to ask them to. Another thing to bear in mind is that being a product owner, especially a good one, is no easy hat to wear. So make sure that your freshly-minted POs can focus all their attention and energy on their new role. Are they done learning the tricks of the trade? Let them teach all the ropes to the next generation of POs through coaching, mentoring and shadowing.
If you’re an agency: Don’t push the panic button just yet. For a while, you can assume the role of the product owner by facilitating the decision-making process yourself and educating your client along the way. Just a word of warning: this will only work if you have a deep, close working relationship with them, have already gained their trust and know all their expectations and needs inside out. Then again, remember that this is anything but a long-term solution. The more the product grows, the more complex and numerous the tasks around it will become. Meaning it will be one heck of a job to manage them. And as the product reaches maturity and becomes a hit in the market, it really is time for the client to step in. So make sure they’re ready.
The product manager in an agile Scrum team is a team of its own: a strategist, a mediator, a UX designer, a marketing analyst, a first point-of-contact, a liaison person, a project manager and a negotiator all at once. A proxy for all stakeholders, but also the key stakeholder of any development project. And it’s time we treated them that way.
So what do you think, how important is the Product Owner?