The Rosetta Stone for CTOs: Feature – Benefit – Value
Development teams are used to defining new features with any software product, whether it be front end, back end, mobile-based or other.
They have the tools and skills to define scope. They also have enough insight to provide estimates. How much time, money and personnel is required?
In terms of final ROI for a project, both developers and the business decision-makers need to ask this question: does the outcome justify the development cost?
Here’s a simple translation tool for your team to work better together.
The Rosetta Stone for CTOs. A 3-step conversation between business people and developers
What Feature do we need to build?
The development and business teams are both free to list as many features in this column.
The features selected are then looked at by the tech team to provide resource estimates, and translate into sprints.
What’s the Expected Benefit?
There must be at least one benefit linked to each feature. If there are no benefits, it’s a no-go for the feature.
Benefits may be overstated just to push the feature through. The next step ensures this mistake does not happen.
What’s the Value to be realized?
Measure value in a way that is meaningful to the business.
When altering existing functionality, base data should be presented and the desired change should be specified.
Unless you quantify the term ‘Happy Customer’ it is not an acceptable value.
How could you actually use this Rosetta Stone for CTOs in a business context?
Example. A marketing team determines that during an event registration process, 20 percent drop out before completion.
The organization wants to cut this drop out rate to 10 percent. In this case, we’re working backwards from the value point.
The UX/UI team suggests two solutions to improve the UX (the feature) which will create a smoother transition from one step of the process to the next (the expected benefit).
The development team, working in collaboration with the UX/UI team, produces two feature sets that solve the problem.
The development team provides an estimate of what resources (time, money and personnel) would be required for each feature set.
In stage three of the conversation, the business can then decide if the value outweighs the cost of either feature set. On that basis, the business can either proceed with one of the feature sets or shelve the project.
If they choose not to proceed with either option, they may wait until a different solution is found. Alternatively, a business constraint may change that makes the proposed project viable when comparing the value and cost.