When you're still working out how to serve the most amount of customers in the most focused way, you need to be operating in the build-test-learn cycle.

Implicit in this is to build just enough to be able to test the feature in your market.

This approach is not well aligned with salaried or paid-hourly development teams because these models incentivise keeping people busy.

Consider a process by which you provide detailed requirements and your developers quote a fixed price to get them built.

This may sound counterproductive but it forces you and them to be super clear with what is to be built, and how it will be evaluated.

Software development estimates are generally wrong and, in my view, a big reason for this is that developers are simply not able to adequately think the solution through if they do not have a large downside. In other words, if they're paid for their time, the implicit idea is "I'll work it out as I go."

For extended relationships you may also agree on a fixed fee for scoping as well.

The increased overhead to capture the requirements and cost of each task provides a reminder that each piece of work should be carefully considered and must achieve a clear outcome.

To be clear, I'm saying that this way of working will mainly help during a heavy build phase, which may be in the pre-revenue or growth stages. It could be helpful at other stages but probably isn't ideal for those which are more evolutionary.

Often our way of working influences the structure of the end product. It makes sense, then, that a more directed development approach should result in a more cohesive set of features for your customers.