Loading...
InnovationMarketingPositioningProduct ManagementSaeed

Do you really understand the true benefits your product delivers?

By Saeed Khan

At the most fundamental level, virtually everything we do is driven by some very fundamental needs: we want to remove what pains us or increase what makes us happy.

As Product Managers, part of our job is to try to understand the reasons why people would buy and use our products (or services).

In most cases we think we know — e.g. it increases their productivity or saves them money or let’s them do something they couldn’t do before — but often its much more fundamental or specific than that.

Here are two recent examples that I came across that I want to share.

Case 1 — Increased productivity or avoiding difficult people?

A friend of mine  (a Product Marketing Manager) told me that she had gone out to visit customers to discuss her product and how those customers were using it. At one customer site, she started talking to some users about how much more productive they were by using her product.

The customer said they had created a detailed breakdown the benefits the product provided for an internal audit and shared it with her. The spreadsheet had the following columns:

  • Task #
  • Manual time spent
  • Time spent using <product>
  • Percent savings
  • Comments

There were dozens of rows in the sheet, each showing a task performed manually and automated via the software. Although the “Percent savings” column had a lot of values between 50% and 70%, some were as high as 90%! i.e. the product was significantly increasing productivity.

What caught her eye though were a number of Comments that said “Need to contact DBA”. Many of these steps had a VERY high “Percent savings” value. She asked the customer why they put those there.

The response?  Those steps required a DBA (Database Administrator) to configure, create or change something in the database. The customer also said getting DBAs to do what was needed was almost always difficult and time-consuming. A major reason they liked the product was that it eliminated the need to contact any DBAs.

“This is huge for us!” was a quote from the customer.

At subsequent customer meetings, if the issue was not raised, the PMM innocently asked about interactions with DBAs and quite often got a similar response.   Overall this was news to her, and without directly attacking DBAs, this nugget will become a key point in her product messaging.

Case 2 — Flexible reporting or time spent with family?

In another scenario, from early last year, a PM was talking to a customer (Albert) about a new release,  and in particular performance and usability improvements that had been made.  Albert was interested and agreed that those new capability were helpful, but wasn’t too excited about them.

The PM became concerned given that a lot of effort had gone into rewriting underlying code and aspects of the UI to make those changes, and users had been very vocal about the need for them. Somewhat perplexed, the PM asked Albert, why he didn’t appear that interested in those new capabilities. Albert responded that his role had recently changed to a more administrative and business focused role so he wasn’t going to be using the product hands on like he had previously.

“Fair enough” thought the PM, and then asked if there was anything he needed in his new role to help him with his duties.

Albert referenced some new reporting capabilities that had also been released and said those were what  he needed. The PM hadn’t spent much time talking about reporting as it seemed rather mundane and was basically a “catch up” feature to close a glaring product gap.

Albert’s company was in Pharmaceuticals and he had a number of monthly and quarterly reports he needed to provide to management for regulatory reporting and compliance.

Albert’s predecessor had been manually creating these reports and had warned Albert that he should expect to work late at the end of each month and quarter to get the reports completed on time.

“Tell your wife and kids not to expect you for dinner the last few days of every month.” was what his predecessor told him. It turns out the new reports provided most the raw data needed for the regulatory reports. There was still some manual labor needed, but collecting all the raw numbers was always the most time consuming part of the task.

The PM asked Albert what he would have done had the reports not been there? He said he would have found some other way to automate the data collection process, with either a home-grown system (not desirable) or from other vendors (of which there were a few discussions already happening).

The PM realized this was a big issue to promote and decided 3 things:

  • first, that the next release of the product would include reports specifically created to address Pharmaceutical needs
  • second, they had a new vertical market to start targeting and marketing to
  • they knew who to target as advocates and influencers during the buying process

Conclusion

I like both of these stories because they clearly illustrate that the drivers of the buyers or users of products are often much more personal and fundamental than we often believe. It’s difficult to get this level of detail from people. A lot of them aren’t willing to open up, and often, WE don’t engage in the right types of conversations or have the right relationships to find out.

But when we do find out, the results can be significant because we can connect with customers and prospects in ways that go far beyond the usual business rhetoric and meet strong and truly personal needs.

Saeed

Tweet this: Do you really understand the true benefits your product delivers? http://wp.me/pXBON-3KZ #prodmgmt