while originally it's "extended Berkeley Packet Filter", at this point it does so much more than packet filtering that spelling out the words probably increases confusion rather than clarifying anything
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”.
