Most startups, and many well established companies, utilize “agile” methods to develop new products. These methods involve customers trying early versions of a product in order to validate conceptual viability and provide feedback to be used for further iterations. There are books and training courses sold to promote “lean” development approach, which I have no quarrel with, but I have yet to see a clear articulation of what stage of such product development process it is appropriate to start billing customers for use.
Here is the dilemma – wait to charge until the product is completely developed (and foot the expenses while early adopters enjoy the benefits without knowing if they ever going to pay) OR start early and risk repelling valuable development partners.
Both parties in this partnership have to see a benefit to participating in the agile development process to get involved. Customers anticipate that the product will improve their life, when developed, and developers need the customers’ knowledge and experience to develop marketable products. The balance of risk and reward for each party should be periodically assessed to produce a list of necessary conditions to be met before billing can be initiated.
The risk for the development team depends on how much knowledge they possess about the market they plan to address, the processes they target to optimize, and the customer experiences they want to simplify. The risk for the customer is in disruption of their existing process, time investment in learning new workflows, and political capital that may be lost if the product does not materialize.
The trust is the most critical condition for any partnership:
- Do not ever try to masquerade “puppy” sale strategy as product development partnership;
- Always communicate how and when, if ever, you will use the feedback given to you;
- Help the customers sell your product when it is ready to be sold. They will be much more effective than your sales team.
Validate that the product as-is meets initial customer expectations in terms of functionality and performance before starting to bill the customers. Functionality allows customers to simplify their workflow and process, i.e. save time/effort by a measurable amount. Performance means customers have the functionality available to them consistently and without interruption. Even though these customers are a part of your development effort you cannot expect them to pay for debugging your product. The balance is critical because too much agility can be too disruptive.
I’ve experienced both sides of such partnerships. When they worked it was a glorious experience producing very successful products, but when they don’t the developers can lose more than time and money they have invested into the project. Customers can share their negative experience with the development team publically, before the product launched, to destroy any chance of it to succeed.
