Run the Numbers before you touch the code

We’d been thinking of a new solution for this company that had pop-ed up a couple of times already, each time we got a little further in seeing if it was a viable opportunity. I was actually very bullish about it, we’d looked at user demand getting feedback from 2-3 potential customers, we’d looked technical solutions for the product, we’d done a couple of quick tests and already found one key bottleneck, I’d even run some numbers to look at business viability. 

Fortunately the dev’s hadn’t actually spent any time on this. I had decided to do a last call with a contact and the feedback wasn’t very promising, they’d managed to do something similar to what I was proposing and their unit economics threw off all the major assumptions in my model and exposed other variables that would have made my original model even more uncertain. It was a blessing of a call.

Without that call, who’s telling how many hours would have been wasted building a white elephant. Even as a prototype it wouldn’t have been worthwhile to take the risk. 

And this is the big lesson, sometimes the interviews and feedbacks and running model simulations of the unit economics – in effect a feasibility study is critical, even before you get the engineers involved.  You wouldn’t build a house on ground you haven’t first surveyed, so why would you build code on a feature you haven’t vetted?

Leave a Reply

Your email address will not be published. Required fields are marked *