The Service–Product Feedback Loop

By Matt Kuckuk, Senior Executive Consultant, CGI - January 30, 2012
Share this

The Service – Product Feedback Loop

As Professional Services leaders, just about all of our time goes to keeping the customers satisfied, the staff productive and the numbers on target. There’s another crucially important aspect of our jobs though, that’s always there somewhere on the priority list but doesn’t always get as much attention. That is the need to capture the unique experiences of the services team in the field, and turn it into useful knowledge that the rest of the company can benefit from. Let’s call it “knowledge feedback” for short. 
 
Knowledge feedback is a prime example of what Stephen Covey in “The Seven Habits of Highly Effective People” calls a “Quadrant II” task – it’s always important, but it’s almost never urgent. It’s especially important in companies whose main business is making and selling products, and who have a services division as well. That’s because the services team sees first-hand how the products work in the customers’ world, what customers like and don’t like about them, and what needs to be done to get as much value as possible from them. Because of that, some enlightened Product groups consider Professional Services to be an extension of the customer base. It’s generally true that: 
 
The services team’s view of the products will be the closest to the customer’s own.
 
Consider a start-up company making, say, a new software product that will revolutionize e-commerce security. Product Engineering develops the product to the point where the first customer can implement and start to use it. With help from the professional services consultants (often side by side with engineers), it eventually goes into production, and Engineering goes to work on Version 2.0. As do, they talk to the people who worked with the first customer to find out what most urgently needs to be added or changed.  The experiences of the team who worked on that first set-up will be invaluable in the effort to make that next version as powerful as it can be.
 
Startups often do this kind of knowledge feedback quite successfully -- and informally. It’s easier when you’re a small firm and everyone knows each other. In more mature companies there is still a great deal of value to be had in capturing field experiences, but more “process” will be needed to make it actually happen.
 
On top of what the consultants observe, there is also a great deal to be learned from the nature of the projects themselves. In essence:
 
In the pattern of services engagements, the market is telling you what it believes it needs to pay for to create a complete solution based on your products. 
 
That suggests the other major type of information PS can feed back to the company – project characteristics.
 
When I was the head of services for an established enterprise reporting software company a few years ago, we started out with no regular forum for this kind of discussion. What triggered us to start was a visit to my office from the VP of Marketing. He asked a simple question: “What do customers use our products for?” Don’t be startled that he didn’t know that already -- we sold an infrastructure product – basic technology that could be put to work in a wide variety of ways -- and customers usually didn’t tell us what they were going to do with it. Except when we had a Professional Services engagement with them.
 
Back to the meeting: I was surprised by his question, but promised to get as much information as I could together before the next time we met.   After talking to the senior leaders on my team we decided to designate each of the hundreds of projects we’d done over the past year according to what general area of business applications it fell into – for example, financial analysis, sales tracking, balanced scorecards, or reports for customers’ customers. We then tallied these up and found that five application areas accounted for over 90% of all projects, with 50% of the projects falling into the top two categories.   It was the same when we weighted by dollar value.
 
When these results were shared with the VP of Marketing, he decided to change one of our marketing campaigns to a “business solutions” theme aligned with the top two application areas, to generate demand by highlighting our strengths and references in those areas. The second impact was in product direction – enhancements that had particular value in the top application areas were moved up the priority ranking. 
  
The third major impact was that it led us to set up a regular, and pretty structured, feedback process to get more information from the services world to the other groups in the company.
 
From this experience, and others since then, my advice on setting up the most effective feedback loop can be summarized as 5 “C’s”:
 
  1. Categorize  the kinds of work you do for customers
  2. Code this information in your PSA system
  3. Capture  it for each project, plus observations and insights from the consultants
  4. Collate – summarize it in a report
  5. Collaborate – hold a periodic meeting with Marketing, Product Management, Sales and leaders from other groups as appropriate to your situation, to review and recommend action.
 
It will take some thought and brainstorming to come up with the right ways to categorize projects in a meaningful way for your situation. One size definitely doesn’t fit all here. A few general categories to get you started are: business applications, types of work, customer types or industries, products used, and partner involvement. It’s also important to capture observations and rankings of enhancement by the PS staff – that turns the feedback from the field into hard facts, separate from project statistics.
 
Here are two simple graphical examples of project statistics and feedback:
 
Projects by Business Application Area
 
Enhancement Requests by PS Staff

I’ve found that this objective statistical information is a major contributor to the success of the process. Without it, there’s a danger that the feedback will be perceived as just opinions about product gaps, which is not as productive.   There’s nothing wrong with leavening the mix with good anecdotes from the front lines – sometimes a well-told story brings a point home better than any dry numbers could.
 
One more point. I often find at least a few people in the services team who believe that they should keep any information and experience from their projects to themselves, because they think that means job security. To me that’s the wrong way to look at it. The more useful insights go to the product team and end up improving the product, the more successful it will be in the marketplace. The better the product does, the more the company will grow. The more the company grows, the more opportunities there will be for smart, customer-focused, and collaborative services people to grow with it.