Clicky

MANAGING THE BUSINESS OF SOFTWARE

Services: The Forgotten Customer

Money 2724241 1920

Product management is about finding market-level problems systematically so other teams can solve them but professional services and support teams are often neglected. Not only should product managers look for problems that will increase sales, they should also seek out problems that reduce our operational costs.

One of my services reps came to me and said, “I have some requirements.” My first reaction was negative—I thought, I’m only concerned with customer requirements. But on reflection I realized that my services people were power-users. They installed and implemented our solution at customer locations. They surely had valuable insights.

“Okay,” I said, “What are your requirements?”

He said, “Get the damn happy interface out of my way!”

Trying to understand, I asked for details. First, the user interface was designed for novices and used lots of wizards—making it tedious for power users. And for security reasons, the services team had to install the server in a highly-secured area and do all their work at a master console. While working, managers would come by to watch, asking, “What are you doing?” or “Can you show my team what the system does?” So in a typical day, the team lost quite a few hours to nonsense.

I explained these problems to my development team. If we took out all the error checking, the basic input was a) search string, b) action, and c) parameters to the action if needed. My developer said, “Sounds like a three-column spreadsheet.”

And that’s what they built. Use a spreadsheet to profile the device, save as a CSV, import to the database, and voila! It’s done.

Implementations went from 6 weeks to 6 days. We centralized the spreadsheets so we could reuse them. Before long we had a library of spreadsheets for controlling hundreds of devices. The services team could do three or four times as many installs as before, so management was thrilled.

Faster installation, reduced frustration, a core library of device definitions. A good solution for us and for our clients.

Many product managers focus primarily on new functionality for buyers. That’s why tech debt is so often under-funded. A great product manager looks for increased capability for all stakeholders.

Consider these two approaches for number of stories per release. On the left side is a typical inside-out release profile (red=bad) while the chart on the right (green=good) shows a release schedule more in tune with all stakeholders. 

strong_release_plan

Here’s the approach I recommend. For every release, we should have at least one feature for:

  • Vision (which excites your executives)
  • Buyers (which also excites your sales people)
  • Users (which also helps the services teams)
  • Infrastructure, architecture, and technical debt (which pleases developers and services)

When creating personas, don’t forget your professional services and support teams. They have critical requirements too.

Return to Blog

Services: The Forgotten Customer

Product management is about finding market-level problems systematically so other teams can solve them but professional services and support teams are often neglected. Not only should product managers look for problems that will increase sales, they should also seek out problems that reduce our operational costs.

One of my services reps came to me and said, “I have some requirements.” My first reaction was negative—I thought, I’m only concerned with customer requirements. But on reflection I realized that my services people were power-users. They installed and implemented our solution at customer locations. They surely had valuable insights.

“Okay,” I said, “What are your requirements?”

He said, “Get the damn happy interface out of my way!”

Trying to understand, I asked for details. First, the user interface was designed for novices and used lots of wizards—making it tedious for power users. And for security reasons, the services team had to install the server in a highly-secured area and do all their work at a master console. While working, managers would come by to watch, asking, “What are you doing?” or “Can you show my team what the system does?” So in a typical day, the team lost quite a few hours to nonsense.

I explained these problems to my development team. If we took out all the error checking, the basic input was a) search string, b) action, and c) parameters to the action if needed. My developer said, “Sounds like a three-column spreadsheet.”

And that’s what they built. Use a spreadsheet to profile the device, save as a CSV, import to the database, and voila! It’s done.

Implementations went from 6 weeks to 6 days. We centralized the spreadsheets so we could reuse them. Before long we had a library of spreadsheets for controlling hundreds of devices. The services team could do three or four times as many installs as before, so management was thrilled.

Faster installation, reduced frustration, a core library of device definitions. A good solution for us and for our clients.

Many product managers focus primarily on new functionality for buyers. That’s why tech debt is so often under-funded. A great product manager looks for increased capability for all stakeholders.

Consider these two approaches for number of stories per release. On the left side is a typical inside-out release profile (red=bad) while the chart on the right (green=good) shows a release schedule more in tune with all stakeholders. 

strong_release_plan

Here’s the approach I recommend. For every release, we should have at least one feature for:

  • Vision (which excites your executives)
  • Buyers (which also excites your sales people)
  • Users (which also helps the services teams)
  • Infrastructure, architecture, and technical debt (which pleases developers and services)

When creating personas, don’t forget your professional services and support teams. They have critical requirements too.