The Simple Rule for Prioritization

Deepak Gupta

Product Manager at Amadeus



If you ask any Product Manager about what their bread-and-butter is, chances are they would say "prioritization." In my recent experience, we had a new product merely signed by 4 customers. Being a startup, of course, everything was going in a fast-paced work environment, and on top of that, 2 of our customers wanted the deliveries yesterday. The company that I was working for, their big, complex products, has existed for more than 10 years without facing any competition.

The default way in which the products evolved was based on customers' demands. Obviously, customers know what they want; we were the bridge that would help them through the technology to run their business. Since it was in the airline industry, they were super complicated regarding their promotional campaign needs, the various seating arrangements, and the constant change of rules and regulations for their passengers. To sum it up all, there were a large number of complexities in terms of business needs.

The company already had grown, whereby product evolution was strongly influenced by customer demand. For instance, if the customer was asking for a feature, the question was not whether we could build it but when we could make it. This was slightly conflicting with my inner PM mindset. That was because, deep down inside, I knew that customers do have a problem, but more often than not, what they were asking for was not going to be the best solution for their situation. It was their way of working; customers would talk to us about specific solutions rather than break down the problems themselves.

Actions taken

I inherited a backlog in which there already were many commitments lined up for the next 6 - 9 months. On top of that, the morale of the engineering team was not so great. Till now, we had merely built an airline's mobile app that the developers could suggest in their opinions — what an airline mobile should and should not have. Although it was not a very complex product, everyone needed to know the context to debate. Instead, everyone had a say about how much value it would have.

There was a recurring problem that I was trying to groom a product with the team. On the other hand, the team was utterly silent. I felt that our mobile app team had to be more passionate and debating about their work, where others insist on placing their own ideas, yet everyone was calm. Honestly, it was not an easy task to enable the user to go through the steps, book a flight, and pay for it within the app.

I was not happy with what I was building. All I did was keep on mentioning to the team about the next steps for the next quarter. So, I zoomed into the problem and started another long journey; I plugged the flood of requests coming from the customers, getting them back down on what they were asking for while listening to what we had to offer.

I remodeled the idea of creating a user's travel journey who would be using the app. I started from scratch. How do people get the inspiration of traveling abroad? From Instagram campaigns or Facebook ads. Starting from the inspiration step to the post journey, I identified 9 stages of travel. To my surprise, our app offered very little to the users. So, I started strategizing what it should have and created a backlog for the product.

Furthermore, I moved on to brainstorming with the engineers. We talked about the hypothetical scenarios of what we would build if we had the opportunity to do so. My idea was to create something that nobody had ever done so far. Slowly and steadily, I pushed my thoughts to our customers, after which I was able to prioritize what I wanted to do in the roadmap.

I went with my proposals to the customers and asked them whether they would like a particular feature to be delivered next quarter. Once I had their approval, I brought that to the senior management, saying that the customers demanded it. I became a bit bolder and started proposing more proposals that I wanted to do, even though the customers did not ask for them.

After that, I aimed to develop ideas that would make a great sales pitch for my product for new customers. While existing customers were happy with the latest features being offered to them, I wanted to increase sales. Here was when two conflicting teams emerged:

  • The product itself, where the goal was to make a traveler's life easier.
  • Our customers were the airlines, not the travelers.

Typically, when the buyer is not the same as the user, the product team must balance the two. For a mobile app, I could think of a ton of features in my backlog yet create only 6 – 8 features. Safe to say that there are systematic frameworks for prioritization. I tried them and realized that there are endless flaws in them. I conducted presentation forums within the organization.

Lessons learned

  • I would always emphasize the importance of prioritizing tasks for product managers. It allows them to make better decisions based on the value that matters the most to the company.
  • It is indeed difficult to hold onto customers until you agree to innovate. Always try to be on the run while offering new appealing features and services to your existing customer. In the process, don't forget to attract new customers.
  • Product managers have to become comfortable with risks. Make sure to drop in some strategic yet executional risks that will make you learn what success is.

Be notified about next articles from Deepak Gupta

Deepak Gupta

Product Manager at Amadeus

Decision Making

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up