Professional services is the next challenge for product management. In many companies, definition of services is an ad hoc affair, nothing more than a rough guess of man-days committed in a contract.
In too many companies, the Professional Services Organization (PSO) fills the delta between what Development built and what Sales sold. Typically, the sales person concedes a certain number of man-days (or person-days, if you prefer) as part of the contract negotiation. The PSO team often ignores most of the information from the sales team and spends a few hours or days identifying the real requirements for this specific implementation.
For some, services are one-off development. Knowing they have PSO, developers and executives sometimes rely on these reps in the field to finish the product onsite. Maybe it's easier than finalizing the installation routines. Maybe we don't know what the market really needs so we build a set of tools instead of a finished solution.
Another problem is that some companies turn to services when Development isn't responsive. The product release cycle takes too long, or the features required for a particular client aren't available in the current product version. Some companies even divert developers to services work where they are billable. This throws the product into a dangerous tailspin: limited resources means longer development cycles with fewer features, requiring more development work in the field.
We're making the same mistake with services that companies in the past made with software. Instead, doesn't it make sense to define consistent, repeatable services?
Development and Product Management are about serving entire markets instead of individual clients. The best approach is to think of Professional Services as a development organization. PSO uses onsite man-hours instead of a compiler. The trick is to deliver the same thing in every similar engagement, leaving room for customization.
Sure, you could make 10% on a one-time contract. Some companies consider this an acceptable return on their investment. But you could make a 1000% return by delivering the same service to 100 clients. Field people will tell you that they do the same basic installation and initial implementation in every client. Don't you? When you're helping someone with their computer, don't you set it up the way you like it before you even begin doing the hard stuff?
Start with understanding the industry problem. In onsite calls, the product manager will identify customer problems, and write down the problems, just as one does with software. Call on a few every month and build a folder of call reports. Each call report contains multiple problems that we could potentially solve.
Define the personas and their problems. After a few onsite visits, a product manager can identify the key personas for your solutions, and the problems that you need to solve. These problems drive the market requirements document. You must filter out the services that do not leverage your tools or your distinctive competence; leave these services to the generic consulting firms. Don't cripple the definition process by presupposing software, hardware, or services--this decision will occur later in the planning process. (Remember, implementation is in the specification, not the requirement. For more, see the article On Reqs and Specs.)
Review the Requirements . With the list of problems in hand, have a team meeting of Product Management, Development, and Professional Services. Discuss how to approach the various customer requirements. Product managers often see software features when the right solution may be professional services. The developer may instead see that an onsite service makes more sense. Or perhaps the PSO rep has already done some similar work onsite that can serve as a basis.
Identify key resources. For those problems that require onsite account understanding and customization, identify the people in your services organization who can best address these problems. Discuss the problems that you've encountered and ask that they create a specification. The PSO expert is serving as the product architect, a 'thinking' role. This person may want to collaborate with others in her organization or leverage some work from a prior implementation.
When considering the list of services, the problems that we do not currently have resources or skills to solve become training or hiring criteria. We know the clients have the problem; we've determined that the solution is a service. Now we have to build the skills internally to deliver it. The PSO executives can identify people who can teach themselves the skills to deliver the service, or initiate a job search for a person who can.
Package for repeatable sales. With the services defined and staffed, the product manager or marketing manager can package them for sale. With understanding of the persona and the problem, the product manager defines pricing based on the problems, and creates positioning documents to drive sales sheets and other collateral. With repeatable services defined, sales people should never have to sell 'off the price list.' Everyone agrees that it's generally bad when sales people make up stuff in the field.
One company saw incredible results when approaching services in this way. After identifying the problems for their various buyer personas, they defined 26 different, repeatable services. They assigned a product manager to oversee the creation and launch of the new services. They created sales sheets with explicit statements of what the service entailed. They created standard pricing for each service. The president launched the new approach for services to the sales force by announcing, 'Effective immediately, all contracts require services; our software is optional.' Their professional services sales quadrupled in one year! The sales team knew what to sell. The PSO team knew what to deliver. The service was priced at a profit for the company. What a difference.
Think of your existing products as building blocks for professional services, tools that they use to realize the implementation for the customer.
As someone at Black & Decker is purported to have said, 'Remember no one wants a drill bit; they want a hole in the wall.' Your customers don't want your software tools; they want an implemented solution. Software, hardware, and services in combination may be required to realize that solution.
Pragmatic Marketing, Inc. has continuously delivered thought leadership in technology product management and marketing since it was founded in 1993. Today, we provide training and present at industry events around the world, conduct the industry’s largest annual survey and produce respected publications that are read by more than 100,000 product management and marketing professionals. Our thought-leadership portfolio includes the Pragmatic Marketing Framework, eBooks, blogs, webinars, podcasts, newsletters, The Pragmatic Marketer magazine and the bestseller “Tuned In.”
To learn more about our courses and join the growing international community of more than 85,000 product management and marketing professionals trained by Pragmatic Marketing, please click here.