Hacker News Reader

> Why - Expected ROI

Any guidance for quantifying this if you're an engineer and don't have access to financial numbers?

It's hard for me to estimate the value of a feature I'm designing if the Product team just says it's important without giving financial reasons. Presumably the feature will benefit the customer, but it's hard to translate that into e.g. "5% revenue increase"

View on HN

I wish I had a straightforward answer for you. This is an important question to quantify, in order to justify the scope and timeline for building features. As an engineer, I always believed that there’s some version of the “no free lunch theorem” applicable to building product roadmaps (and as an extension identifying pertinent product features). Meaning, you can’t reasonably predict what features are going to work, and how well they’re going to work to translate that to $$$. If I could take a guess, I would build out a framework to accurately guesstimate the value of a feature as follows. A brute-force approach to build out a free —> paid feature funnel: 1. Launch a beta or a “free” version of whatever feature you’re building. This could be as hand-wavy as conducting focus groups and doing proper UI/UX research to validate there’s “some amount” of interest in your user base. 2. Tighten the scope and refine the feature to make it as seamless as possible. Check the app/usage stats and KPIs to ensure people actually derive value out of your features albeit not actually paying for it now. 3. Start charging for it. And see how many people will actually pay for this well-refined feature. Do this long enough, your company should have some baseline numbers for all of these steps. %conversions on steps 1 —> 2 —> 3 and therefore, better ways to estimate the “why”.

Reply on news.ycombinator.com