Over the course of my career I’ve done a variety of consulting projects as both an employee and freelancer. I’ve helped found and run a small consulting team. And, through my experience leading engineering teams, some experience of designing products and platforms. I’ve been involved in a few discussions, particularly over the last 12 months or so, around how to generate repeatable products off the back of consulting engagements.
I wanted to jot down a few thoughts here based on my own experience and a bit of background reading. I don’t claim to have any special insight or expertise, but the topic is one that I’ve encountered time and again. And as I’m trying to write things down more frequently, I thought I’d share my perspective in the hope that it may be useful to someone wrestling with the same issues.
Please comment if you disagree with anything. I’m learning too.
What are Products and Services?
Lets start with some definitions.
A service is a a bespoke offering that typically involves a high-level of expertise. In a consulting business you’re usually selling people or a team who have a particular set of skills that are useful to another organisation. While the expertise and skills being offered are common across projects, the delivery is usually highly bespoke and tailored for the needs of the specific client.
The outcomes of an engagement are also likely to be highly bespoke as you’re delivering to a custom specification. Custom software development, specially designed training packages, and research projects are all examples of services.
A product is a packaged solution to a known problem. A product will be designed to meet a particular need and will usually be designed for a specific audience. Products are often, but not always, software. I’m ignoring manufacturing here.
Products can typically be rapidly delivered as they can be installed or delivered via a well-defined process. While a product may be tailored for a specific client they’re usually very well-defined. Product customisation is usually a service in its own right. As is product support.
The Service-Product Spectrum
I think its useful to think about services and products being at opposite ends of a spectrum.
At the service end of the spectrum your offerings are:
- are highly manual, because you’re reliant on expert delivery
- are difficult to scale, because you need to find the people with the skills and expertise which are otherwise in short supply
- have low repeatability, because you’re inevitably dealing with bespoke engagements
At the product end of the spectrum your offerings are:
- highly automated, because you’re delivering a software product or following a well defined delivery process
- scalable, because you need fewer (or at least different) skills to deliver the product
- highly repeatable, because each engagement is well defined, has clear life-cycle, etc.
Products are a distillation of expertise and skills.
Actually, there’s arguably a stage before service. Lets call those “capabilities” to borrow a phrase. These are skills and expertise that you have within your team but which you’ve not yet sold. I think it’s a common mistake to draw up lists of capabilities, rather than services or products.
The best way to test whether your internal capabilities are useful to others is to speak to as many potential customers as possible. And one of the best ways to develop new products is to undertake a number of bespoke engagements with those customers to understand where the opportunities lie for creating a repeatable solution. Many start-ups use consulting engagements as discovery tools.
Why Productise?
There are many obvious reasons why you’d start to productise a service:
- to allow your business to scale. Consulting businesses can only scale with people, product businesses can scale to the web.
- to make your engagements more repeatable, so that you can deliver a consistent quality of output
- to distil learning and expertise in such a way as to support the training and development of junior staff, and grow the team
- to ensure business continuity, so you’re less reliant on individual consultants
- to reduce costs, by allowing more junior staff to contribute to some or all of an engagement. Check-lists, standard processes and internal review stages providing the appropriate quality controls
- to focus on a specific market. Tailoring your service to a specific sector can help target your sales and marketing effort
- to more easily measure impacts. Products solve problems and, when manifested as software, can be instrumented to collect metrics on usage and hopefully impacts.
Because they have a bounded scope, products are easier to optimise to maximise revenue or impacts. Or both.
A Product Check-list
By my definition above, a product will:
- solve a specific well-defined problem
- be targeted at a specific customer or audience
- be deliverable via a well-documented process, which may be partially or completely automated
- be deliverable within a well-defined time scale
- be priced according to a tried and tested pricing model
If you can’t meet at least the first three of these criteria then I’d argue that what you have is still a bespoke service. And if you’ve not sold it at all then all you have is a capability or at best an idea.
Products evolve from client engagements.
Approaches to Productisation
Some organisations will be using consulting engagements as a means to identify user needs and/or as a means to fund development of a software product or platform.
But developing a product doesn’t necessarily involve building software, although I think some form of automation is likely to be a component of a more repeatable, productised service.
You might start productising a service simply by documenting your last engagement. The next time you do a similar engagement you can base it on your previous most successful project. As you continue you’re likely to iterate on that process to start to distil it into a check-list or methodology. Ideally the process should start from pre-sales and run through to final delivery.
There’s already lots been written about lean product development, the importance of adding metrics (which can include measure product process). And also about the care you need to take about extrapolating the needs of early adopters to later customers. I already feel like I’m doing stating the obvious here when there’s a wealth of existing product development literature, so we’ll skip over that.
But I’ll also note that there’s (of course!) a lot of overlap between what I’m outlining here and the discovery phase of service design. The difference is really just in how you’re being funded.
I’d argue that taking an iterative approach is important even for freelancers or small consulting firms. Even if your end goal isn’t a software product. It’s how you get better at what you do. Retrospectives, ideally involving the client, are another useful technique to adopt from agile practices.
But productisation also takes effort. You can iterate in small steps to improve, but you need to build in the time to do that. Even a small amount of reflection and improvement will pay dividends later.
Lost Boy 