It's often impossible to get metrics on what new features you should build since your users have not yet experienced them, and those that give you feedback are not necessarily the ones you should listen to.<p>My experience is that you push out the feature and test them. If there us usage, you keep them, if not, you kill them. Testing works a lot better than trying to measure future usage.
I don't mind this strategy, but it requires that you already have a product good enough to get customers—assuming you are actually going to <i>measure</i> things to plug into the formula.<p>So, there's a bit of a chicken/egg problem here. The way to solve it is to do great customer development (see Steve Blank et al.) to make sure you are addressing a real problem, and then make the best damn product addressing that problem that you can within a reasonable cost. Maybe your gut/luck is good enough that you don't even need the customer development step. But still, an "MVP"—and I admittedly don't like the term—really can't be 'minimal' to make that formula usable in most cases; you've got to make something good enough to attract and retain users right out of the gate, and that requires taking on some risk.
> how should I be spending my time?<p>Good question<p>> It is best to pick a metric you are pretty sure you know how to increase.<p>Good answer but the game is a bit more complex. It's good to have a KPI driven behavior but it depends also on the stage and thus, KPIs can change quickly. Sometimes you should find best hires, sometimes the best angels and VCs and sometimes customers or reach.<p>> (b * d) / c<p>Not really sure about this thing. I like your thought behind it (that before implementing an idea check if it's wanted and build time is in relation to the potential market size) but I don't know if the formula is a good way to communicate this definitely good idea--it's a bit too abstract/cumbersome.
Dr. Eliyahu Moshe Goldratt explains how to manage complex systems, trying to manage everything at the same time is not only unrealistic - it will also not bring success.<p>Explanation in his own words is for example at <a href="https://www.youtube.com/watch?v=tWvMODJ9cVc" rel="nofollow">https://www.youtube.com/watch?v=tWvMODJ9cVc</a> but also in many other lectures and presentations of his available online.<p>"... managing a bunch of wild cats" was said somewhere in there.
My first reaction was to think that (b*d)/c was a cool way of expressing how to go after the low hanging fruit, or get the biggest bang for the buck. After thinking about it for a bit, it seems like a good starting point and better than nothing to act with some intent.<p>But it might be better to focus more on b/c OR d/c, or weight b and d, if you're trying to come up with a general framework. In practice, that comes out to generally, we want to go after broad OR deep features we can build easiest as we groom the backlog. Of course, you would want to maximize both b AND d, but often a single feature doesn't do both.<p>The whole discussion might be too nuanced. Overall, it's valuable to give some quick thought to why you're picking the features you pick, as long as it doesn't make decisions take too long.
This feels pretty high level. Knowing that we want to build the most profound feature for the most number of users is not very controversial. But there are many ambiguities about how you measure profoundness. There are many things that I could fill up my time working on each day all in the name of building profound things - e.g. do I build this feature, do I refactor, do I do customer interviews etc.<p>In my experience, teams always struggle with that level of decision making, and the problems stem from optimizing for the wrong tasks, even if someone is overall agreed on what the "most important" metric is.
"Task switching overhead is an intrinsically hard problem to solve. As a startup CEO, at some point you need to shut everything out, go with your gut and move forward."
I think the (b * d) / c formula is not just useful for startups, but for just about any software development.<p>It's what I try to use for 'in-house' development, although the (b)readth in that case isn't about expanding customers, but about how many of our userbase will be (positively) affected by the change.
Note that Geoff Ralston is a Y Combinator partner, which is context that otherwise makes the article confusing.<p>EDIT: relevant info was added to the user profile after this comment was made.
Here's a braindead simple idea for how to get a startup going: 1. Don't hire anyone else until you're making money.<p>I mean, how easy is that? It's not flipping rocket science.