Many software development firms pride themselves in being able to tackle almost any software task. They elicit requirements, or build prototypes, and code databases, business logic, algorithms and user interfaces without any particular market or industry focus.

Those firms produce bespoke software solutions to solve unique client problems.

But almost inevitably, they end up specialising. It may just be that they are so much more credible when bidding for work in a particular segment. Or it might just be that their capabilities are more in tune with one industry than another. Either way, specialising generates more business and more profit. It feels right. It’s evolution.

Those software development firms can, of course, specialise without developing product. But again inevitably, their developers will re-use bits of code, libraries and modules. Product of sorts will emerge, albeit without central direction.

So, often, bespoke software developers won’t remain bespoke for long.

Managing productisation

There are reasons why firms across business develop product. From the market side, client needs tend to standardise as each market matures – all firms selling motor policies have similar needs, and so too do all dentists booking client appointments and keeping records of treatment.

This trend of productisation occurs throughout history. Early cars were bespoke creations until Henry Ford came along. And now we only have a few different marques, each selling a few models.

The customer benefits hugely from productisation. Only the very rich could afford custom cars, but the Model T was affordable by many households. As markets productise, volumes increase and costs reduce dramatically. For customers buying software solutions on stretched budgets, they get more product for their money than they could ever afford by asking a software house to develop something bespoke.

For the developer, productisation enhances quality, cuts costs and reduces the required skills and knowledge needed to sell, develop and implement the solutions. Of course, the revenue per order drops, but generally the overall market grows, growing the productiser's turnover.

If it’s right to sell bespoke solutions, the client must be prepared to pay for it. Systems like the UK’s Passport Office solution or the failed e-Borders system are examples of such bespoke solutions. But in the end the market price for all goods and services reduces as competition rises, demanding that all firms specialise and productise.

The issue then is how producisation comes about. When should a firm choose a productising strategy – and what changes should managers make to successfully accommodate this new strategy.

Degrees of productisation

The difference between a bespoke and a product strategy in software (and indeed in many other businesses) lies in the definition of ‘product’. A firm has a product strategy where re-use is high and there’s common function between solutions for individual market segments. At one extreme in the product strategy greyscale, re-use is so high that everything the firm sells is the same – described as commercial off-the-shelf (COTS) or 'shrink-wrapped' in some markets. In the middle, there's the other productisation milestone: re-use as a method of cutting costs and core software is then modified or customised for each client. This gives us the notion of modified off-the-shelf or MOTS.

In moving from bespoke to MOTS and ultimately COTS, the people needed in the firm are very different.

New roles under productisation

In bespoke software, the client will generally have a very clear view of what’s needed and will direct the developer, at least in the user requirement, if not in the functional requirement and implementation. In a product scenario, someone must take the role of all clients. In product strategies, someone must act as Product Manager.

Product management is a big role, defining what’s to be developed and sold in sales, marketing, software development and support.

As soon as a firm focuses on one market segment or other, it must harness a source of knowledge to secure its competitive advantage. This demands an advanced development arm that is close to the universities and embraces new techniques and methods. The firm must hire a few highly intelligent, competent engineers who can provide the necessary technology leadership.

Those Technology Managers will determine a common architecture that fits the market and the degree of specialisation wanted. And they’ll select the parts of that architecture that the developers will code and the modules that they’ll buy in from other specialists. Ultimately, in conjunction with the Product Manager, they’ll determine where on the ‘COTS-MOTS-bespoke’ spectrum the firm will lie.

And of course, someone has to sell the product. This requires someone steeped in the client’s business but perhaps with little competence in software development.

And for the rest

Having increased competencies in markets and technology to provide direction, there’s less pressure on the developers themselves. For them, the situation is similar to the bespoke state where they are told what’s needed. Developers can get on and do what they’re good at. Typically, there are special techniques in test now, embracing automation to exploit the common ground between solutions and there’s a new role in support. But overall the back end of the firm is as it was.

Summary

Software development firms trading in bespoke solutions today will inevitably specialise in one or more market segments. With that specialisation comes some fundamental changes in leadership. The firm must develop or hire a technology specialist to lead engineering methods and a product specialist to determine, on behalf of future clients, what’s to be developed and when.

If you’re thinking on specialising and adopting a product strategy, call us. We’ll be happy to discuss what you’ll need.