As product managers, we often try to think practically about what gets built first. There are many components to a product, including a features list, and all can seem equally important. However, not all features will be built together. How do you determine the cost of delay to order priorities? TIFIN Product VP Abhinav Gupta shares how to take the economic value of a product feature and quantify the cost of delay. 

Join us for new conversations with leading product executives every week. Roll through the highlights of this week’s event below, then head on over to our Events page to see which product leaders will be joining us next week.

Join us at our weekly Speaker Series to gain insight on how to accelerate your career as a product leader.

Join us at our weekly Speaker Series events to engage with product leaders in your own community and gain insights on how to accelerate digital transformation.

On Why the Cost of Delay Is Important

The most important part of being a product manager is asking the why. That question is the focal point of the process, including the idea of exploring the cost of delay.

“Every question, every feature, every solution that we’re trying to build, we need to define and ask these questions as product managers. It is why we want to do it and what we want to do. That is the first question. …

“Why are we talking about the cost of delay? … Even in your product, whenever you’re trying to build a new feature, just ask this question, ‘why do you want to do this,’ and then, later on, figure out what, and then, later on, figure out how you’re going to do it. I think for product managers, the question of how definitely is not something that they should be very close to. That’s more for an engineering team to figure out the technical designs and stuff like that, and then actually do delivery. Why is the holy grail of everything that the product manager always has to think about inside their heads.

“Product managers are usually racing with time. In general, you might have 20 Chrome browser tabs that are open, 30 Excel sheets that are open up, and you will always have your calendars filled. You will have all these conversations with sales, marketing, engineering, UI, UX, and others. There’s so much that is coming your way, and you are basically a conductor of that orchestra around all of that entire thing that you’re trying to build. You will have that overarching view of that particular product. This is very important. 

“You don’t let the ideas and you know the list of the features that someone is requesting to stop flowing into your backlog at some point. You also want to prioritize because there are always so many ideas. There is so much information that is out there for a product manager to absorb and then prioritize. So that is one of the very, very important reasons why we want to just talk about why the cost of delay.”

On How To Calculate The Cost of Delay

It seems like calculating the cost of delay can be complicated, but it really isn’t. Abhinav gave a few examples of how to see this in your work life and which numbers are most important.

“Let’s make it more simplified in general. So the simplified version is to estimate the revenue per unit time for what that new project would generate. You’d have to just do a micro project within that particular product that you’re trying to build, or microfeature or whatever you want to call that. You want to also ensure that whatever feature that you’re trying to build, and you’re trying to add into the product, it has to ultimately earn revenue. When you’re shipping a particular feature, it has to add particular revenue to the entire scheme of things, whether it is in terms of the direct dollar cost, or it kind of solves the current problem on a larger scale of things so that customers don’t get grumpy about certain things.  The keyword over here is you have to define that unit time that you want to measure it. ….

“You also want to estimate the amount of the time your team needs to complete that particular project. There has to be an estimation done by the team. I am not going to my sales rep and say to give me some numbers from the air. Instead, I’ve done my validation with my teams, internal UI UX, engineering, and all of those teams, and then come back with a particular number that says this is the time that I would require to kind of build that particular thing and divide that entire number with your time duration. 

“For example, you say like 500 days as an estimate that you are building that particular feature, and you multiply 500 days into the dollar amount based on your cost of that particular thing, whether that is $100 an hour or $100 a day. … This is a very real way of like coming back to the sales team and saying if we do this, we are going to invest 500 days, which is equal to this particular cost. That’s the number that we wanted to just showcase to them. It’s as simple as that you’re just getting the number, you’re dividing it with time and getting a real number. 

“Make sure to stack it with the overall impact that a particular feature would have. You have already determined what is my cost of delay, and then you’re determining the impact of that particular feature that is going to make.”

On How To Start Prioritizing With The Team

The final step in cost of delay is getting buy-in from the team by creating a huddle, laying out all the ideas, and voting together on what to prioritize. 

“Then you go back to that particular drawing board with your team. …. You’ve calculated the numbers, you already have the list of ideas. You have calculated values, you’re trying to stack them up. You are then taking a conscious call with the entire team about why you think that you’re going to make that particular decision. For most of the products that we are building now, you don’t have to go with one particular strategy. This is a very common strategy that a larger organization usually has. Say you have 50 people: five people do this, five people do this, five people do this, and then on one fine day, we’re gonna wholly merge everything and then make a brand or grand big product. I think sometimes that particular strategy kind of takes a lot of beating in general and in my experience, we waiting for like two months for a big bang release to actually happen, and where we haven’t validated with a lot of things that we could have. 

“I am generally a big advocate of shipping out things very quickly and just getting the pulse of the particular product. Even customers or the users don’t know how the product needs to be defined or like how they’re gonna use that particular product. So in the shorter run, if you can just bring some of those features very quickly in front of them; it might not be very prim and proper but then again, we also don’t want to build a product and throw it over the wall with a big bang, feature release. In that particular case, we would be losing a lot of money because we have invested pretty heavily all that time.

“The features that can deliver the maximum cost of delay in the shortest duration of the time need to be brought in first. I’ve been there, there’s no thought about it. You want to make sure that the impact of every single feature that you’re trying to build is the highest: highest to the customer, highest to yourself as a product owner, and that it drives your P&L of that particular product. So just put all of those notes about every single feature that you had in your product backlog or your idea map or your Myro board or whatever you trying to build in, and put all of those sticky notes there. Then calculate all of those values into a particular sticky note, stick that particular number. All that should drive is that particular number instead of some story points.

“This is a very mathematical and a very easier way of sticking a particular number to a particular feature list. Then you actually analyze and get the vote from your entire team. Do you think that scope is going up or going down? You then have buy-in from the entire team ecosystem. That’s how you would prioritize your entire backlog.”

About the speaker
Abhinav Gupta Statestreet, Vice President Member

Abhinav Gupta is a Fintech Product Leader and an engineer by qualification, having built several Fintech products ground up. He has more than 18 years of experience in the FinTech industry and has managed and planned products and services for Fortune 500 companies. Abhinav is currently the Vice President of Products at TIFIN, an AI- and investment-intelligence-driven financial services company. Before this role, he was the VP of Product Management at State Street. He loves to speak to customers, and design a customer journey, identifying product-market fit, and he specializes in product design and product monetization strategies that help build/design products that will last. Over the years he has managed products across continents (India, USA, Denmark, UK, and France) and has set up, managed, and grown remote teams. He also has won numerous awards for his work in the FinTech industry and is a regular speaker at various industry forums. Abhinav likes to read books and blogs about innovation to stay in the present and keep his eyes on the future. He is an avid cook, traveler, and audiophile, and writes blogs about product frameworks.

Get answers to your questions
/ Join for Free with LinkedIn

Join for FREE and get access to :

  • All EBooks
  • All Infographics
  • Product Award resources
  • Search for other members

Coming for members in 2022: personalized content, engagement, and networking.