Why Failing the Interview at booking.com Changed My Life Forever
The bitter taste of failure opened my eyes to transform myself into a real Product Owner.
The bitter taste of failure opened my eyes to transform myself into a real Product Owner.
It was a beautiful sunny day by the end of summer in 2016 when someone from booking.com contacted me. The recruiter said: “Your profile looks interesting for one of our positions as Product Owner. Would you be open to discuss it in detail?” It was unexpected for me. I was really excited about the opportunity.
Back then, I was living in São Paulo. I had four years of experience as a Product Owner. I thought I was great in my profession. After the contact from booking.com, I started dreaming of living abroad. Yet, not everything went as I expected. After a round of interviews, I received the answer I didn’t want: I was not the professional that booking.com was looking for.
Although failing the interview had a bitter taste for me, it was the tipping point for my career. After the negative feedback, I recognized that I was not a Product Owner. At best, I was a good executor. I had to change something to thrive.
“Failure is another stepping stone to greatness.”
— Oprah Winfrey
Let me share with you why failing at booking.com is one of the best things in my career.
I posted similar content to my YouTube channel. As an addition to this post, you can also watch the following video.
The Learnings From the Interview
After booking.com contacted me, I thought I could get the position. But when I read the job description carefully, I was confused. I wondered, “Is this really a Product Owner position?” Nevertheless, I decided to take part in the selection process.
The first conversation was with a recruiter. The talk went well; the recruiter wanted to evaluate my soft skills, expectations, and willingness to move to Amsterdam. My motivation increased after the first part. I gained confidence.
Some days later, I had the second conversation. This part focused on the job itself. Before the interview, I thought it would be okay because I had four years of experience as a Product Owner. It turned out to be totally different. I was wrong. During the interview, I was puzzled. I heard many terms for the first time in my life. After the interview, I knew I had failed. A week later, I received the expected negative feedback.
Failing at booking.com was frustrating for me. But this failure was precisely what I needed at that moment. I thought I knew what it was to be a Product Owner, yet I didn’t understand half of the questions asked during the second interview. I decided to take this failure as an opportunity to learn. Some topics I had to learn were:
Discovery process: how to uncover the hidden end-users’ needs.
Validate hypothesis: how to learn as fast as possible to ensure we are building something that matters.
A/B Testing: a problem can be solved in multiple ways. Which is the best alternative for the end-users? Segmented tests can help with this question.
Product Vision: what are we here for? Where do we aim to be?
Outcome vs. output: the product increment refers to the output while its impact represents the outcome. The output is a means to an end, never the end itself.
Discovery Process
Part of the interview process was to describe how to discover what makes sense to build. Back in 2016, I had no prior experience with a proper discovery process. I used to have frequent meetings with stakeholders and define the next features with them. What about the real end-users? Well, honestly, I seldom talked to them.
I misunderstood what being accountable for the Product Backlog means. I thought my mission was to keep the Product Backlog updated and reflecting the stakeholders’ needs. Every day I updated the Product Backlog according to my learnings from the stakeholders. I basically prioritized the work based on the stakeholders’ feelings. As you can imagine, we endlessly built features nobody needed. Yet, I didn’t understand why.
The interview with booking.com opened my eyes. I was not a Product Owner. I was investing most of my time in building the features right. But I forgot to spend time clarifying which features are useful to create and which aren’t.
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
― Marty Cagan, Inspired
Set Goals to Achieve Instead of Tasks to Deliver
Another critical realization during the interview was that: I focused solely on delivering tasks instead of achieving goals. I remember when the interviewer asked me: “How do you communicate with developers what to do?” My answer was, “I prepare a detailed specification with all the details. The solution is clear. Then, the developers can focus on coding.” It’s embarrassing to say that, but that’s how I worked.
I thought I had to provide all the needed information to developers. Then, they could concentrate on transforming documentation into working software. It was a huge burden on me to write extensive documents. Yet, we kept building something useless, and developers were disengaged.
Product Owners should focus on identifying opportunities. Then, share with the whole Scrum Team which goal to achieve instead of which tasks to implement. Collaboration is vital to success.
“The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
Measure The Results
Until 2016, matching deadlines was a synonym of success for me. I used to align with the stakeholders which features to build. Then, I would estimate the features with developers and give a deadline to the stakeholders. Whenever we made the deadline for all features, people were happy. But only in the short-term.
Something frightened us. Despite delivering exactly what we agreed upon, the business remained still. We were not acquiring new customers or generating more businesses. As a Product Owner, my success metrics were wrong.
I thought that more story points delivered meant maximizing the value. We never killed any feature deployed in the live environment. Once again, my misunderstandings of Product Management led the Scrum Team to poor results.
“At the end of the day, your job is to minimize output, and maximize outcome and impact.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
Failure Is the Best Teacher
When I look back to 2016, I was a horrible Product Owner. I had many misconceptions. I am glad booking.com invited me to the interview process. After I failed, I could refrain from my perceptions as a Product Owner.
The failure showed me I was very far from being a good Product Owner. But I clearly understood what I had to learn. I invested time in understanding what I didn’t know. I became a more curious person. Today I accept my ignorance, and I am always looking to learn from different perspectives.
Thanks to the failure I had in 2016, I learned:
Outcome is what matters the most. It’s not about delivering features; it’s all about making people’s lives better.
The faster we prove our assumptions, the faster we can succeed.
Product Owners are leaders, not managers.
Before starting anything, the success metrics have to be clear.
Collaboration is vital to thrive.
Do you want to write for Serious Scrum or seriously discuss Scrum?