Working with Superheroes: My Experience as Product Owner at Interbank
It was 9 PM and my cell phone started ringing. Jorge Higa, the Product Owner of Interbank.pe, was calling me. Without a doubt, it was strange to receive a work call at such late hours, but I answered immediately to attend to what could be a possible emergency. And boy was it: Jorge explained that after 9 successful years at Interbank, he’d decided to move to another company in search of new opportunities. At the same time, he told me he was recommending my profile to take his place.
With only a year and some months at Interbank, I decided to take on the challenge because I was eager to learn something new and because somehow I had been preparing for this moment over the last 10 years (without knowing it). The same instant I accepted the offer I wasn’t completely sure what I was doing, but my conviction about what this step meant for my career and the trust my boss placed in me would help me move forward.
Overnight, I became the Product Owner of Interbank’s Public Web, and for almost two years I faced the most difficult challenges of my professional career daily. We fought several battles together as a team, won some and lost others, but on balance I can say we made history together. In the following lines, I don’t want to bore you by repeating all our successes or create a definitive guide to being an infallible Product Owner. On the contrary, I’d like to share some learnings I accumulated during this time with those people who are just starting in this role or have interest in it.
The best theory is what works in practice
Yes, we’ve all taken at least one course on Scrum methodology and we’ve read about the role that a Product Owner, a Tech Lead, and a Scrum Master should respectively fulfill. And we’ve all also felt the same frustration when realizing that none of what those articles or books say actually happens in reality. Have we failed?
Theory is meant to guide us in the practical execution of a methodology, but it should never become an unquestionable dogma. On repeated occasions, some with more tension than others, I discussed with the team what our respective roles should be and what differences we found in what we did day to day. However, our discussions never aimed to generate conflict, but to reach agreements and seek an itinerant balance. Try and try, until finding a balance.
Some will say the Product Owner (PO) must have a strong technical base, participating in definitions that go a bit beyond the functional. Others will say the Tech Lead should be the one who really defines the how. I think there’s no perfect formula. We came to discover our strengths and weaknesses as a team, and then we leveraged the best each one could offer. Practice will show you that above theory and roles, you can always negotiate and reach an understanding with your work team. Find the way to get the balance you need.
Dedicate energy to manage your time
One day you’re an analyst with clear functions, and the next you’re PO of a project where you feel like you’re putting it all on the line every day and time isn’t enough. How can I find space to build my project’s day-to-day and also think about its future? How do I ensure I prioritize my backlog well if I have to measure the results of what I’m achieving in parallel? How can I make sure I write user stories well if I have to participate in planning, refinement, and retrospective ceremonies? Without a doubt, these questions don’t have easy answers, and the key here will be that you dedicate energy to creatively managing your time.
Don’t remember what you agreed on in the last meeting with the stakeholder? You’d better start sending your own meeting notes by email, and don’t depend on others for this. Want to have shorter, more effective meetings? Maybe it’s a good idea to prepare some slides before the meeting so everyone understands what you need in a few minutes. Do people distract you a lot in the office? You could try isolating yourself a few hours a week to advance faster with tasks that require concentration. Do you respond to each of your emails as soon as you’re notified? Maybe it’s better to dedicate only a few fixed minutes of your day to answering all emails and then continue with important tasks. In short, you must find your own method and not become a victim of circumstances.
Prepare to live with anxiety
The refinement was proceeding with laughter and good humor. The scope detail was reviewed, but as the meeting approached its end, the stakeholder launched an uncomfortable question that left everyone in silence. “When will the functionality be in production?” he asked. I’m sure this story sounds familiar and you’ve also repeated the same thing over and over: defining an exact date for launching a new development goes against the Scrum methodological framework, used mainly for managing projects with high uncertainty. Okay, now how do we make everyone understand all this?
I’m not going to lie: they didn’t understand me either. The only certainty in a PO’s life is that they’ll always be surrounded by anxious people. The speed of technological change, competition’s aggressiveness, and the urgency to achieve results are variables that constitute a perfect scenario for our stakeholders to remain nervous and searching for answers. So then, how can you solve it? Simple: provide visibility, lots of visibility. Exaggerate if necessary. Create a shared backlog for each of them and have them also participate in its management. Release estimated dates for your new developments, and highlight that they’re tentative. Tell them about the difficulties you encounter and your latest progress: keep them informed of your struggle. Any tool is valid as long as you and the stakeholder are always on the same page, and you can avoid dozens of emails/calls caused by anxiety. In my experience, a stakeholder will be more dissatisfied by not having visibility into what’s happening than by a deliverable that wasn’t delivered on the committed date.
The ideal MVP is the one in production
“We’d like this functionality to launch fireworks, leave the customer satisfied, generate business impact, and go to production tomorrow,” said an enthusiastic sponsor while talking with the PO during a refinement. With the same passion, the latter told this great idea to the Tech Lead. Suddenly, concern invaded both their faces. “Today we don’t have the technology or infrastructure to achieve it,” he ruled. Right away, the PO questions: how do I design the product of the future if I don’t have all the resources today?
Theory tells us that the best MVP is that deliverable that, with minimum effort, allows us to collect maximum learning from our customers. Sounds simple, but in practice deciphering this can be somewhat complicated. In my experience, the best MVPs are those that end up in production and generating value, so the first thing you should focus on is cutting (and cutting) the scope. Take it as fact: waiting for ideal conditions to launch an MVP is a key ingredient in a recipe called failure.
Once you’ve digested this important premise, what you should do next is expand your knowledge to the maximum about the technology your product uses to be able to propose creative solutions. Finally, and after having clarity about the minimum viable product you need, you must convince the sponsors that your idea, while not a definitive solution, is adding value to the business and that the first results will allow you to scale it to the next level. When they’ve accepted, you’ll be on your way to glory.
Learn to say “No” more often
At some point I called this project “The Dream Factory” and the truth is I wasn’t exaggerating. Every stakeholder who ever approached to ask for a new development always came with the same gleam in their eyes: eager to tell their boss in a few more weeks that that idea they sketched out on slides or paper a while ago was now a visible reality on the web.
Everything can be done. The technology team will always remind you of this; however, your role as PO will always be to prioritize ideas with the greatest business impact, and consequently deprioritize those that are more far-fetched. If your focus isn’t clear, you’ll end up with clinical stress levels and hating your project. I guarantee that. Regardless of long faces, unjustified complaints, and even complaints to your boss, you’ll have to say NO many times. But don’t misunderstand me: it’s not about saying NO just for fun. The criteria for being able to say it is something you’ll develop over time; however, the best foundation for making decisions will always be when you know the business and breathe the reality of the company where you work
Define why you want power
In recent years, the figure of the PO has been shared as that of the “superhero” in the imagination of agile communities. An image that has made this role very attractive in the market and whose metaphor I don’t entirely share (I’ll explain more later). It’s inevitable, however, not to have perceived in meetings with the team and other stakeholders that “the PO has the final word.” Faced with this reality, many months ago I reflected on this power that’s conferred to the Product Owner to lead the project.
I asked myself many times if I really felt comfortable with this “power.” If in some subsequent months I was going to want more power or if, on the contrary, I was going to reject all that they were giving me. After thinking a lot about it, and with professional help, I realized that the question I had to ask myself was really why I wanted all that power. It’s the same question I invite you to ask yourselves: Why do you want power? Power to lead a team to perform at its maximum potential? Power to give a group of people something to believe in? Power to change customers’ lives? Power to change the history of the company where you work? Answer this question and rest assured you’ll feel liberated and find motivation that even goes beyond your role as Product Owner.
In the coming days I’ll take on another role at Interbank and I write these lines to officially close this chapter of my personal and professional life that has allowed me to grow tremendously. I’m very grateful to all the people who trusted in me and who accompanied me throughout this bumpy and fun journey. No result could have been possible without you. Today I’m more convinced that teams that achieve extraordinary things aren’t those where the Product Owner is the only one who puts on the superhero jersey, but those where its various members (Tech Lead, Scrum Master, Analysts, Devs, QAs) alternate wearing it daily and push everyone to the next level. I myself confirmed this during the days I worked with the Interbank.pe team.
