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.

There we go, I’m already off on a tangent. My poor brain.

You see, I said “…engineers selling…” Yep, that’s the job of the sales engineer. Don’t fool yourselves. You get paid to sell. You’re the people with the credibility. Where the sales person manages the mechanics of the sales process, it’s the sales engineer that establishes credibility and demonstrates value.

I was once questioned by a customer about a higher price than a competitor (a distributor who took my design and priced it). My response… “you pay more because you get me.” It’s a funny story, but suffice it to say that I was lucky my sales guy was on vacation that day. He would have had heart failure at my response, and he would have just matched the distributor’s price. I sold the value (along with a little humor) and the customer agreed. They purchased at our higher price.

Anyways, back on track.

I’m often asked about support for a particular platform. “How can we sell Actional if there isn’t support for platform XYZ?!?!?!?” people scream/beg/plead.

Simple. Demonstrate value first. Worry the details second.

Sure, if we don’t support any of a prospect’s platforms, it’s not a good opportunity (duh). But, that’s not going to happen. We support all major protocols and platforms. Sometimes, there’s an obscure (or not so obscure) component of the overall solution that’s missing.

Well, get in there and work with what you’ve got. Get the prospect to agree that there’s value in our solution. Once value is established, the technical details are just that. Details. Important ones, but not difficult ones.

Let me share an example.

A large CORBA customer was struggling with sporadic failures. Unable to pin-point the root cause, they’ reboot “quadrants” of their data center and the problem would go away. During the 30–45 minute “reboot” they’d have major capacity problems, but… it was the fastest way to make sure their business kept up and running. (Of course, this really just fixed the symptoms, so they never actually solved the problem… which would just keep recurring.)

So, we demonstrated the value in their CORBA environment, and quickly had “men with suits and ties” in the room looking at the solution. They were so pleased, they brought a few new problems too. Of course, these problems involved a custom written high-speed messaging protocol.

Value was established and trust was there. The new protocol was just a bump in the road. A detail. In a couple of days, we instrumented their protocol, and the rest is history.

Anyways, if you want to read a great e-book on sales enablement for other ideas on how to improve your game, check out Jeff Ernst’s e-book “The New Rules of Sales Enablement.” It’s a favorite.

In particular, I’d like to weigh in on the Savvion acquisition we just completed and my new role. But, I don’t feel comfortable doing either just yet.

I recently had the opportunity to present to the entire company during our annual sales conference keynote; a presentation that was streamed out to all our offices. I’ve got the recording, and I believe it to be appropriate to share that experience as part of my online resume/blog.

So, what you’ll hear/watch/read here is a bit about our go to market strategy and message through the charade of an executive sales call that uses a solution demonstration to convince a fictional CEO, Pete, of the value that Progress can help him and his company achieve.

The Setup

In our scenario, I was presenting to the CEO of a logistics company with the objective of getting his support to take our proposal/project to the board with his recommendation to move it forward. I had never met the CEO, but we had worked with his “underlings” prior to gather the right information and understand this company’s pains and needs.

The Delivery Strategy & What I Learned

While I was preparing, I spoke to a bunch of our top speakers and product strategists within the company, and bounced ideas off their experience. I recommend doing this… for me, as I talk about what I’ll be presenting, I get comfortable with the words, the concepts and the flow which then makes me smoother on stage. One guy in particular, Rick Kuzyk, gave me some good advice:

When you’re talking to a CEO, they delegate you to the person they feel most closely relates to what you tell them. If you start talking about technology, they’ll delegate you to their CIO. If you start talking about operations, they’ll delegate you to their COO. If you want to keep his attention, you’ve got to speak to what he relates to.

Or something like that. Rick’s one of our Power Messaging experts, and a fantastic instructor. He gave one of the best training’s I’ve ever been to, so if you’re a Progress employee get your ass to one of his Power Messaging classes!

3 other things I’d like to mention about presentation/delivery strategy:

Amount said. Frankly, this was the biggest “a-hah! moment” for me. I had 10 minutes in the agenda, but was asked to do a 5 minute pitch. I ended up at 7 1/2 minutes. I knew the 3 key capabilities I wanted to speak about, and how those would present Pete with value. I also knew how I had to show (remember, it was a demo-driven pitch) the solution in a way that highlighted those values. The three key values I chose were (1) visibility, (2) sense & respond, and (3) process optimization. The key ways to describe differentiation were (1) use their existing stuff so no major upgrades/investment required, (2) rapid time to value, and (3) highly performant/scalable even with a huge amount of information that we were sensing and responding to. I wanted to tell Pete what I was going to tell him, tell/show him, and then tell him what I told him. I wanted to use case studies to reinforce the key points, and close by asking for his support to take this to the board.

By the time I outlined that, I realized I didn’t have a whole lot of time to say all that! It doesn’t seem like a lot, but since I was essentially repeating myself multiple times (and that’s a technique you should use purposely — it reinforces your key messages and helps people know what’s important about what you’re going to tell them), I didn’t have much time at all.

Actually how little I had to say to fill that time was a really big surprise. I ended up using only one case study, but I believe it was enough. You’ll see for yourselves in a few.

Speed at which it was said. I know from competition that people always move faster when they’re under pressure. Even when you think you’re moving slow, you should move slower. So, it didn’t come as much of a surprise that I needed to talk slower, and that I would feel like I was talking too slow. I was fascinated though, when I saw the video below… my speed was really good. It looked like a natural pace. I hope knowing this makes it easier for me to be slower in the future.

Tempo at which it was said. I’m a bit of a showman. Not unexpected, I’ve been performing/competing for almost 30 years. I was surprised at how many people in the audience, when they congratulated me afterward (thank you all for your support!) chose their one comment to be about the tempo at which I presented. You’ll see me get on the stage and first just look across the whole audience. That was for me. I have a lot of friends in the audience and I knew that if I were at all nervous, seeing them would remind me where I was and that I would have their support. It also gave me a few seconds to gather my thoughts and be fully present, both of which would translate to my body language and presence.

Once I started the pause, I realized something else. I could feel the audience ask themselves the question “what’s he going to say?” Had I started right in, people would have been listening. But, by waiting, they pulled themselves in. I let the anticipation build just enough for some tension to grow… and that not only engaged them more, but lifted my energy for the delivery. I continued to use tempo through the presentation to keep the audience (and Pete) engaged, and to help them focus on the key points.

By the way, if any of my students are reading. We do the same thing in iaido. You don’t want a flat tempo when you do a kata. You need to make your enemy come alive. You do that, in part, with the tempo in which you present the kata. Hooper Sensei, as a musician, is really good at explaining this concept.

The Pitch

There was fundamentally one slide, and three components to the demo which show just as well as screen shots, as they do as point-and-click recorded demos. The slide setup the context, with the left side used first before the demo, and the right side used for the second half of the demo — when I talk about pursuing new business opportunities in addition to solving problems. The first screen shot was used for the demo around solving problems, the last two were the parts about pursuing new business opportunities. Listen for me to say something like “you’ll see that the service level delivered is the same for expedited biologicals as it is for regular shipments…” that’s the second screen shot. The third screen shot shows the results after implementing new business processes to specifically target this new business opportunity. I’ll make more sense in about 5 1/2 or 6 minutes, I promise!

Holy cow, YouTube is cool! I annotated the video to let you know which slide/screen-shot I’m talking to.

The Result

It was received amazingly well. I had a great time, but I also felt like I accomplished what I set out to accomplish. I stumbled once or twice while speaking, but I bet you couldn’t tell that the monitors in front of me weren’t working properly! You might have noticed one quick glance over my shoulder to make sure it was just my monitors and that the audience could see what I was talking to. Or, you might have noticed a grin at one point when they came back.

Forget about me though (for just one second). We accomplished our goal of demonstrating three Progress products truly integrated into a single solution with a clear message as to the value. And, the value was aligned clearly to our corporate value of Operational Responsiveness. In doing all this, we gave our field the confidence that we can deliver — even though we’ve only recently acquired Savvion.

Oh, and I got a new nickname from my new boss. I’m sure the hair had nothing to do with the fact that I’m now known as ‘Hollywood.’ It’s all about “the show” and the show must go on. I can live with that.

I remember when Microsoft’s Zune came out, Dan Foody thought it was a really nice device. I vaguely recall him saying something along the lines of it being much “better” than the iPod. “Better” meaning more cool technology stuffed inside. Of course, the Zune hasn’t really made a dent in the market.

Palm’s Pre is similar. Probably a really sweet phone. Certainly addresses the physical keyboard I know I missed when I briefly used an iPhone. It runs a lot of apps at once, and on it’s first release supports cut-and-paste. I’m willing to bet it too will fail to make an impact on the market.

It’s obvious to me why both these products have failed (yes, I’m calling the Pre a failure already).

It’s the whole product experience. What we say is that we want all the latest and greatest features, but what we do is all about the experience.

And, that is also my answer to Mike Kavis’ rant from the other day.

I kept starting to answer Mike via comments or a post of my own, but any time I started to write something I couldn’t help but feel that I sounded like a defensive vendor spokesperson. I fully agree with Mike, and hope the situation changes. There are reasons for why it is the way it is, but we’ll save those for another time so as not to detract from my support for Mike’s important points.

The take-away is that enterprise software vendors need to start thinking in terms of the customer’s whole product experience. Then, we’ll be able to make some progress.