mike.trachta

Earlier this week I asked for opinions on what makes a good technical sales person.  Now, I’d like to share mine.

I’ve been lucky in my career. I’ve worked with terrific sales people, and had very few occasions where they made a promise we couldn’t deliver on.  Here are the things I think they’ve done well:

1. They communicate with Implementation (and possibly Support) during the sales process.  This is particularly important if they are new to the company, or the product.  If there is something they are unsure about, they should always check with Implementation/Support before agreeing it can be done.  This also includes handing over any information they may have already discovered.  Customers hate being asked for the same information twice.
2. They set customer expectations.  This really just boils down to the fact that they don’t make promises the delivery team can’t deliver on.  They give of an overview of the implementation process as well as the philosophy behind it.  This lets the customer know exactly what to expect at kickoff.
3. They aren’t afraid to say “no”.  This goes back to setting expectations, and not promising something that can’t be delivered on.

I also want to add one more thing that isn’t really a quality of the person.  As Rod pointed out in his comments, a technical sales person should report to services rather than sales.  This keeps his/her interests aligned with services, and thus, helps ensure they strive for sales that lead to successful implementations.

Are there other things to add to this list, or maybe some things you don’t think are as important?  Please leave any feedback in the comments.

Tweet This Post Digg This Post Facebook

mike Uncategorized

I posted last week about how POCs can make life difficult on the engineer responsible for implementing a solution.  This got me thinking not just about POCs, but also about the person who makes the sale.  I started wondering, “What makes a good technical sales person?”.  I want to look at this through the perspective of services, rather than from the typical revenue perspective.

Obviously you need people who can close deals and bring revenue to the company.  Any technical sales person should have technical aptitude, and be honest and personable.  What other qualities should they have?

Please leave your thoughts in the comments.  I’ll post my opinion later this week.

Tweet This Post Digg This Post Facebook

mike Uncategorized

My friend Ashraf Motiwala brought up a topic I’m very familiar with when he explained Why (most) Identity Management POCs Suck.

To give a brief overview, a POC (Proof of Concept), at least in my experience, basically consists of a sales guy, and a sales engineer.  They spend a couple of days with a client, and build a solution to prove they can integrate with the customer’s technology.  Ash came up with 3 major complaints:

1. A typical POC is just a glorified demo.
2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy
3. A POC is typical technology focused. Most IdM deployments are business process centric.

I have a 4th and major complaint, coming from the point of view of a integrator who must implement the solution after the deal has been sold:

POCs typically stretch the system to its technical limits, and are able to do so because they are built in a very controlled environment.  When it comes time to scale, the demoed solution won’t work. This leads to unreasonable expectations.

This can create a lot of problems for the consultant/engineer implementing the final solution.  I consider one of my most important jobs to be managing the customer’s expectations.   A typical overly elaborate POC make this job extremely difficult.

The sales folks may not realize it, but the customer remembers more about the POC than you think.  They remember how pretty the screens were.  They remember how seamlessly all the pieces fit together, and how quickly each task executes.  What they don’t realize is that all of the data is massaged and simplified.  Of course the POC could do these things!  It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment.  When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex.

Has anyone else had bad experiences due to a POC?  If so, let us know by leaving a comment.

Tweet This Post Digg This Post Facebook

mike Uncategorized

Here is the definition, according to Wikipedia:

Identity management is the management of the identity life cycle of entities (subjects or objects). An identity management system:

1. Establishes the identity
   1. Links a name (or number) with the subject or object;
   2. Re-establishes the identity (i.e. links a new or additional name, or number, with the subject or object);
2. Describes the identity:
   1. Optionally assigns one or more attributes applicable to the particular subject or object to the identity;
   2. Re-describes the identity (i.e. changes one or more attributes applicable to the particular subject or object);
3. Destroys the identity

I also got a couple of comments from readers, including:

You help businesses be sure they know who is doing what with their computer systems.

and:

*Streamlining all user accounts (anyone who has 10 sets of ids at their workplace can relate to the benefit of this)
*being able to do a master reset on pw (save IT staff time)
*Being able to disable all accounts in one shot thus securing data from those who no longer should have access

Putting it all together, I’ve come up with the following pitch:

Identity Management solutions allow an organization to control and audit what its users can do.  This includes creating accounts for users when they are hired, modifying their accounts as they change jobs within the organization, and terminating a user’s access when they leave.  It also allows users to synchronize their password across the various computer systems they have access to.

Is there anything important I may have left out?  Is it simple enough for someone who isn’t technical to understand?

Tweet This Post Digg This Post Facebook

mike Uncategorized Identity management

It’s time to really launch this site and get blogging about Identity Management.  To get things started, I’m trying to come up with a good elevator pitch for Identity Management.  Too often I have to explain both what I do, and the industry I’m in.  No matter what I say, as soon as I’ve uttered the words “Identity Management”, folks assume I work for a company that helps prevent Identity Theft.

Any thoughts on a good pitch?  Put it in the comments.  I’ll post what I come up with on Friday (and I might even “borrow” from some of your comments).

Tweet This Post Digg This Post Facebook

mike Uncategorized