The cost of product requirements in a new product release
When working toward a product release, once you have prioritized your product requirements, you will:
- Better understand the business priorities associated with your requirements
- Have a list of requirements ordered by importance for your company
This is not the end of the process, however. You must now understand the cost of each product requirement.
The cost involved hinges on how much effort it will take to deliver each requirement. Your team can provide an estimate of how much effort it will take to solve a problem (that is, build the requirement). You can measure this amount of effort in hours, days, weeks or months. By getting estimates from your development team, you will be able to see the cumulative effort needed to deliver all of the requirements on your list.
Evaluating the costs of product requirements
Once you receive the estimates of the effort from your development team, you will then have to evaluate those costs. This does not involve testing the validity of those estimates. Rather, it requires an understanding of the costs, and whether there are more economical approaches.
Trade-offs to reach the product release
There are multiple ways to solve problems, and each tactic will bear a different associated cost. Keep in mind that customers use only 20% of a product’s features; you might want to explore less costly (and perhaps less elegant) solutions for features that are seldom used.
Example: If you are building an online solution that allows users to manage their own profile, one solution that automatically logs them in may cost four days of work, while forcing users to log themselves in may only cost one day. If a user rarely changes their online profile, the second option may be acceptable.
Identifying exorbitant product requirement costs
If you identify a requirement that seems to have an exorbitant cost, ask your team if there are different ways to solve the problem. Alternatively, you might want to re-examine the requirement, as it might be a particular aspect of the requirement that is causing the cost of the solution to escalate.
If the cost is too high, you could opt for a workaround for the functionality. By collaborating and brainstorming on the potential solution, which could involve trade-offs, you can come to a solution that works for everyone.
Example: A new type of website has been created that allows users to donate their charitable dollars to any charity in the world. Because there are so many currencies, the original requirements included the ability to convert a users’ donation to the charities’ chosen currency using an up–to-the-minute conversion rate. However, the cost of this feature proves exorbitant. The team proposes that they convert the currency only once a day, using the daily rate. The tradeoff is the monetary difference in the conversion of the donations versus the cost of delivering the up-to-the-minute functionality.
Buying versus building a product requirement
When evaluating requirements, it is useful to understand what it would cost to buy a feature instead of building it. In some cases, going this route proves the more effective and efficient strategy.
During the costing process, make sure to investigate the cost of integrating another company’s technology.
Example: If you are building a solution that includes photo management, you might want to provide functionality that allows users to crop photos. While your team could build that functionality, you can also find open-source alternatives, or online plug-ins, that would serve that same function and save your team time.
Costs versus revenue
Compare the costs of developing a feature against its expected revenue (if it is a revenue-generating feature). It should be worth the effort and resources to build. If you choose to build a feature with a high resource cost, then ensure that the expected return on investment is also high. For more information, see Prioritizing product requirements.
Impact of costing on release priorities
Once you identify the costs of the requirements, you will have all of the facts to determine the timing of your product release. Bear in mind that as with any project, you can adjust two of the three variables in the product release: scope, cost and schedule. For more information on this and how it works, read the article, Product requirements and requirement prioritization.
No comments:
Post a Comment