Product Management Skills - Articulating development cost risks
Development cost risk is the easiest one to think about for Product Managers, but it’s also the one they misuse the most.
As a product manager, you have to be able to articulate, separate, and define your risks - the potential negative effects of whatever you are trying to do. Articulating them helps you frame and compare them appropriately - ignoring low risks and mitigating higher ones.
These are the levers you use and the plates you balance as a product manager to create and deliver value.
Saving money can be wasting money if you aren’t replacing it with another piece of work. Thinking about theoretical capacity available helps combat this counter-intuitive issue.
Development cost risk
Development cost risk is the easiest risk to think about for Product Managers, but it’s also the one they misuse the most.
Development cost is the cost to develop the solution. Every single solution being built has a quantifiable amount of time it will be expected to take. That is the development cost. To identify this amount, Product Managers work with their engineering partners to obtain estimates, or look at historical trends, or if they bad, just make something up.
Once that time is obtained, you can multiple by the average developer salary to quantify the development cost in terms of dollars:
For example, supposing there are 2 developers and they are working on something that’ll take them 2 weeks to build, at $4,000 / week per developer cost:
2 developers
x 2 weeks
—————
4 developer-weeks
x $4,000 / week average salary
—————
$16,000 development cost
You now know that it’ll cost $16,000 to develop the solution,
The development cost risk here is that the cost of developing the solution will not be worth the impact it has. For example, if the impact ends up being estimated to be $100, it probably wasn’t a good tradeoff.
The second development cost risk is that a cost over-run occurs, and the solution is more expensive to develop than previously believed. This still results in the same efect as the solution not being worth the impact, and is more of an engineering concern to monitor and avoid - outside the scope of this particular post.
Addressing the risk
As a Product Manager, you can address the risk a variety of different ways.
The first option is to reduce development costs by cutting scope. Can you solve the problem with a simpler solution? If so, you can change the ROI calculation for the solution.
Many Product Managers don’t actually cut scope, though. They haven’t thought about the solution space enough, or maybe they can’t envision what the smallest possible increment could be.
Instead, the first tool they often reach for is to say “no” and to remove that solution from consideration. They don’t do it at all, instead looking for more valuable items to work on.
Ka-ching! You just saved the company $16,000…maybe.
A key pitfall in saying “no”
There is a subtle nuance in addressing development cost risk that most Product Managers forget when working in a product-based organization: you are always paying it regardless of what you are working on or not working on.
Developers in long-lived teams are typically salaried - they get paid every two weeks regardless of whether they do 1 thing or 100 things. This cost is a recurring amount. It doesn’t stop if there’s no backlog of items to work on.
Product Managers attempting to prioritize solely from the lens of “saving developer bandwidth” or”avoiding something that is too costly to build” can potentially act counter-productively, incurring an even higher cost than time they actually saved from not doing a piece of work.
This is because many well-intentioned Product Managers turn down decent, valuable items to prepare or work on something even more valuable, without having something else ready for development. With no backlog and no ready work, the developers just sit around with nothing to do or tinker on technical concerns of intellectual value but no meaningful impact, or work on lower value items than the one that was discarded.
Remember: in an organization with salaried engineers, you are always incurring development cost if you don’t have something ready for the developers to do. Efforts to address development cost must factor in that this is the floor of cost.
Counter-intuitively, this means that declining to do something because of concerns of development cost can actually lead to lower overall value delivery in some cases.
An alternative approach
An alternative model I prefer to use when thinking about development cost is percentage of developer bandwidth. It’s a common one I use as an Engineering Manager when I think about team capacity.
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.