04022 New Features Won’t Solve Business Problems

Companies that make software have one big strong point: they know how to make software. They know how to build all sorts of cool features that work in amazing ways. And when they do that, they create businesses that succeed.

But the problem comes when this strength at making new features is not rounded out by other strengths, such as good marketing, delivering compelling demos, strong salesmanship, or good consulting.

The management team at a software company may be too used to solving problems by developing features in the software. This can lead to expending effort to develop capabilities in response to problems that are actually solved well outside the domain of software development.

Product Managers are uniquely situated in positions whose responsibilities span both technical and business functions at a company. This placement means that they can serve as the conduit that directs the team away from a time consuming technical change and towards a business solution.

Read on below for some examples where the correct response is not a development effort but a business solution.

[private]

Delayed Features vs. Better Demos

Software is a product that is always in the process of being improved. Most people see a software product as a very fluid thing, where it seems like new features can be created effortlessly. And when there’s a long list of planned features, it’s hard to be clear about what’s already in the product and what’s not.

And unfortunately, the tendency during demos is to talk up future features. After a prospect has heard a couple demos, it’s not surprising if they begin to get confused about what’s there today rather than tomorrow. And that’s when the confusing questions start. Questions that result in tangled answers that include words like “delayed” and “not ready yet.”

The next thing that happens is that an astute and motivated salesman at one of your competitors gets wind of the discussion and begins spreading the word about delays and missing features. And it’s all very unfair.

Well, the solution to this is definitely not to develop more features faster. The solution is to be very disciplined about how the capabilities are presented. The presenter needs to be rock solid about all the features that are there today. Next, it must be crystal clear that future abilities are arriving as planned and on schedule, not merely in some vague tide of uncontrolled delays.

More Reports vs. Selling Better

In most software applications, reports are where the value of the product hits home for top managers and executives. It can be a very important consideration during the product evaluation.

There is also an almost boundless need for information, and if you get a group of managers at a prospect started, they can come up with a list a mile long of the reports they want in the software. Your product’s three dozen standard reports in five categories can quickly seem paltry by comparison.

This is where a good sales rep needs to do his work, setting expectations, letting prospects see the possibilities while keeping them grounded in reality. The rep needs to make it clear that the standard reports will get the team much of the way to where they want to be, and in addition, with a dedicated effort to master the report writer (most likely a third party one), they can develop their own customized reports.

A Copy Button vs. Good Training

We all know how convenient it is to have a Copy button to save data entry time by quickly copying a record, not to mention cutting data entry errors. But that’s also a feature that frequently doesn’t make the first version of a new module.

A good trainer, however, can provide a great tip: Export the record, then import it, giving it a new name when you do, and you have the equivalent of a Copy button, a whole year before the official button is available. In this case, it’s good training that solves the problem.

A Tabbed Interface vs. Astute Consulting

When a company begins to build a library of, say, campaigns in a CRM application, the list can build quickly until it becomes hard to scan, with much time lost searching for the right campaign. It can become a jumble of names that nobody can easily navigate. And it just keeps getting worse over time.

A development-based solution would call for the ability to create a set of custom-named tabs, or maybe multi-level categories, to organize the campaigns. But astute consulting will help the implementation team develop a naming scheme, perhaps with an initial number, that neatly organizes, categorizes, and sorts all records. The list of campaigns is now easy for the whole team to understand and move through.

Not that multi-level categories is a bad idea. But providing categories is no guarantee that a company will use them wisely, without good guidance. The solution in this case lies in the consulting.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]

Comments are closed.