Market Requirement and Product Fit

In a high value technology product there are typical three types of stakeholder that have separate concerns who each ‘speak a different language’. These types of buyer are highlighted in Crossing the Chasm. The economic buyer, technical buyer and user.

When building a sales proposition and message it is common to make the mistake of trying to force your perception of benefits, which may not be shared by your customer. It is also easy to convolve messages, which may not be relevant to the buyer you are talking to, for example, focusing on price or ROI with a technical buyer.

We want to deliberately and separately address the concerns of the technical buyer and the economic buyer. We can use an interactive dashboard to capture market requirements and support the sales process from the technical buyer perspective.

Product Requirements Capture and Competitive Benchmarking – Click here to launch the product dashboard

Instead of pitching a solution to a perceived problem we can work with a technical buyer to capture their ‘total’ requirement and the key points of pain. The feature or performance space has many dimensions, for example, size, weight, speed etc. Different requirements will also have different levels of importance, some are essential and some are ‘nice to haves’. With the dashboard the technical buyer can work though the feature list and select their target requirement and associated importance. They build up a map of the total requirement, which is then plotted on a spider diagram. They can drill down in a gap analysis chart to compare specific features across multiple products.

Target real needs in sales process – Instead of ranting about ‘guessed’ requirements, you allow the customer to fully articulate their need. There will be fewer objections as you spend more time understanding the problem instead of pitching a boxed solution. As they work through the requirements and weighting you can engage them to better understand the reasoning and problem implications. For example, if speed is an essential requirement you may drill down to find that the implication of delay is under utilisation of another costly resource etc. This implication knowledge will be valuable in future sales where there are common problem sets.

Map the need to your product – There is no algorithm for sales! However if the customer builds up the map of total requirement and there is a good match with your product this can be compelling when making the decision. In addition the document is permanent; often you can bounce between objections on specific features, with this representation you keep a global focus. The technical buyer can forward this dashboard to colleagues and they will have an audit trail of the decision process.

Competitive Benchmarking – once the requirement has been mapped you can compare it not only to your own offering but also competitive products. Ideally you are demonstrating significant and compelling differentiation. Even if other products are comparable in meeting the requirement you are acting more in the role of an honest information broker as opposed to just hawking goods by saying anything. This may be valuable in building trust in the customer relationship, which is often a larger determining factor in the sales process.

Interactive and Engaging – Most people have sat through interminable power point pitches. The dashboard changes the process from a passive information dump to an interactive conversation. Also dashboards are new and different; people find them fun and ‘every little helps’ when you are trying to get the product and company noticed in the crowd.

Market Analysis – In addition to using a dashboard in a sales context they can also be used when doing market analysis. They are a lot more interesting than a questionnaire. I’ve previously described two principle uncertainties in new product introduction 1)’Likelihood of market entry’– a binary event; whether we can enter the market at all with a product and subsequently 2) ‘Market penetration and growth rate’ –the income over time for a product. The risks can be split into further levels of granularity. The requirements capture can be used to make a detailed assessment of likelihood of market entry. If your product has a very poor fit with requirement then the ability to enter the market at all is greatly diminished. For example if the ‘fit metric’ was 20% we could use this directly in our Monte Carlo portfolio analysis as the threshold for market entry. You can also spot requirement trends that can have a strong influence on the direction of your technology roadmap.

Interactive Economic Value Models – Click here to launch the value model

The language of an economic buyer is very different from a technical buyer. They use words like, cost savings, ROI, payback period, utilisation, efficiency, payment terms etc. Again we often fall into the trap of guessing points of pain instead of listening to the customer who actually feels them. We can use interactive dashboards to capture costs and metrics on the fly and automatically calculate saving, ROI etc.

We don’t talk about technical advantages at this stage; we assume we have addressed the needs of technical buyer at the level of requirements capture and we are now speaking to the person who writes the cheques (in reality we probably speak to both in a parallel fashion).

The example value model above was developed for the Lonestar chemical process monitor. A factory processing an arbitrary number of samples will have a proportion of faulty goods. If these are not detected then the faulty goods can be shipped to customers. The question is whether we can save money by employing a detection system to identify the out of spec goods. The user can input the number of samples they process and how many defects occur. They can then input the associated costs, for example if a batch of out of spec goods was shipped then there may be a direct monetary cost in refunding / paying compensation as well as potential for significant brand damage. If there are false alarms then we may end up scraping product which was actually good. The model takes these inputs and calculates the cost of not using detection vs the cost of using a detection system. They get metrics including ROI and payback period.



3 Responses to Market Requirement and Product Fit

  1. […] Requirements Capture and Competitive Benchmarking – Posting / […]

  2. […] Product selector and sales tool I’ve just posted a new version of the TouchConvert Interactive sales tool on my main site. Check it out and let me know what you think. This builds on an earlier posting on Product Benchmarking. […]

  3. Jimmy Warmath says:

    Promotion needs to concentrate on the unique selling point / differentiator of the product you are selling, so this would be promotion through media (the choice of which depends on place ie internet, leaflets, direct sales force, tv etc etc) with a strong emphasis on the reliability, durability and quality of the desk drawer slide heavily focussing on the life of the product compared to cheaper ones; a lifespan comparison could show the cheaper one to be a false economy both in cost and effort of replacement, so this could communicate it quite well.Hope this helps 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: