>>> fix all the bugs that are upsetting customers and causing them to flee. Well yes. I am just posting that it is possible to take a top level metric and bui

>>> fix all the bugs that are upsetting customers and causing them to flee. Well yes. I am just posting that it is possible to take a top level metric and build a backlog that represents sensible solutions to that metric. But you first need - a top level metric (preferably that measures what will make or break your business) - a way to determine what things under your control drive that metric. But yes, the things you do in the trenches will probably not move the needle far. That is for two reasons - at some point the code base is so big that doing "one thing" won't make impact (i think this is around the 100k SLOC) level which is still fairly small - and even if you can affect the whole code base, the code is at the bottom of an inverted pyramid of "leverage to affect the business" - the CEO can chnage the business far far more be deciding to triple the price tomorrow than any bugs you fix. But yes - in the end, if you have a working product right now the best thing to do is to go find real customers, work out why they are upset (either with clever telemetry analysis or just fricking ask) and go fix that bug / missing feature. If you don't have a working product there is no telemetry so ... fricking ask. But find what's not working and fix it is a good plan. If what's not working however is "the business model" we are in interesting territory I think a non working business model is exactly the purview of software. I think that we shall replace all non-coding business people with coders who can business in a generation. But that this generation will see real opportunities