From Service to Product?
You offer a service that relies on data as well as knowledge and results in an valuable asset. You think that there is more than one customer for the resulting work. What does it mean to become a product organization instead of a service provider?
Sometimes the difference between a product and service can be subtle. To illustrate a point, I went to the Meriam-Webster dictionary on-line and looked up “product” and “service”. For product, these are the definitions that I found:
- something produced
- something (such as a service) that is marketed as a commodity
Whereas for service I found:
the act of serving: such as
- a helpful act
- useful labor that does not produce a tangible commodity(these are just a few of the entries)
The word service is in the definition of product. To me, this points to an element of subjective opinion as to the difference between the two.
In the context of this article, I see service is a one-off offering of know-how that is specific to the problem that the customer has. Typically, service is the result of a significant manual component; the deliverable to a customer is tailored to their unique situation by a human being who applies their expertise and judgement.
When I think of a product, the output is the standard offering where the bulk of the customization is offered via a limited range of configurable options. Automation with limited self service. (Some customers think they are getting lots of configurable items, they just don’t appreciate the depth of what’s going on under the hood.)
This point of view can be applied to software, data, and more tangible objects such as clothing, furniture, etc. The carpenter provides the service of creating a custom chair whereas the chair at the big box store is a product, no questions.
Why is this concept inherently more difficult in the realm of products that increase an organization’s decision power? I think part of the challenge lies in the reality that we are more comfortable allowing machines to take on the task that we view as labor intensive, such as lifting and assembling but we are less comfortable automating things that we associate with logic and know-how.
Where am I going with this? When a company decides that they are transitioning from a being service provider to offering a product, often there is reluctance to consider that some things don’t need constant human intervention. Part of it is pure nostalgia, in my POV. But to offer the original component, like a report or data, on a much larger scale with more breadth to more customers means hard choices. Like questioning how something was done and being willing to do something different.
Let me be specific. One-off ways of working can deliver when you know you have a person scrutinizing every step. This may get the job done for a single customer but it will not scale. Consider some data science script that is required to generate the report. If it is created from an inconsistent data source, without automated normalizations and error checking, with human interactions every time it is run, then you need significant human interaction and skill with every delivery. In this scenario the customer is really paying for labor.
During the transition to product, investing in the correct infrastructure is often overlooked or downplayed. But, the infrastructure is key. Creating products inevitably requires some level of automation. Product companies that started as service providers can struggle with thoughts of “we succeeded without it”, “what’s that all going to cost me?”, “the human creativity is more valuable”. When I hear this, I want to ask “Do you actually want to change to a product company?” Half measures will lead to unsatisfied customers. Why, because how are you going to deliver at scale, be reliable and do it with a quality without infrastructure investment.
I am not suggesting that we automate everything. We need to keep the human in the loop, but let’s do that for the decisions and tasks that make sense.
I struggled with the title of this post which is the reason for the question mark. I was tempted to title it “From Manual to Automation’’ but given this is a product management blog and my most recent experience is on the software side, it seems that automation would be a given.