"The big difference between consultancy and product based development is that with consultancy you're building what the individual customer needs rather than building what your product needs strategically in the long term...."
If so, then focusing only on product development is going to be successful only if you know what your customers in aggregate need better than they do. Isn't that the whole 'agile' lesson?
Focusing too narrowly on immediate improvements can constrain scope to bug fixing and building the best version of the current product possible rather than adding new features and directions for the product. It makes the product vulnerable to competition that better meets the ever-changing needs of the market.
I'm not saying it can't be done, just saying that you have to be careful when managing scope. And that isn't even a unique concern to a consultancy-based model, it just has different pitfalls.
Keep in mind you don't know what the features and directions of your product should be until you talk to your customers and understand what roadmap will fit their needs. For every DropBox there are hundreds of failures that didn't get it right about whom we never heard about.
Let's say your consulting pays for the time of one engineer while your investors pay for another one. If you stop your consultancy, your workforce will have to be slashed by 50%. Unless the custom development job is focusing on features that add no value to the product for other customers, this is insanity.
If so, then focusing only on product development is going to be successful only if you know what your customers in aggregate need better than they do. Isn't that the whole 'agile' lesson?