Thursday, May 31, 2007

Surface computing - how will this help?

Microsoft has just made a major announcement that they are re-inventing the tabletop computer.

Is this a big thing? Is it new? Is it going to change the world?

First of all, what is it?
Basically Surface is a hardware product which allows the user to directly interact with a smart application system on a tabletop directly, without the need to use a keyboard, mouse or other device. The surface also is able to read, sense and interact with devices, cards, and documents placed upon it to perform various tasks.

The first applications of this are going to be in major hotels as a functional kiosk type device, to assist people finding out information. It could do things like plan your day's trip, outings, restaurants and so on, and then send them to your phone's calendar and mapping programs to help you get there.

T-mobile seem to be using it to help sell new phones. In fact the demo seems to imply that you walk into a shop, put a few phones on the surface, and it will compare their features on the screen, and help you decide. Once you decide, put your current phone on the table, and transfer all your details. Then, just put down your credit card and buy the phone.

I guess the other uses are perhaps endless, and perhaps this device can do a lot of things quite smoothly and easily.

What is the Reaction to Surface?
Reading around a bit, I have come across a few ideas from different people.

First of all, it will be aimed at first at enterprise purely from a unit cost point of view. These things will cost around $5-10K, so its obviously not a home use thing. Also you will need to start writing applications to fit your use of the device, since it is such a new thing.

Deal Architect notes that this product is already getting adopted by Harrah's, Starwood Hotels, T-Mobile, and probably others to follow.

However it will take time to see when you are likely to see this product surface in your area...

Saturday, May 26, 2007

Proof of Concept

If everything is going well, and the customer likes the product you are selling, they will probably make you come in and show them that the product does what they want. We usually call this a PoC (Proof of Concept) but it could also be anything from a demonstration to a full pilot of the product in their production system. Ideally you don't go that far!!!

A well-run PoC should have the Sales Engineer contact the customer's technical evaluation team ahead of time, and find out how the product should fit into the customer's system. From this early discussion, a series of steps should be developed that would make up the PoC. As an SE, you should drive the process here to ensure that the tests play to the product's strengths, and shelter any weaknesses you are aware of. If possible, and if acceptable, the PoC should include discussion on the final architecture, and this can even take place of some of those tests.

A colleague of mine recently complained that his customers wanted him to come on site and they would run some tests. They wouldn't tell him ahead of time what they wanted to test, or how they wanted to use the product or any other detail. This is a recipe for disaster. Depending on the customer requirements, your lab can help you prepare for the PoC with custom tools, builds, special reports, or you can even just sit down and work out how to best run all the tests. It is waste of your company's time and resources if you go into a sales situation without being able to prepare for their requirements.

The worst result of doing a PoC, is that it eliminates you from the sale, or you have to go in again to do another, because you weren't able to address the customer's main questions.
The other thing is, if you just have a workshop or planning session with a good demo system, you might be able to avoid doing a PoC altogether.

The other thing is, unless the customer is paying for the software, paying for a report, you should take your software off all their machines as you leave. Unsupported evaluation means that inexperienced users will explore your product and not learn anything about how it is supposed to be used.

Finally, the PoC is a sales tool. It can sometimes be strategic in being the first vendor to do it, and at other times you should refuse to PoC unless the customer prove that the are actually going to buy. You always should be doing the PoC to satisfy the business buyer, not just to show the product to interested technicians. It might be the business buyer's requirement for the technician to like the product, but it might not be as well (especially if the tool eliminates jobs...)

So make sure you plan your PoCs carefully, and only do them if it makes sense to you. A customer asking you to PoC should be sounding interested in your product. Otherwise, they might just be ticking a box to say they checked out X other solutions.

Wednesday, May 23, 2007

Using Visio to architect solutions

Often I have to make up a presentation from scratch. Some of you would argue that this is more of a job for marketing or documentation, but when you have to show a customer a picture of what your product will do for them, you need to be self-sufficient and do it yourself.

Microsoft Visio is often a great tool for doing this kind of stuff. However, if you are like me, and not using it all the time, sometimes you find yourself scratching around for hours getting the right sort of picture going. There are so many different tools and toolsets for getting information in and building diagrams, network maps and other cool stuff, but how do you get them working?

Luckily there are a lot of how-to tutorials online that should get you going quick. The Visio Guy links to some very helpful video tutorials, and in general he is a great resource for finding your way round the program, and programming it to do other interesting things.

I often just build a diagram in Visio and drop it straight into a powerpoint or word document. As they say, a picture tells a thousand words, and looks a damn sight better. A must for any customer response I would say, so I would use them in any of the following situations:
  • Customer Architecture presentation
  • Product Integration Diagram
  • Network Diagram
  • Roles and Responsibilities chart
  • Anything involving an Active Directory or LDAP
  • RFI responses
  • Service Provider model
And I am sure there are many other points of doing a visio presentation as well.

Thursday, May 17, 2007

RFI Time - Answering an RFI

These things sometimes seem to be the bane of my life. A big company or public body decides to buy some big expensive piece of software, so they decide they need to make it a big process for everyone to answer the demand. I usually spend the best part of a week on these documents which can weigh in at 50-100 pages.

An RFI (Request for Information) is a business process (similar to an RFP or and RFT) requesting information from vendors in solving a business problem. All of the vendors will respond, usually in the format of the request for easy comparison to give the company a chance to narrow down the selection process to the tool(s) that they might consider purchasing. Of course, once they have started the process, it doesn't actually mean they need to buy, or even that they only need choose between companies that respond.

What to do with an RFI:
  1. Respond on Time. This is the most important thing to do. If you don't respond on time, you might not be included in the process.
  2. Be Positive. Your job is to represent what you think the product can solve and present it in its best possible light
  3. Conciseness. Do not write a page when a paragraph will do. A short answer says that you know what they want. A long answer tries to answer all sorts of unasked questions.
  4. Pictures, Graphics, etc. A picture tells a thousand words. They also help skip a lot of technical jargon and show basically what the product does.
  5. Be truthful. This document will stick around for the whole sales cycle and beyond, and you will be made accountable for the claims you make.
Remember, the RFI is your 'foot in the door' but won't be enough to sell the solution. You should have plenty of opportunity to do that later.

Wednesday, May 16, 2007

Tools and Books that I aim to review

Over the course of this blog I will try to review all the following tools and books, or at least find good reviews of them already, and link to those.
  • Vmware
  • IBM/Lenovo laptops
  • Windows Vista
  • Office 2007
  • SQL 2005
  • Inside Microsoft SQL Server 2005 series
  • Solution Selling
  • google
But this blog will not be purely on technologies or tools, but will stretch to other details as well, including experiences.

Introducing... the Sales Engineer Guy Blog

Right. Every site needs a first post.

This site will basically help pass on my experiences as a software sales engineer, selling enterprise software products to large organisations, supporting salespeople in my company and channel partners.

I will try to steer clear of things specific to my company and products, and focus on tools, ideas and experiences that are more universal to all sales engineers. Hopefully, over time, I can have other SEs also share their experiences to make this site bigger than just my own ideas.