How Much Does It Cost To Develop A New Feature?

Product managers often face this tough decision: from two competing product ideas, which one should we put on our roadmap? When estimating the return on investment for both, calculating the “investment” figure certainly looks easier. At the end of the day, a product team that knows how to build something should also be able to come up with realistic estimates, right?

Realistic cost estimates are a rare phenomenon. Just ask two or three software teams for their estimated costs for building a new website and you’ll get timelines and prices that are two times, or even ten times apart. 

To make matters worse, many project teams are based on essentially a fixed cost structure. The budgets are allocated early in the year, and there’s little wiggle room in increasing it if the project’s resources are proving to be tight. Any miscalculation in the workload or unforeseen changes to the schedule will likely have a knock-on effect on other projects or margins.

Why the naive model fails

While it’s difficult to provide a budget for a product idea, the same can be said for how software agencies give price estimates to their clients. The easiest way to price anything is to find out its costs and add a comfortable margin to it -- a lifesaver if new features get added to the product or in case someone leaves the team and time is lost on replacing them.

Of course, many experienced teams have the know-how to fulfil the brief on time and on budget. Even then, innocent questions such as “Can we look at this with a yellow background?” can make or break a project when the margin has already been eaten up. When calculating a budget, the name of the game is often: risk management. The more risk a project involves, the higher its price has to be and without a built-in buffer, projects are doomed to fail as soon as one of their variables changes for the worse.

Risk management gets you more accurate prices

The more risk a project involves, the higher its price has to be, but you can control some of that risk, and get a better product and a quicker turnaround.

  1. Projects that the product team has experience with are inherently less risky than anything new they pick up but you can shop for experience. Find team members who’ve been there, done that, and can help provide better estimates.

  1. Flag everything that’s uncertain. It’s OK to take risks if you feel like it, but it’s never OK not to know about them. Every time you see something that can take the team down the rabbit hole, increase the time and cost buffer accordingly.

  1. Can you find multiple team members or vendors for the same piece of work? Maybe it isn’t the right time to onboard someone new, but planning for extra capacity or reaching out to multiple providers rarely hurts. And if you can find only two vendors, and their quotes are ten times apart? The more realistic quote is likely to be the higher one.

  1. Large products take longer to deliver, and with every week between milestones, things can get derailed more easily. Write a schedule and set the deliverables for every milestone and task, make sure milestones are not too far apart.

Short and frequent milestones can keep unforeseen changes limited. With each new milestone after the first one, the product specifications will be blurrier and there’s more risk involved. However, because it’s really difficult to de-scope things you’ve already agreed upon, the better approach is to resist adding more detail to the descriptions. It’s easier to embrace risk and the incomplete specifications, and build in a buffer accordingly.

Project managers and product teams often dread giving quotes and time estimates, because  an incorrect price estimate can mean long extra hours and work on weekends, or even worse, a lost business.

Take the time to manage the risks, and be ready to strike a compromise in your quotes when needed. In any situation that you can’t de-risk, add as much buffer as possible. If you can’t add enough buffer to compensate for risk? Sometimes the only winning strategy is to say: no.