Whatever the request, I always deliver a product.

Try to imagine an incredibly fortunate situation: instead of signing a contract for a project, the client requests the delivery of a product. The great thing about this is that it gives you the opportunity to be paid to avoid and correct – in a clear and transparent way – all the pitfalls involved in project-based work.

When I ask people the question "If the digital product produced as a result of the delivery of the project does not live up to the business expectations placed on it, who will the client blame?” nine times out of ten the answer is “the supplier”.

We would like to believe that as a software development company, we sign the contract for the project itself, yet actually the sad truth is that in the minds of your customers, you are always delivering a product, and they see you as responsible for that product.

If the client chooses a bad business model, or even worse, they believe they have mapped out a business model, yet they don't know how to develop a digital product in reality, this means that any risks from not addressing these issues will land on the desk of the software developer-supplier.

When (and not 'if') you reach the point where the software developer-supplier needs to get the contract out, as because of the client they have to defend the delivery of the product and the purpose of the contract, then in all likelihood the project is already a failure.

The client won't place any more orders, and from that day forth the name of the supplier will just get their blood boiling.

This is exponentially true if, due to dependencies formed during the development process, it also becomes excessively expensive and hard to change the supplier… if it is difficult for the client to get rid of them.

No contract will defend the supplier from the feelings of the client when they have to utter their name.

Only one thing can help – you yourselves. 

Before making a business proposal, it is essential to lay the groundwork for three key strategies that must be validated in fields that are constantly relevant and need to be operated in parallel during any software product development. 

The three strategic dimensions

These are not linear steps, but rather continuous intertwined activities.

• • Continuous design: The strategy I follow when working on the design
• • Continuous software delivery: The kind of strategy I follow when I develop, hand over and launch the software
• • Continuous aftercare >>> responding to market feedback, warranty period, follow-up: After any launch, the strategy I should follow to provide the best possible service

You might think that product delivery ends once the product has been delivered. But no, this is not the case. Product delivery actually ends when the warranty period of the given project comes to a close. In fact, you may well find there are some fairly major development requirements during the warranty period. So when does the warranty period actually begin? When I have delivered the original product, or when I have delivered any further developing work? 

How does the warranty period work when it comes to fixing bugs? 

If I fix a bug that I notice after delivery, how does the warranty period for that fix work?

Have you even considered how long or under what conditions the life expectancy of a software product is?

If you haven’t answered these questions yet, it’s time for the development and legal departments to come together, fill the gaps, and update the T&C.

Priority tasks in each strategic dimension 

How you want to work is one thing. Whether you can build your approach into the contract is quite another. Even more important than that is whether you manage to explain to the customer at the very beginning of the bidding phase how the way you work is a value proposition for them (have you formulated these ideas yourselves yet?)

The three operational dimensions need to be covered with three completely different strategies.

A general strategy alone cannot cover and serve the operation of the value chain as a whole. 

This is partly because in very different fields of expertise, very different people are needed. 

For example, you might not directly involve the development team in high-level business planning tasks. You are also unlikely to involve business decision-makers in breaking down, planning, and discussing architectural issues at the team level.

Software product vendor strategies begin when I decide on the people I can count on because I have the choice, and who I have to count on because of their capabilities. 

If I don't truly (!) know the people involved that I need in order to be effective in the planning, delivery and aftercare processes, then our strategies can only be a set of dreams and desires, even if they are flawlessly worked out in professional and logical terms. Are you strategizing, or are you writing a dissertation?

The same is true for those who can be obstacles (!) in a given step. You should always discover what motivates the person who comes into contact with the delivery situation:

• When they might be obstructive
• Why they might be obstructive
• How the process might get stuck when a given situation arises

Artifacts, physical assets

In addition to the individuals involved, the strategy of all three areas of operation are fundamentally influenced by the range of artifacts to be created and operated.

These artifacts are specific, tangible items that represent independent value in any product development business environment. 

For example: Business model and lean canvas, backlogs, Kanban walls, charts, business logic flowcharts and user journeys.

The artifacts used must be interpreted and actively considered before strategizing the operational dimensions prior to the bidding phase.

Operating and refining the three operational dimensions and their associated strategy must be a routine activity at all levels!

And finally

"Do, or do not. There is no try."

The points mentioned above must be extremely well-defined. For the benefit of both yourselves and your clients.

Simply 'trying' is not enough, because in this case the client’s will almost always prevails: this is generally synonymous with short-sighted business thinking (not out of bad will, but out of a lack of specialized knowledge and experience), something that can easily leave your allies and colleagues full of frustration. 

At the same time, with a decisive attitude and well-trained professionals who convey knowledge and the value proposition from the very first moment of the opportunity to bid for the work, you have a realistic chance of educating your clients for the benefit of everyone.

A notable competitive advantage is at your fingertips ...