Eventually the Enterprise Irregular discussion I posted about earlier wound its way around to asking, “Why must this development be so slow for conventional enterprise vendors?”

One Irregular opined as how it was due to wasteful R&D. That waste being due to:

– Too much emphasis on derivative products

– Continuing old assumptions/processes even though newer technologies exist

– Continuing to re-invent the (stone) wheel instead of challenging all of the old assumptions.

– Doing development only at the margins. Adding a tenth method of allocating a general ledger balance will not re-order the competitive landscape for anyone.

– Thinking that R&D spending should be tied to market size, market share or some other proxy that is irrelevant. The effort should be one that is relevant to the effort being planned and must be one that shareholders will get value from.

These are all classical problems for large company product development that I quite agree with. Just to amplify on a couple of the points:

I recently took a new position but interviewed with many firms that were firmly stuck some ways back in the technology world. These included extremely large organizations for whom C++ was a relatively new and not yet often used tool. Needless to say, most of the problems there are self-inflicted, and given the proclivities and mass, are so institutionalized as to have ossified into a nearly impenetrable mass.

Reinventing the same wheel is extremely common. Even among SaaS companies, most are focused on doing the same thing their client server predecessors had done only via SaaS. Relatively few have innovated very much on that theme.

Doing development at the margins is a common outcome once the visionaries have been separated from the project (if there ever were any). Momentum and sales coupled with a lack of imagination compells these organizations to continually poll customers for ideas (or simply copy the competition), and grind them out until applications sport a porcupine’s coat of random disparately connected features.

But there are some other key issues as well that are particularly insidious for the non-SaaS world.

Consider the issues of supporting multiple platforms and versions of the software. I’ve chatted on several occassions with peers of mine who’ve done duty for both SaaS and conventional product development organizations. We’ve tried to estimate what the cost of supporting multiple platforms and versions is for the typical Enterprise Software R&D budget. The results are surprising. I routinely hear 30-40% of cycles are expended in these areas.

Imagine boiling off 40% of your available cycles for innovation just supporting old releases and doing platform work. SaaS companies do neither.

First, there are not multiple platforms for SaaS. It all runs in the SaaS company’s data center on their preferred platform. No ports, no additional testing, no maintenance, no architectural workarounds for deficiencies in one platform or another. In addition, SaaS companies can focus their talent and experience base around one platform, so resources become more fungible and a larger community of experts can be built.

Second, customers run the latest release as soon as it becomes available. I’ve polled Technical Support professionals in the past and gotten them to reach into their trouble ticket databases to answer a key question:

How many trouble tickets involve problems that would have been fixed if the customer ran the latest release?

The numbers I got back ranged from a low of 40% to a high of 70%. That represents a huge number of fire drills, hot patches, and customer satisfaction angst that just simply does not occur for SaaS companies.

Is it any wonder they’re more nimble?

Last point is the release cycle time. Many large members of the Old School are used to release cycles of a year or more. This is simply not very agile. What are the chances the assumptions that drove a particular release cycle are still just as valid in the year it takes to release as they were when the cycle was begun? Are they still valid 18 months later? Some vendors take two or more years for a major release. At what point are you building software that just won’t matter to the market when you do finally release it? And how much of that sloth has to do with customer reluctance to accept the new release anyway?

SaaS companies take care of the burden for customers, speed their own development cycles to more like one or two quarters, and wind up with happier customers in general.

Appologies to Forrest Gump for the title of this post, but I want to talk a bit about a recent Steve Yegge post that I enjoyed reading.  Steve is riffing on a Joel Spolsky quote, “Smart, and gets things done.”

Joel’s point is to hire people that are smart, and make sure they also can get things done, because there are a lot of smart people who can’t.  He mentions PhD’s in large companies as one example.  Yegge’s riff centers on the idea that it is nearly impossible to tell whether people are smart because “”smart” is a generic enough concept that pretty much everyone in the world thinks they’re smart. This is due to the Nobel-prize-winning Dunning-Kruger Effect, which says, in effect, that people don’t know when they’re not smart.”  That’s an interesting appeal to ignore smart because of what some other smart people said, but we digress!

Steve spends a lot of words convincing us we are very unlikely to even be able to recognize someone smarter than ourselves, let alone hire them.  This is a point I seriously disagree with, and my read of the Dunning-Kruger effect doesn’t contradict that.  It doesn’t say people can’t recognize smart, it says they’ll tend to overestimate their own intelligence and underestimate that of others.  What does that mean? 

Generally, it means we can mostly recognize people who are a lot smarter than us, but not so much people a little smarter.  Are we suprised at this?  Did we need a Nobel Laureate to tell us?  No, a pretty casual study of human nature would have predicted it.  The problem is conflict and the tussle of ideas for supremacy by their backers.  A person who is a little smarter may simply seem antagonistic.  They keep beating us a little bit, but not always.  That annoys us and polarizes us against such people.  We start to think they aren’t so smart after all, just that they’re messing with us.  Or perhaps the smart person is not articulate, or not extroverted.  They’re conflict averse.  Hard to decide they’re smarter if they won’t or can’t stand up for their ideas.

I can say with great certainty that I have met a great many people smarter than myself and I have also had the pleasure of having smarter people working for me.  It’s a beautiful thing if you can arrange it.  I read somewhere that a successful management structure is a Type B personality leader with a lot of Type A’s to sweat the details.  I’m too Type A for that, but having a lot of smart (but get things done) people is nearly as good.

However, I think the problem I have with Yegge’s post is he spends an awful lot of time obsessing about making sure every last person is smarter.  Let’s face some realities.  Quite apart from the problem of even recognizing the smarters, why do they want to work for you?  What do you bring to the table for them?  Be sure to give that some serious thought and incorporate the results into your sales pitch when you go to hire those people.

I want to get back to Spolsky’s original aphorism, “Smart, and gets things done,” which Yegge has discarded as impractical, and point out that I agree with Joel that it conveys everything you need to know including how to decide “Smart”.  Joel is saying smart is important, and do what you can about it, but the juxtaposition of “and gets things done” is there for a reason.  And I believe it conveys the real secret sauce. 

There will be those eliminated from the process as “not smart”.  This is fine.  My read of the Dunning-Kruger effect in no way implies a conclusion that “not smart” has a high error rate.  So don’t hire any “not smarts!”  Now you have a bunch of “smarts”.  They are likely clustered around the interview decision maker’s collective IQ.  This is where “gets things done” shines. 

I have tended to view programming as a talent you are born with and that you cannot be taught to do well.  Perhaps this is an indication I am unsuccessful at identifying smart and Yegge is right, but I don’t think so.  I’ve seen very smart people who are lousy programmers.  How do I know this?  It starts out with they didn’t get things done!   Curiously, I have seen folks with just a high school diploma code rings around MIT CS PhD’s.  I’ve seen individuals with 5 years of experience code rings around those with 15.  I’ve reached a point where despite the fact that I have a CS degree from a good school, I’ve stopped caring about where the person went to school.  I’ve stopped caring about how old or how young they are to a great degree.  These are factors that may or may not get you into the interview with me, and if they got you in, they won’t be anything we’ll talk about.

What I care about is whether you played an integral role on the dev team for some product I am impressed by.  If you didn’t, I probably won’t talk to you for very long.  If you did, my conversation will be about drawing that out, understanding the role you played, and getting you to tell me all about what you did and why you’re proud of it.  As I talk to individuals, I also like to network and find out who they know that impressed them for having done something significant on a product they loved.  The networking is good, but so is the chance to engage in further dialog about this central test.  The right person can speak with great passion about their contribution, and you’ll leave the discussion with little doubt.  You won’t be right in hiring them 100% of the time, but the success rate is pretty darned good.

I’m in the process of adding some new talent to my current team as our company is growing rapidly, so I thought it good to revisit these thoughts.

And remember, Smart is as Smart does.

I recently caught up with CEO Ken Rudin over lunch to see what was new at LucidEra since we last chatted 7 months ago.  It turns out quite a lot has happened, and Ken was very generous to share some of the news as well as a deep discussion of what went on behind the scenes to make it happen. 

The big news is that he now feels like LucidEra has reached some sort of “critical mass.”  What does he mean by that?  Critical Mass means that the sales process feels different and it has gotten markedly easier.  It’s not an end goal, and Ken would probably not agree that he is at “critical mass”.  Rather, it is a meaningful and measurable step on the road to finding your product/market fit and best strategy to make winning easy.  For LucidEra Critical Mass first became apparent at about 40 customers.  This is a figure that is pretty similar to what others have mentioned.  In fact, 40 customers is the point where Greg Gianforte of RightNow decided to hire a sales staff and his company started doubling every 90 days.

I asked Ken what it took to create the critical mass, and he gave me 4 answers:  Total Focus on Customer Success, Best Practices, and Customer Marketing.  Each one is a fascinating topic, so let’s delve into them.

Total Focus on Customer Success

Many companies claim to have a total focus on Customer Success, but it entails quite a lot.  In some cases, making a customer successful can even turn out to be a money-losing proposition.  For a relatively new startup, making money is not the objective.  Instead, it is proving yourself and getting on the map so that the world can see what you’re capable of. 

Rudin talks about his initial customers making comments like, “I got off the phone feeling like a princess.”  Or, in another case, having a customer get off a support call with LucidEra and immediately contact the CEO and other executives to compliment the company on their superb customer support.

Rudin’s company approaches Total Customer Success in a number of ways.  First, he has done the most critical thing by setting the agenda for the organization that this is the goal.  That’s hard to do, especially for all levels. The sales people will like to think their goal is to make quota.  Customer Service may simply want to close the tickets as fast as they can.  Professional Services wants to sell services.  But for LucidEra, the goal is none of those.  Rather, it is to pull out all the stops towards making customers successful.

Towards that end, they use a combined SWAT team that meshes normal customer support with professional services to make sure customers are getting everything they need.  They focus hard on developing Best Practices that can really change business outcomes for customers (more on Best Practices in a moment).  They try to make sure customers see real value right from the very first moment.

Their trial is called a Pipeline Health Check.  It’s goal is to hook up to your Salesforce.com data in 48 hours and present you with a Best Practices report on what you should be doing differently in sales to improve your results.  As Rudin says, if customers aren’t talking about the result of the Health Check constantly in their staff meetings, something is wrong because there are some real actionable insights there.

This is part of delighting the customer with real value.  It goes on to delighting the customer with the relationship.  Customers often receive bottles of wine, or cookies baked in the shape of the company’s light bulb logo.  Ken Rudin always sends a handwritten thank you note when the deal closes to every customer.

LucidEra’s salesforce, for their part, are incented not just on traditional measures for closing deals, but on measures having to do with the willingness of the customer to talk about their experiences with LucidEra.  Obviously that will be difficult if the customer isn’t very pleased.

Obviously, this all reflects a very personalized and customer-centric approach to selling.  I asked Ken what hadn’t worked and he mentioned web marketing, especially around search engines.  Why not?  “Because people don’t know what to Google for to find us,”  he says.  What LucidEra is doing is too new and unusual.  So it takes a more personal touch.  But it also takes Best Practices, which are something customers really sink their teeth into.

Best Practices

Best Practices involves not just telling a customer about product features and abstract benefits.  Rather, Best Practices are a recipe that customers can follow to use the product to achieve real business results.  So much of software is marketed around the promise that if features result in benefits, and if you want the benefits, you need a particular set of features.  It doesn’t take long in a competitive market before the blizzard of features has become so fierce you can scarcely see the hand in front of your face.

I like Rudin’s Best Practices approach a lot better.  It enters into the relationship right at the start, because the primary deliverable from the Pipeline Health Check is a set of Best Practices recommendations about how to improve sales at your company.

I was curious to learn how LucidEra developed their Best Practices.  It’s been a real challenge at some companies I’ve worked for to get together Best Practices and make them available to customers.  Rudin’s response was straightforward.  Initially, they had some domain talent on board in the form of folks they’d hired from BI companies who had a lot of experience around Best Practices for Sales Analytics.  That was followed by lots of ideas from customers.  Some were direct suggestions, and others came into being as LucidEra analyzed customer data.  Lastly, a lot of the company’s key differentiated product features resulted in Best Practices.  After all, what good is a feature if it can’t?

These Best Practices are marketed through Webinars and other vehicles to produce leads.  Visit a Webinar and learn enough about them to decide you need the Pipeline Health Check.  That then leads to a sale in many cases.

Customer Marketing

The final ingredient in Ken Rudin’s critical mass plan for Lucid Era is what he calls “Customer Marketing”.  LucidEra makes sure customers are mentioned constantly in every marketing communication.  And it isn’t just the mention, they’re quoted, their names are given, and one generally gets the idea of who the community behind LucidEra really are.

Interestingly, LucidEra is quite successful at turning its own customers into ambassadors as well.  Rudin tells the story of a CFO coffee held by Silicon Valley Bank as a networking event.  Apparently one of his customers was there and proceeded to demo the application for a group of CFO’s. 

In another example, LucidEra was presenting as part of sponsoring the Silicon Valley Salesforce.com Users Group.  At the end, a customer stood up unbidden in the audience and told the crowd how great their experience with the product and company had been.  You can imagine how powerful such things can be.

Analysis

Getting a startup on the map is a necessary step to making winning easier.  A company is not on the map until it has a significant number of highly satisfied customers who are willing to speak up about it.  But getting customers to speak up is only a part of it.  Having the maniacal focus and contact with these customers mobilizes a startup to do right.  It is a product/market fit of sorts.  I say of sorts because elements are not scalable indefinitely.  However, having the deep conversations with these customers makes it easier to tell how to build the parts that will be scalable throughout the life of the company.

What’s Next

Ken Rudin is quick to point out he is not done.  Critical Mass is my term for what he’s achieved.  For his part, there is a lot more to do.  Many more customers to sell, lots of learnings to put into practice, and a lot more to learn.

The current product does a good job managing the sales end of the pipeline.  Next up is a product release aimed at the lead generation process.  The reports available here sound intriguing.  Imagine  being able to track every stage of your pipeline, know what the close rate for deals in a stage might be, as well as the average time deals stay within a stage.  Now you’re in a position to extrapolate by looking at the whole pipeline what revenue might come in at various times in the future as deals make their way through the pipeline.

Pretty cool stuff!

I chuckled reading Stowe Boyd on Yahoo’s travails.  He is clear Jerry Yang should be replaced in his post titled (sic):  “Joe Nocera on Jerry Wang’s Yahoo”.   He mentions not thinking Meg Whitman could do much for Yahoo.  I have to agree there, not clear she “did” much for eBay.  It grew fabulously during her reign, but it was a “steady as she goes, damn the innovation, and full speed ahead” kind of reign.  No turnaround challenges there, and she departed just as the troubles started to get menacing enough that it might require some real ingenuity to fix.

How did Benioff come up in this context?  Well here is the money quote of the day from Stowe:

You need a young, hungry and ambitious visionary. Like Salesforce.com’s Marc Benioff.

Just one tiny little problem with this theory.  With respect to young, Marc Benioff is 43 while Jerry Yang is 39.  With respect to hungry, I did the math this morning and if Benioff is hungry, it is only because the value of his Salesforce shares are a whopping $1M less than Yang’s Yoohoo shares.  Did I say $1 million dollars in my best imitation of Dr Evil?  I should have because that’s “one million dollars (evil leer)” on a total worth of 1 billion dollars for both men.

I’ve got no problems with Mr Benioff.  His execution at Salesforce has been genius in many ways, but it’s hard to see him as young, hungry, and ambitious at this stage.  Stowe probably meant to original Benioff at the time he founded Salesforce, but it isn’t clear such a personality is really what is needed to fix a giant injured beast that’s lumbering almost blindly through the jungle in its pain. 

Personally, I think someone more like HP’s Mark Hurd would be on point for Yahoo.  Sounds crazy, I know.  So much of the blogosphere wants to get someone hip in there.  But you want the hipsters operating below the level of a CEO that can clean up the business and get it to perform by the numbers.  Hip is not so reliable at that until you find your next hit.  The company has already been bet on one man’s ambitions.  It has some valuable properties that need to be emphasized and that can make the company financially healthy until the hipsters can figure out some new new things.  The hipsters won’t come around until the company looks healthier anyway.  Why be subject to the stigma and negative energy?

But wait!  What about Microsoft? 

I’m really not surprised things have gone this way for Yahoo.  As I wrote some time back, it was over when Yang fought so hard as to make Microsoft feel rejected.  You can agree or disagree with what the Microsofties are doing, but keep in mind they have some very bright people who are quite passionate about what they’re doing.  If you hope to join them, they’ll expect you to salute their flag.

Mathew Ingram writes about the iPhone as razor/razor blades, but he’s missed the most important part.  The handset is indeed a razor, and I suppose you can see the service as razor blades that benefit the carriers.  But where is Apple’s razor blade play?

It’s the iPhone Application Store.  Apple has bet heavily on the idea that the iPhone is a platform.  It’s why thye’re so ballistic about unlockers, and why they’ve allowed the carriers to get the recurring service revenue on the deal in an apparent retrenchment to traditional models.  Apple sees that it can radically stimulate growth, make the carriers more eager to embrace the iPhone, and give the unlockers a serious setback all in one strategic move.

What does this have to do with Adobe Flash and the fact I can’t get it on my iPhone?  Somewhere, I read that the SDK prohibits you from placing an interpreter on the iPhone.  That’s when the light bulb went off.  Flash is an interpreter.  Why would Apple care?

An interpreter is a piece of software that creates a “virtual machine.”  To the hardware, the interpreter looks like a single application, but it can run any number of applications written in its interpreted language.  Java is an interpreted language.  The JVM is the Java interpreter.  Flash is an interpreter, and Flex is a language and framework that run on that virtual machine.

Putting it into Apple’s terms, if they let Flash onto the iPhone, you pay them once for that application, and then you’ll have a backdoor through which any Flash/Flex application can gain entry without having to pass through the Application Store.  It’s a revenue leak of biblical proportions, and one the market would be sure to exploit.

So what’s a poor Adobe to do?  It’s a tough problem.  They’d need to provide Apple with a special version that only runs apps that are certified at the iPhone Application Store.  Adobe is probably loathe to do something so specialized, and it likely conflicts with their religion about what Flash is.  Worse, there is a lot of Flash out there (the vast majority) that is not applications.  It’s animations or ads or streamed video.  It’s not obvious how to tell the difference between an app Apple wants to charge for (they get 30% of the revenue and the app owner gets 70%) and an ad or other piece nobody would pay for.

Don’t look for the problem to be resolved very soon, and if it is, look for some Draconian measures to have been taken around Flash.

Related Articles

Piper Jaffray says iPhone Application Store could be $1.2B business next year.  Apple isn’t going to play around and risk a $1B+ business!

3G iPhone Shuns SaaS for Longer Term Opportunity