Selling a new product

This is a short distillation of stuff I'm trying to ensure I do as I launch a new product.

How to Sell (adapted):
1. Know your customer. Understand his personal (secondary) buying motive. ie what he really seeks from the product or service. Ask questions and listen to the answers.
2. Sell the features, advantages and benefits that relate to what the customer wants.
3. Be aware of the psychological steps that buyers go through and how to deal with them.
4. You need a) Empathy, so that you can understand customer needs. b) Confidence, so that your can bring customers to the point of buying, and c) Resilience, so that you can use rejection and temporary setbacks as spurs that constantly move you forward
5. Be honest and available. Sales are about relationships and relationships are about trust.
6. Plan for the possible objections.
7. Make it easy to buy.


Some of this doesn't relate to me but perhaps more to the website or the product. I am a stickler for simplicity. When it's simple it's usable and has less trouble. For usability it needs to be lightweight, with few options all of which are labelled clearly. To some extent this is a carry over from designing tools offshore. I listened to the complaints about existing tools, agreed they were indeed correct, noticed where they could be designed a lot better and made sure my own products did not have the same defects. It's most gratifying when the users of the tools say something like "this tool is a heck of a lot better than the last one we had".


I'm aware of course that others like complications but I'm thinking they are the kind of people who will buy the big name products, where you might know what you want but you can't a) find it in the interface, b) use it after you found it because you didn't do 3 or 4 previous steps correctly. If you don't know what I'm talking about then you clearly haven't used Ansys Workbench!


Now the reason some buyers/users value complexity is presumably the assumption that they are getting more bang for their buck. So if the buck is less maybe that would overcome that difficulty.


Then of course you get into the canard of "you get what you pay for". Well there is no way around that other than to target your audience. People may criticize Alibre for price reductions, just like they criticize Ryanair for cheap flights but if the sales are there then clearly it's just snobs or vested interests who are worried about buying something cheaper. Most of us here in France just love Ryanair because they provide a service that is convenient, unique, quick and fair. Their separations of the charges are a pain but clearly they are used to bring customers in the door. I think that's what I'm aiming for. The pricing issue is a problem that will sort itself out only by testing, in the way that Alibre just did. Having added 10,000 users at 100 dollars a piece it was an interesting million dollar gain as well as an experiment.

It should also be robust. Two things I made sure of with FEMdesigner after bad experience with other FE software were a) Keep a readable text file because binaries get corrupted easily, and b) if it ever crashes make sure these files are not affected. Potential crashes can be found by beta testing. What I'm discovering - the biggest headache - is that these crashes come almost exclusively from 3rd party issues so I'm trying to keep it simple regarding using the graphics card, threading and the like. Anything too new or controversial will fail. Currently I'm sorting out a deadlocking problem because I need a worker thread to overlay my plots on the host viewport but if the user or the operating system causes a refresh message on the other thread then everything freezes. It took me a while to discover that one and I've still only half-fixed it.


Update - fixed it: Confucius he says "Use too many threads and deadlock is your downfall".

Sphere: Related Content