Service Management For Product Managers

In my consulting practice, I have been working a lot lately to define a service line for one of my clients.  It’s a strategic content generation service that we are packaging as a standardized, multi-customer offering. I find that it has a lot of the same high-level needs that a product might have – pricing, packaging, definition, release plan, feature/function, messaging, etc…  Seems similar – and it is, but only at the high level. Since a large portion of the knowledge economy is moving to service-oriented offerings as well as transitioning from traditional software to SaaS, I thought that more and more product managers might find themselves in a similar position.

So what are the key differences between managing a product and managing a service?

Features vs. Modules: Products have features – pieces of functionality that we spend our lives trying to tune to the users needs.  Similarly, Services are comprised of one to many modules, which are the value added actions performed to complete the services. Just as product managers have to decide what features go on the must-have list and the nice-to-have list, the same action needs to be taken for the modules of a service.  For example, if you are defining a dental service, teeth cleaning and cavity checks are must- have modules while teeth whitening goes into the nice to have category.

The Product Manager uses the same methods to research the modules as he or she does for the features: what does the customer base need and want, how will they be using the feature/module, what else is out there in the marketplace, etc… He or she should also use the same methods for pricing – the EVC of the feature or module.

That is where the similarities end.

Instead of building a feature, as you do in the product world, in the service world, you have define the module.  Defining the module is a very different process because unlike the feature, the module has to be executed each time the service is performed.  The module has to be designed in a way that is repeatable by the service provider in a cost effective way.  There are several considerations:

  • Repeatability – After you design the module, can it be easily repeatable by the service provider?  Service modules with significant levels of complexity may not always be successfully executed even thought they were defined very well.
  • Provider – Who is going to provide this module?  How expensive are they?  How skilled are they?  How motivated are they?  Defining a service module that will be provided by a highly skilled and motivated person will need to be less through than one provided by an unskilled person because the skilled and motivated person will take more ownership in the job that they are doing and require less specific directions.
  • Cost Structure – Complex modules generally have greater variability in the amount of time they take to perform even with people that have similar skill levels. Furthermore, the recipient of the module may take varying amounts of time to receive it. Using the dental exam again, people with a fear of dentists will take significantly longer to consume the teeth cleaning module. Furthermore, unlike a feature, a module that is sitting idle can be costing you money while a product sitting idle isn’t.
  • Audit Processes – Service modules may degrade over time as service providers become bored, lazy or otherwise disengaged.  On the other hand, modules may improve as service providers perform them. Your audit process needs to both ensure that the quality is up to par and quickly assimilate any “lessons learned” into the module definition. (This is similar to developing features with “iterations” except with services you are in an almost constant release cycle for element tuning.)

Sales and Promotion – Assuming that the customer is aware of the business problem and is properly qualified, you must arm your sales team with the knowledge and collateral to convince this customer of the following:

    • The defined service corresponds to the customer’s needs without significant modification. Services seem easily customizable from the customer’s perspective, but customization can drive your costs up dramatically.
    • At the end of the engagement, the defined deliverables will solve their problem.
    • Your people are skilled enough to execute it properly.
    • You are putting the proper structures in place so you won’t have to come back regularly to do the same service. unless your service is a regularly scheduled event.

Financing – Unlike a product that has to be built, a service, once defined, can be ready to perform with minimal start up costs.  It requires less capital investment overall and can be producing revenue within a few days.  Since the sunk costs are a significantly lower part of the budget, you can afford to take greater risks in rolling out a new service than you can with a new product.

However, since you can roll out a service easily, so can your competitor.  Business process patents do exist, but they are not as popular or binding as regular patents.

Product Support vs. Service Support:  Many people consider support a Service and it is, but not in the sense that I am defining Services here because you need Support for a Product or a Service.  (Think you don’t?  How many times have you asked the painter to come back and clean up something he hasn’t done right?) One significant difference that I have found though is that increasing the complexity of the service does not necessarily increase the support cost as it does with a product.  Sounds a bit counterintuitive, but the more complex the service, the higher the level of service provider (usually) which results in a deeper emotional connection between the service provider and the quality of the service.

Even outside the SaaS world, many Product Managers are now finding themselves defining and managing a service offering.  If you find yourself in this position, these concepts will help get you started without making the same mistakes I did, which should save you a lot of time, effort and frustration.