Read Neil Ward-Dutton’s analysis for good perspective.

What we need to do is get them interested enough to take the next step.

So, in fact, we often need LESS information, and the information we share needs to be presented in a way that tells a story. A story the prospect can identify with¹ . A story the prospect wants to be a part of.

Want to grow as a technical sales person? Give yourself half the time you think you need to get your message across on your next meeting and have a go at it.

1. I know it’s bad form to end a sentence with a  preposition. Don’t worry, I’ll do it again in a second.

We’re going to see enterprise software vendors creating applications for iOS and Android. This is doing everything.

The fact it, there isn’t a corporate tablet market, there’s an iPad market.

Vendors, like everyone else, have limited people to work on products. Rather than pick one, and do it well, they’ll do everything.

Why? So they can check off that they support every platform when they respond to RFP’s. It won’t matter than each is a bland experience, partially complete because they’re splitting efforts. They can check off the check-list so they feel they’re doing their job. Nobody gets fired for creating crap.

Be bold.

Be willing to say no.

Commit to a platform, and create a great solution for your customers.

It’s as much what you do, as what you don’t do.

1. Caffeine. Tiny (and free) program that sits in your menu bar to quickly let you prevent your computer from going to sleep or dimming the screen.
2. Camouflage. Another tiny program that sits in your menu bar to quickly hide all the icons on your desktop so you don’t need to actually keep your desktop clean, you can just “toss everything under the bed”. You can even set an alternative desktop picture that’s more professional than the one you like to have while you’re working.

And, in case you wonder if these little things matter… remember, every little thing matters.

Enjoy.

Imagine that you are responsible for your company’s telephone infrastructure and are tasked with buying a whole new system. You’re given just one criteria on which to evaluate your choices, cost.

What sort of telephone system do you buy?

I’ll get to the answer in a second (this is called “building anticipation”).

There are two characteristics of typical IT staff that really impact the perceptions we have of IT. Forgive the profiling; let me remind you not to hate the player, rather hate the game if you must hate something about what I’m saying.

1. The IT people that typically come into contact with people¹ in your company often lack communications skills. They often don’t know anything about the business, and may not even really care what company they work for. They view their job as distant to the company’s mission itself. I remember I was walking around the Port of Newark designing a Frame Relay network (have you ever needed a weather-proof computer rack/enclosure?) and I asked the guy how things worked at the port. He proudly replied that he had no idea, he just kept the network up and running.
2. Non-IT people don’t understand and are frustrated by technology. When IT people don’t communicate well, these non-IT people respond with frustration and fear, which leads to them fall-back to what they know, what comforts them. Cost/benefit. Accounting. Money. “I can’t judge the value of what you have given me, so I’m going to determine it’s value by how much you spent.”

In a conversation the other day, I showed a friend a new travel website that I think has a fabulous user interface. He took a look, said he couldn’t find a flight to Hong Kong. I told him to fly somewhere else, and then made a joke that I’d be a good IT person. He knew immediately what I was talking about. This is the sort of communication that happens all the time the contributes to the frustration.

And, the answer to the riddle? Which phone system would you buy if you were making the decision solely based on cost?

You’d buy none.

If the sole criteria for your decision is to minimize cost, minimize it by not buying a phone system. Your total cost: $0.00. Job well done. [snark]

Clearly there is an implied value to expect from a phone system, and most likely your directive is to get some amount of functionality for the best cost possible. Not to minimize cost absolutely.

We all want to reduce IT costs, but still want to keep the lights on and do business. How do we do a better job at using IT to do better business? We need to reevaluate how we understand and allocate IT costs.

And, here’s the original point of my post.

The difficulty with this situation is that, if viewed as a COST center IT only owns half the “situation”. The VALUE side of the situation is owned by someone else. In English, that means, IT bears the COST of the phone system while the business gets the VALUE of having a phone. If IT is judged purely on cost or cost management, it’s not necessarily in alignment with the business’ objectives of doing more/better business.

If you want to read more about this from an IT perspective, you must read this post about how IT costs are allocated at a big financial firm.

What can we do about this? Well, in my situation as someone who evangelizes the value of technology for solving problems it’s important to pitch the right value to the right person. And, to make sure the value and cost align with my audience. I build credibility by deeply understanding my customer’s challenges. Though that understanding I build credibility. That credibility bleeds over to the solutions I propose. I’m not going to sell better by explaining my products better. I’m going to sell better by being the person who best understands my customer’s needs.

As an IT person, I think a way to get started is to work more closely with business people to break down the communication barriers. Work your communications skills, and educate your counterparts. Not so much so that people can fix their own computers, but so that they trust that you understand their business. If you can articulate their story back to them and empathize with their IT experience, they’ll trust that that the solution you provide is one that’s going to meet their current needs and anticipate their future needs.

Imagine if IT valued communications training as much as technical certifications?

Imagine, instead of having 20% of your time to work on “new and innovative” projects, IT support individuals spent 2 hours a week with their company’s people, to see and listen to their experiences?

I’m going to break this into two posts. Next, we’ll talk about a backup solution as a practical application of the value of IT not being in alignment with the cost, and how it affects us all. We’ll also look at the IT process, and see how ignoring what I’m talking about is like pumping pollution into the Hudson River. Stay tuned.

1. I abhor the use of the word “users”

Turns out, it needed a court to decide the answer.

I’m frustrated by how things are oversimplified these days. There seems to be no time for actual thinking in our daily activities — we just run at full speed to mindlessly get things done. We judge things we can’t possibly fully understand. Partly because that’s what we do (how do you feel about Obama? or Bush?). But, often it’s more mundane… like what’s the thinnest smartphone.

Well — is it the absolute thinnest point? The average thickness of the whole phone? If the average, why not the median? Or, maybe the thickest point of the phone is the measure that should be used?

Bragging rights are important to these companies. And, while it’s funny that something this seemingly trivial had to be handled by the courts when no one has a job (isn’t that the oversimplified call to arms these days?), it’s better than what I’m used to. I’m used to software companies all being the “best”, “fastest”, and the one used by the “most Fortune 100/500/1000″ companies.

As you look to improve your business. Is it the to process the most transactions in an hour? Or, to provide the highest quality transaction possible in each instance? For the former… well, the banks tried that with mortgages and look where it landed them. The latter… go buy a suit at Brooks Brothers. What an awesome experience considering how much many of us hate shopping. Same goes for Tiffany’s.

How you choose to measure things is the measure of how you succeed. I suggest it’s worth some quality thinking time.

In this YouTube Vivek Ranadive (CEO/Founder) stays tightly on message and it’s well worth watching the 3+ minute video. If you’re less of a visual person, you can read Dennis Howlett’s or Krishnan Subramanian’s writeups. Both are well written and brief. In particular, I think Krishnan is spot on when he says “they’ve nailed it for the enterprise.”

A while back I vague recall that Todd Biske posed a question… wondering if anyone had used Twitter as a public bus for messaging between applications.

That got me thinking. Using Twitter as a public bus has all sorts of problems, not the least of which is the lack of privacy.

However, using tibbr as such, with the proper governance around hashtags and @replies could be really interesting. I think we’re about to find out the answer to Todd’s question.

TIBCO’s tibbr can run privately (hosted SaaS or installed on premise), and is the first human readable integration bus.

I thought I’d share some ways that I successfully prepared for my interviews.

When I started the job hunt I knew I needed to figure out what I wanted to do. I sat down, wrote my resume, decided what I was good at, what I wanted out of this job change (which defined the type of company to look at) and what technology I was interested in. But, still didn’t think I understood what I was looking for. That is, until a friend who I was reviewing this with (I had asked for some coaching in preparation for an interview) said “it sounds like you know exactly what you want to do.” (Thanks Bill)

Once I knew what to do, and found an interview, there was a lot of preparation to be done. First, I’d just discover stuff. It’s amazing what you can find online! If it’s a software company, they probably have an annual user conference. Watch it on YouTube. Know who you’re interviewing with? Find them (and their friends) on LinkedIn. Absorb information. Just read. See what pops up.

I would write down the answers to questions I thought would be asked, or wanted to answer, and then would go over the answers. I didn’t quite memorize them, rather I embedded them in my conversation so that the key points I wanted to get across would do so (over and over again).

So, between my own questions and those I got asked on interviews that I thought were really good ones (remember, if the interviewer doesn’t ask you what challenges you, you might start a discussion by saying… “what challenges me are…” if you’ve prepared a powerful answer), here’s the list I’d use again:

Why do I want the job?

What would I contribute to the role?

How do I think the interviewer would perceive me, and how do I need to re-align or reinforce that perception to improve my chances?

How would I start? (If I got the job, what would I do?)

Why should I be selected for the role?

Why am I leaving my current job?

What challenges me?

Explain the role I’m interviewing for?

Of course, if these questions don’t come up, by preparing you can also use them as discussion points… “Mr. Interviewer, what do you think I would/should do first once I’m hired?” or “What makes a person successful at X company?”

Anything you think I missed? Please leave your advice in the comments.

In general, my opinion about Brett’s points are that the cons outweigh the pros in most every case, and that there are alternative ways to achieve the pros without invoking the cons.

I feel quite strongly that the RFP process for software purchasing is totally broken, and have an idea to replace it based on the work that some early founders of WebLayers did when I was selling Actional to them at Credit Suisse.

First let me explain why I think it’s broken. Then I’ll share my recommended fix.

1. RFP’s are biased. Typically, RFP’s are issued by companies after they’ve done some due diligence. That due diligence is “biased” based on who they spoke to, that bias finds its way into the form and function of the RFP. If all vendors have been involved prior to the RFP issue, that’s fine. But, if not… then the RFP is weighted towards those who have participated. And, that’s not always good for the consumer.

2. RPF’s only provide a partial view into what’s important. RFP’s often have hundreds of questions, some requiring complex answers. They’re meant to (1) get a complete comparison of relevant information, and (2) standardize the answers. Well, by the time a purchase is made and an implementation happens, the state of the various features will change, so knowing the current state isn’t necessarily helpful. I realize it provides a baseline, but that assumes that none of the vendors stretches the truth. Also, a simple question like “Do you support WS-Security” doesn’t have a simple answer, like “yes”. Usually, the answer is something between “no” and “sort of”… there are interoperability issues, minimum platform issues, which pieces of the standard are supported, and how the support is implemented. Second, standardized answers are not useful for a large portion of the questions… and in my opinion those are the important questions. What RPF writers really should want to understand are what makes each vendor unique, and how their philosophy around the solution aligns with the needs of the organization.

3. RPF responses are difficult to write, and even more difficult to evaluate. Finally, companies usually have a very short time to respond to an RFP making the responses less than the quality documents anyone would really like. I know it’s surprising to buyers, but the product information you would expect to be cut-and-paste is not often available. Even a prior RFP response that’s 3 months earlier is probably out of date. And, even the best “cut-and-paster” out there (I think I’m up there) is hard pressed to weave multiple cut-and-paste sources back together into a professional looking and consistent document. What about the review process? It’s time consuming and similarly biased. A grading system would certainly be unable to evaluate things like strategic alignment and uniques… and anything less is subject to the preferences of the reader… and what they happen to pick up when reading the responses. Try this. After all the responses have been read, put a simple 10 question list of features/capabilities in front of the readers… and ask them to match them to the vendors that wrote the answers. Do you think they’d remember which vendor wrote which answer?

One final point. The time/effort it takes for the teams to write the responses and the team to evaluate them all… isn’t there a better way to spend our collective time to get better technology out there faster and solve problems sooner?

So, what do I recommend?

Keep in mind that I’ve been almost exclusively at vendors/integrators in my career so admittedly I’m probably leaving some administrative/purchasing requirements out. However, I think the following makes for a great place to start.

1. Use analysts only to get a view of the landscape and make sure you know all the relevant vendors out there. Analysts don’t have the time to do much hands-on evaluation to validate what the vendors tell them. And, analysts have their own biases which may or may not align with your own. Save the analysts for when you have specific questions about relative vendor comparisons and market trends.

2. Along with a non-subjective checklist of standards and IT requirements (such as interoperability with existing systems/platforms, support in particular countries, number of SI’s trained in a product suite, etc.) deliver a set of use cases for how the product would be used. The use cases should include some long-term (and therefore less specific items) and some short term cases. The short term ones should really address the driving need for the evaluation. At least one use case should test performance and scalability in order to prove out the scaling model and help drive to a final configuration (and therefore a final project cost). Other use cases should include interoperability testing for integration to existing systems, and how the product gets migrated between development and production.

Slight aside. By checklist I mean there should be nowhere on this list to explain anything. Answers should be unambiguous lists, yes/no, dates, numbers, etc. This keeps it black-and-white. If it needs an explanation, it best to have the vendor answer in the context of the use case.

3. Ask vendor participants to fill in the checklist, give “essay” answers to the use cases, and then provide 10 items that they believe you should evaluate as part of the evaluation. These 10 items will be all you need to understand how each believes they compete with the other vendors, the vendors’ philosophical alignment to the problem space, and their unique value propositions. By the way, these 10 items should include use cases on how to test them, and an explanation of why they are important to the proposed solution. Of course, these 10 items might be non-technical… like they might be about standards support, or SI relationships, or whatever the vendor thinks is important.

I believe if we moved in this direction, we’d have a process that got customers what they need, faster, with higher quality results. And, the efforts used in the decision process (by implementing the use cases in a POC) would be directly relevant to deploying the solution, so once the process is complete, you’ve done more than selected a vendor, you’ve begun your implementation.

This big bank he visited had no idea who Progress was. They were a customer of OpenEdge, DataDirect and Sonic, and there was a big Apama deal on the table. We were late to the deal, and didn’t have the strategic relationship with the bank that we should have had as a long term technology provider. A relationship, I might add that was critical to beating some of the smaller startups competing against Apama for the business. Chris was frustrated that there were four sales teams in at the bank, none of which showed a whit of interest in working with the other.

Tons of reasons, obvious to anyone at Progress, as to why that was the case.

Just 8 months later, I’d like to share an experience. The experience was fittingly my final Progress performance.

I visited a customer in Dallas who is a long-time OpenEdge customer. I went with the account manager and his sales engineer. The account manager is a long time Progress employee from the Sonic/Actional business. The sales engineer, an old hand at OpenEdge development is now working selling the components of RPM and DXSI. I’ve seen him in accounts and had no idea he had an OpenEdge background until he told me. He competently positions and leads POCs around Actional, Savvion, and DXSI.

The informal discussion before the meeting started briefly covered Sonic, and the customer’s interest and experience with ESB’s. Then, we had the OpenEdge product team join on a Webex, share some new technology and roadmap… Actively showing this prospect that OpenEdge technology is alive and well. Based on the number of people that joined from the team, it was clear it’s also important to us.

Interestingly, there was a gentleman from the DataDirect side of Progress who has taken on a larger role in OpenEdge product management. Able to give some perspective on Progress from that perspective. Then, we were joined by someone from our indirect team, along with an OpenEdge partner whose product this customer used. Progress are taking an active role in participating in this relationship between partner and customer to get closer to the business problems and help execute. It was great to see the Progress direct and indirect account team members collaborating this way.

The customer now has a single account manager across all these products and aspects of our relationship, a feat that would have been unheard of 8 months ago!

The customer had joked earlier that no one has ever heard of Progress, but that recently a vendor who they selected for compliance had committed to supporting the Progress database. Would we like an introduction? You bet! Could this be a sign that change is in the air regarding their market presence?

Finally, I delivered the Actional message. Interestingly, the customer started me off by saying “Actional’s been around a while, hasn’t it?” I gave the whole 20+ year history of the VisualEdge and adapter technologies, the evolution to web services / SOA, the Westbridge merger that added a deep security core to Actional’s SOA Governance suite, followed by the Progress acquisition and all the fun that entailed (You’re part of Sonic. You’re not part of Sonic. Wait, you’re part of Sonic. No, wait…), ending with the evolution to RPM both as important to the market, and to the evolution of Progress.

It was amazing to give this story one last time. And, to give it in a context that so demonstrates the changes that have occurred at Progress under Chris’ leadership.

The changes that are occurring are exciting. I wish my friends the best of luck with the new Progress. It’s a small world. I say that with great authority having worked in 26 countries, including delivering the first Actional deal in about 8 new countries. (I swear this is true… I once got on a plane, and the stewardess said “hi David, oh, you got a haircut. Looks nice.”)

Thanks for the experiences, the friendship, and the inspiration. It was my greatest pleasure.

Peace.