Innovate together with your first customer
Many successful commercial software products originate as a result of joint innovation between a customer and the developer. The first customer of a product benefits from getting the functionality that meets their requirement exactly. The developer benefits from having a committed user and some upfront funding.
When done well, this process allows the developer to build something that has relevance to a wider market and which can support a stand-alone business case. The intention is to offset the ongoing development and maintenance cost with revenue from commercial sales of the product.
The business relationship between the first customer and software developer becomes more strategic once the software products become integral to the customer’s way of doing business. If this relationship is not managed well it runs the risk of being unsustainable, and ultimately a breakup could be very costly for both parties involved.
From a software vendor’s perspective, it is very valuable to involve your first customer in ongoing product management, but only up to a point. If you get this balance wrong the arrangement can become sub-optimal for both parties. Instead of win-win, it becomes lose-lose. The customer ends up paying a premium for developing what is ultimately an inferior product; and the software developer is unable to commercialise the product to a wider market because of financial constraints or functional gaps.
Finding the right balance between customer involvement in early product development is therefore very important and will impact the sustainability of the business model going forward.
How are software products created?
There are two basic ways in which the first versions of software (or information) products are created.
The first is when a company solves a problem by developing a bespoke solution. During the implementation, it becomes apparent that the solution might have a wider application in the market.
The people involved make a strategic decision at some stage that the product should be offered commercially. By sharing the costs of ongoing development and maintenance with other customers they intend to ensure that the product will remain viable.
The developers then organise themselves as an “independent” entity with the goal to commercialise the product in the market with the support of the first customer.
The second is when an entrepreneur has a good idea on how to solve a problem, sources some capital, and invests upfront in developing a generic solution for the market. At some stage, the first version of the product is considered viable and taken to market.
The first implementation with the first customer is critical to the continued success of the product. This first customer needs to become a good reference and evangelist, as well as helping determine the roadmap going forward.
To sweeten the deal, the developer can offer the product to the first customer at a discounted license price. Repayment of the investment loan and continued investment in product features is funded from future license revenue.
Which of the two business models is the best?
The answer will depend on a number of factors and who’s perspective you take – customer or software developer.
In my experience as a software developer, the best and most sustainable products have without exception been the result of working closely with a customer from the start. The nature of this relationship is key to the success of both parties, and if leadership agrees on the strategy upfront then the objective of sustainability can be realised. When a product is developed in an “ivory tower” it rarely finds traction in the market because developers by nature tend to get excited about different features than end-users; and the product can become an abstract complex unfriendly monster.
The key to a sustainable relationship
Once the software developer starts licensing the product to other customers; the key to ongoing sustainability can be predicted by the nature of the continued relationship between the software developer and the first customer.
If the software developer dominates the relationship several problems can arise, for example:
- The first customer’s ongoing needs are not met in subsequent versions of the product; leading to dissatisfaction and lost value.
- The software developer pursues the next shiny opportunity and no longer invests in the product. It is then only a matter of time before the product becomes dysfunctional as the underlying technology evolves and change, or the business requirements change.
If the customer dominates the relationship then other problems can arise, for example:
- The software developer might not have any discretionary capacity to develop and commercialise the product for the wider market.
- The software developer is not able to diversify its business and remains dependent on the first customer for continued funding.
- Over time the product functionality becomes baked in and very specific to the first customer; is therefore not suitable to serve a market requirement.
- Commercially established alternative software vendors with a decent customer base will always be able to invest more in R&D, eventually overtaking your in-house program with a more robust generic and flexible product.
As can be seen, there could be significant cost implications of getting the balance wrong. In a situation where the software product becomes critical to the business (such as an ERP system or an operational system); this risk will only increase over time.
Who is responsible for getting the balance right?
The responsibility for creating a successful balance lies in several role-players within both businesses.
- On the customer side, executive sponsorship of the model is essential, and the CEO and CIO have a major role to play here; as do the functional heads who rely on the solution in their operations. They must all agree on the strategy and rationale for the approach they are following.
- On the software developer side, executive sponsorship at the CEO level is important. A strong account manager is necessary, focus on the relationship and delivery elements. A strong product manager is also vital to ensure that the product is relevant to the market.
It is not realistic to expect every developer/customer relationship to be without problems. When these occur, it is the foundation of the business relationship that will ensure a positive outcome. This is normally embedded in the contract between the software developer and the first customer. (There are several models of contracting which work and others that don’t, but this is beyond the scope of this article).
Always plan several steps ahead
At some stage, the software vendor will have diversified sufficiently and will no longer depend on the first customer. Industry analysts estimate this to be the point where the income from the first customer drops below about 30% of the total revenue (of the developer). By then there is probably a user group in place representing multiple customer stakeholders. The balance then shifts in the relationship and the developer can theoretically survive separation from the first customer.
At this stage it takes maturity within both parties to accept that sustainability requires that each party ultimately becomes independently successful. An arms-length relationship becomes desirable.
Navigating this shift in a relationship requires a clear understanding by both parties of what the ideal future looks like because old habits die hard and it will be difficult for the software developer to see themselves as truly independent and playing in an open market instead of serving just the first customer. There is after all a sense of security in holding onto old relationships that have worked before.
Many software products evolve to become world-class as a result of a journey similar to that described above. There is a body of experience in the industry that can be drawn on. However, there are just as many disappointing failures using the same model. It is therefore important to constantly communicate and reinforce the strategy and ensure alignment on the desired way forward.
By Gavin Halse
You might also enjoy
An information business is one where you are compensated for sharing your expert knowledge and experience through various means such as consulting, training, coaching, writing, entertaining, etc. You are compensated by the hour. An online information business is the...
A business requirements specification is not the same as a value proposition. If you want to create a product for a defined market, as opposed to a customer, then you need to be able to articulate a value proposition for many customers, not just the bespoke...