Disconnect To Reconnect

All journeys, no matter how fruitful, come to an end. After a little over nine and half years I decided to leave SAP last week. What a journey this has been!

Making Design Thinking real

I was hired into a multidisciplinary corporate strategy team, set up by Hasso Plattner, the chairman of SAP's supervisory board, and the only co-founder still with the company, whose mission was to help SAP embrace “design thinking” in how it built products and processes as well as how it worked with customers. It was the best multidisciplinary team one could imagine to be part of. We were multidisciplinary to a fault where I used to joke that my team members and I had nothing in common. I am proud to be part of this journey and the impact we helped achieve. Over the years we managed to take the double quotes out of design thinking making it a default mindset and philosophy in all parts of SAP. It was a testament to the fact that any bold and audacious mission starts with a few simple steps and can be accomplished if there is a small passionate team behind it striving to make an impact.

Be part of foundation of something disruptive

Being part of the Office of CEO I worked with two CEOs—Henning and Leo—and their respective executive management teams. This was by far the best learning experience of my life. I got an opportunity to work across lines of businesses and got first hand exposure to intricate parts of SAP’s business. As part of the corporate strategy team I also got an opportunity to work on Business Objects post-merger integration, especially the joint product vision. Some of that work led to the foundation of one of the most disruptive products SAP later released, SAP HANA.

Fuel the insane growth of SAP HANA

HANA just happened to SAP. The market and competition were not expecting us to do anything in this space. Most people at SAP didn’t realize full potential of it and most customers didn’t believe it could actually help them. I don’t blame them. HANA was such a radically foreign concept that it created a feeling of skepticism and enthusiasm at the same time. I took on many different roles and worked extensively with various parts of organization and SAP’s customers to explore, identify, and realize breakthrough scenarios that exploited the unique and differentiating aspects of HANA.

HANA’s value was perceived to help customers to do things better, cheaper, and faster. But, I was on an orthogonal, and rather difficult, mission to help our customers do things they could not have done before or could not even have imagined they could do.

I was fortunate enough to significantly contribute to early adoption of HANA—zero to billion dollars in revenue in three years—which also went on to become the fastest growing product in SAP’s history. I got a chance to work closely with Vishal Sikka, the CTO of SAP and informally known as the father of HANA, on this endeavor and on many other things. It was also a pleasure to work with some of the most prominent global SAP customers who are industry leaders. They taught me a lot about their business.

Incubate a completely new class of data-first cloud solutions

As HANA started to become a foundation and platform for everything we built at SAP my team took on a customer-driven part-accelerator and a part-incubator role to further leverage the most differentiating aspects of the platform and combine it with machine learning and AI to help build new greenfield data-first cloud solutions that reimagined enterprise scenarios. These solutions created potential for more sustaining revenue in days to come.

Practice the General Manager model with a start-up mindset

A true General Manager model is rare or non-existent at SAP (and at many other ISVs), but we implemented that model in my team where I was empowered to run all the functions—engineering, design, product management, product marketing, and business development—and assumed the overall P&L responsibility of the team. The buck stopped with me and as a team we could make swift business decisions. The team members also felt a strong purpose in how their work helped SAP. Often times, people would come up to me and say, “so your team is like a start-up.” I would politely tell them claiming my team as a start-up will be a great disservice to all the real start-ups out there. However, I tried very hard for us to embrace the start-up culture—small tight teams, experimentation, rewarding efforts and not just the outcome, mission and purpose driven to a fault, break things to make them work, insanely short project timelines, and mid to long term vision with focused short-term extreme agile execution—and we leveraged the biggest asset SAP has, its customers.

Be part of a transformative journey

I was fortunate to witness SAP’s successful transformation to a cloud company without compromising on margins or revenue and HANA-led in-memory revolution that not only paved the path for a completely new category of software but also became the fastest growing product in SAP’s history. These kind of things simply don’t happen to all people and I was fortunate to be part of this journey. I have tremendous respect for SAP as a company and the leaders, especially the CEO Bill McDermott, in what the company has achieved. I’m thankful to all the people who helped and mentored me, and more importantly believed in me.

Looking forward to not doing anything, at least for a short period of time

At times, such a long and fast-paced journey somewhat desensitizes you from the real world. I want to slow down, take a step back, and rethink how the current technology storm in the Silicon Valley will disrupt the world again as it has always and how I can be part of that journey, again. There are also personal projects I have been putting off for a while that I want to tend to. I’m hoping a short break will help me reenergize and see the world differently. When I broke this news to my mom she didn’t freak out. I must have made the right decision!

I want to disconnect to reconnect.

I am looking forward to do away with my commute for a while, on 101, during rush hours, to smell the proverbial roses. I won’t miss 6 AM conference calls, but I will certainly miss those cute self-driving Google cars on streets of Palo Alto. They always remind me of why the valley is such a great place. For a “product” person, a technology enthusiast, and a generalist like me who has experienced and practiced all the three sides—feasibility, viability, and desirability—of building software the valley is full of promises and immense excitement. In coming days I am hoping to learn from my friends and thought leaders that would eventually lead me to my next tour of duty.

About the picture: I was on a hiking trip to four national parks a few years ago where I took this picture standing on the middle of a road inside Death Valley National Park. The “C” curve on a rather straight road is the only place on that long stretch where you could get cell phone reception. Even short hiking trips have helped me gain a new perspective on work and life.     

"Trying to be nice" Becomes Less Important For Developers As They Gain Experience

No, I didn’t say this, but 56,033 developers in 173 countries who responded to recent Stack Overflow's developer survey did.  I have always enjoyed going through these surveys to validate my several hypotheses and learn new things. I would strongly encourage you to go through the results from the most recent survey here.

Here are some interesting insights:

Occupation

"Full stack developer" is the most identified developer occupation. More and more developers are gravitating towards this occupation where they are simultaneously working on 5 to 6 programming languages or frameworks at time. Rise of new languages and frameworks don’t mean developer fragmentation, but more developers picking up more and more languages. It’s not about SQL or Angular; it’s SQL and Angular.

Ninjas: 10% of respondents self-identified as Ninjas! Yeah. So, yes, watch out.

Age

The millennial: The highest percentage of developers, 28.4%, are in the age group 24-29, followed by 23.6% in the age group 20-24, and 18.1 % in the are group 30-34. This validates my hypothesis: more than 70% of developers are millennial, from youngest to oldest.

Average age: India has the lowest average age for developers, 25.5. This might surprise some people unless you look at the overall population and demographics of India. While there is a large number of Indian developers who are older than 25.5 the current number of engineers graduating from colleges and entering into the workforce are outnumbering some of these developers to bring the overall average down. India is the second most populous country in the world (behind China) with median age of 25. Compare that to the US where the median age is 36. It will all make sense.

Star Trek versus Star Wars: The highest percentage of developers (68.4%) like Star Wars. The same age group also happens to like Star Trek the least (17.6%), if at all they know what Star Trek is. If you really like Star Trek you must be old :-)

Gender disparity

This continues to be the most depressing statistics.

92.8% “developers” are male.

There’s not much salary gap between genders for young developers in the US, but male developers of the age of 30+ get paid up to $20,000 more than female developers. This perhaps explains the ongoing debate: male and female developers get initially hired at similar salaries, but male developers negotiate harder for promotions and raises compared to female developers. I would argue this disparity will most likely be also true for disciplines other than technology.

Diversity

While 73% of developers responded they value diversity, product managers and engineering managers responded they value diversity the most. It validates my hypothesis that people value diversity more when they either hire/manage people or manage a product. While individual contributors still work in a diverse team and most of them value diversity they perhaps don’t realize and appreciate the bigger impact of a diverse team.

Education

Machine learning developers have most likely completed a Masters or a PhD. This isn’t surprising given the complexity around this domain and traditionally how niche it is. As it becomes more mainstream I expect these skills to get commoditized and the numbers will likely change.

Developers, across the board, with Masters and PhD degrees get paid more. Good to know that higher education is still important.

Technology

The most popular stack: JavaScript is the most popular technology (55.4%). No surprises - thanks to Node.js, Angular, and many other frameworks. SQL is the second most popular language followed by Java. This proves the power of SQL as ubiquitous database access language and simplicity of JavaScript that makes it a preferred choice of language even for backend programming.

Emerging technology: Developers seem to be loving React (trending 311.3%). It proves that if you design a better framework developers will flock. Developers are not necessarily married to a specific framework; they love to learn and adopt newer things if it helps them solve their problems in a better way. If you’re are an organization making technology decisions your life is going to get more and more complicated. You have to design your platform and architecture to embrace newer languages and frameworks more frequently than you would have anticipated or desired.

Developers love Mac: Mac is the most popular desktop OS for developers. Windows has been losing its share and this year Mac overtook Linux as the most popular desktop OS.

Employment

Looking for a new job: Indian developers amongst all other developers are either actively looking for a job (29.2%) or will consider an opportunity (60.7%) when approached. This is consistent with what I have experienced: it is extremely hard to retain talent in India and developers will jump ship when offered something slightly better. Employers are outcompeting each other in attracting talent and offering outrageous raises. Unlike many countries, developer salaries are not normalized in India and the country has relatively high inflation rate and weaker currency (against US dollar) making it easier for US-based companies to offer more money to make developers jump ship.

Priorities: German developers prioritize work-life balance over salary. I have personally known many German developers and many would agree to these numbers.

Titles: Developers care less about titles and more about making or influencing decisions as they gain more experience. Titles may sound exotic when developers join the workforce, but they realize over a period of time that titles are often disconnected with compensation and empowerment. These numbers are a reflection of that realization.

Promotions: Getting promoted is one of the biggest priorities for Indian developers. This explains the hierarchical nature of Indian companies and the societal value of a promotion which might be less relevant in the most western countries.

Source: Stack Overflow 2016 Developer Survey

Salary

US and Australia are somewhere on the top when it comes to developer salary (considering purchase power parity). My hypothesis is that good higher technical education and favorable immigration policies in these countries are making it relatively easy to attract the best students and early talent. This creates a vibrant ecosystem where skills are appreciated and valued more compared to other places. Also, good developers attract other good developers.

Large companies tend to pay higher salary than smaller companies. The survey does not seem to reflect the equity versus salary split and preferences - that could have been a better indicator of where and why developers work. Contrary to popular belief freelancers/contractors are paid about 10% less than full-time developers.

Photo courtesy: Thomas Hawk

Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part III

This is the third and the last post in the three-post series on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with your prospects and others to mitigate them. If you missed the previous posts the first post was about “why buy anything” and the second post was about “why buy mine." This post is about “why buy now."

Platform sales is often times perceived as a solution looking for a problem a.k.a hammer looking for a nail. In most cases your prospects don’t have a real urgency to buy your platform making it difficult for you to make them commit on an opportunity. There are a few things that you could do to deal with this situation:

Specific business case

It’s typical for vendors to create a business case positioning their solutions to their prospects. These business cases include details such as solution summary, pricing, ROI etc. If you’re a platform vendor not only you have to create this basic business case but you will also have to go beyond that. It’s relatively hard to quantify ROI of a platform since it doesn’t solve a specific problem but it could solve many problems. It is extremely difficult to quantify the impact of lost opportunities. If your prospect doesn’t buy anything do they lose money on lost opportunities? Traditional NPV kind of analysis goes for a toss for such situations.

As a vendor not only you will have to articulate the problems (scenarios/use cases) that you identified leading up to this step but you might also have to include more scenarios that were not specifically discussed during the evaluation phase. Getting a validation from the business on expected return on their investment while fulfilling their vision is crucial since your numbers will most likely get challenged when your prospect creates its own business case to secure necessary investment to buy your platform.

Leveraging the excitement

What seemed like a problem when you worked with a variety of people inside your prospect’s organization may not seem like a problem in a few weeks or months. It’s very important in platform sales cycle not to lose momentum. Find a champion of your pilot keep socializing the potential of your platform inside your prospect’s organization as much as you can while you work on commercials of your opportunity. People should be talking about your disruptive platform and wanting to work with you. Cease that moment to close it.

Knowing who will sign the check

Platform sales are convoluted. People who helped you so far may not necessarily help you with the last step—not that they don’t want to but they may not be the buyers who will sign the check. It’s not uncommon in enterprise software sales to have influencers who are not the final buyers but the buyers do have somewhat defined procurement process for standard solutions. When it comes to buying a platform many buyers don’t quite understand why they should be spending money on disruptive platform that may or may not necessarily solve a specific problem.

To complicate this further, for disruptive technology, it typically tends to get cheaper as it becomes more mature. This gives your prospect one more reason to wait and not buy your platform now. As I mentioned in the previous post your focus should never be on pricing (unless of course you are the best and cheapest vendor by a wide margin) but on immediate returns, no lost opportunities, and helping your prospect gain competitive differentiation in their industry.

Despite of working with your prospect for a while helping them define problems and piloting your platform to prove out the value proposition, you might get asked again to do things all over again. There are two ways to mitigate this situation: a) involve buyers early on in the sales process and not at the very end so that they are part of the journey b) work aggressively with your influencers to establish appropriate communication channels with the buyers so that it’s the influencer’s voice they hear and not yours.

Happy selling!

Photo Courtesy: Wierts Sebastien  

Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part II

This is the second post in the three-post series on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with your prospects and others to mitigate them. If you missed the first post in the series it was about “why buy anything.” This post is about “why buy mine."

Convincing  your prospects they need to buy a platform is just a first step in the sales process. You need to work with them to convince them to buy not just any platform but your platform.

Asking the right questions - empathy for business

This is the next logical step after you have managed to generate organic demand in your prospect’s organization a.k.a “why buy anything” as I mentioned in the Part I. Unlike applications, platforms don’t answer a specific set of questions (functional requirements). You can’t really position and demonstrate the power of your platform unless you truly understand what questions your prospect needs you to answer. Understanding your prospect’s questions would mean working closely with them to understand their business and their latent needs. Your prospect may or may not tell you what they might want to do with your platform. You will need to do it for them. You will have to orchestrate those strategic conversations that have investment legs and understand problems that are not solvable by standard off-the-shelf solutions your prospect may have access to.

Answering the right questions - seeing is believing

One of the key benefits of SaaS solutions is your prospect’s ability to test drive your software before they buy it. Platforms, on-premise or SaaS, need to follow the same approach. There are two ways to do this: you either give your prospect access to your platform and let them test drive it or you work with your prospect and be involved in guiding them through how a pilot can answer their questions and track their progress. While the latter approach is a hi-touch sale I would advise you to practice it if it fits your cost structure. More on why it is necessary to stay involved during the pilot in the next and the last post (Part III) in this series.

Proving unique differentiation

Once your prospect starts the evaluation process whether to buy your platform or not your platform will be compared with your competitive products as part of their due diligence efforts. This is where you want to avoid an apple-to-apple comparison and focus on unique differentiation.

Even though enterprise platform deals are rarely won on price alone don’t try to sell something that solves a problem your competitors can solve at the same or cheaper price. Don’t compete on price unless you are significantly cheaper than your competitor. The best way to position your platform is to demonstrate a few unique features of your platform that are absolutely important to solve the core problems of your prospect and are not just nice-to-have features.

Care deeply for what your prospects truly care about and prove you’re unique.

The next and the last post in this series will be about “why buy now.”

Photo courtesy: Flickr 

Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part I

I think of enterprise software into two broad categories - products or solutions and platform. The simplest definition of platform is you use that to make a solution that you need. While largely I have been a product person I have had significant exposure to enterprise platform sales process. I have worked with many sales leaders, influencers, and buyers. Whether you're a product person or you're in a role where you facilitate sales I hope this post will give you some insights as well as food for thought on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with customers and others to mitigate some of these challenges.

I like Mark Suster's sales advice to entrepreneurs through his framework of "why buy anything", why buy mine", and "why buy now." I am going to use the same framework. Platform sales is sales in the end and all the sales rules as well as tips and tricks you know that would still apply. The objective here is to focus on how disruptive enterprise software platform sales is different and what you could do about it.

The first part of this three-post series focuses on "why buy anything."

Companies look for solutions for problems they know exist. Not having a platform is typically not considered a good-enough problem to go and buy something. IT departments also tend to use what they have in terms of tools and technology to solve problems for which they decide to "build" as opposed to "buy." Making your prospects realize they need to buy something is a very important first step in sales process.

Generating organic demand:

Hopefully, you have good marketing people that are generating enough demand and interest in your platform and the category it belongs to. But, unfortunately, even if you have great marketing people it won't be sufficient to generate organic demand for a platform with your prospect. When it comes to platform sales your job is to create organic demand before you can fulfill it. This is hard and it doesn't come naturally to many good sales people that I have known. By and large sales people are good at three things: i) listen: understand what customers want ii) orchestrate: work with a variety of people to demonstrate that their product is the best feature and price fit iii) close: identify right influencers and work with a buyer to close an opportunity. While platform sales does require these three qualities like any other sales creating demand or appetite is the one that a very few sales people have. You have to go beyond what your prospects tell you; you have to assess their latent needs. Your prospects won't tell you they need a disruptive platform simply because they don't know that.

You're assuming a 1-1 marketing role to create this desire. Connect your prospects with (non-sales) thought leaders inside as well as outside of your organization and invite them to industry conferences to educate them on the category to which your platform belongs to. Platform conversations, in most cases, start from unusual places inside your prospect's organization. People who are seen as technology thought leaders or are responsible for "labs" inside their company or people who self-select as nerds or tinkerers are the ones you need to evangelize to and win over. These people typically don't sit in the traditional IT organization that you know of and even if they do they are not the ones who make decisions. These folks are simply passionate people who love working on disruptive technology and have a good handle on some of the challenges their companies are facing.

Dance with the business and the IT:

As counterintuitive as it may sound working with non-IT people to sell technology platform to IT is a good way to go. The "business" is always problem-centric and the IT is always solution-centric. Remember, you're chasing a problem and not a solution. Identify a few folks in a line of business who are willingly to work with you. This is not easy especially if you're a technology-only vendor. Identify their strategic challenges that have legs — money attached to it. Evangelize these challenges with IT to generate interest in disruptive platform that could be a good fit for these challenges.

IT doesn't like disruption regardless of what they tell you. If they are buying your disruptive platform they are not buying something else and they don't use some of the existing platforms or tools they have. There are people who have built their careers building solutions on top of existing tools and technology and they simply don't want to see that go away. You will have to walk this fine line and get these people excited on a new platform that doesn't threaten their jobs and perhaps show them how their personal careers could accelerate if they get on to this emerging technology that a very few people know in the company but something which is seen highly strategic in the market. Don't bypass IT; it won't work. Make them your friends and give them an opportunity to shine in front of business and give them credit for all the work.

Chasing the right IT spend:

Most enterprise software sales people generally know two things about their customers: i) overall IT spend ii) how much of that they spend with you. What they typically don't know is how much a customer spends on similar technology or platforms from that overall IT spend that doesn't come your way. There are two ways to execute a sales opportunity: either you find something to sell for the amount that your customer typically spends with you on annual basis or you go after the larger IT spend and expand your share of the overall pie. It's the latter that is relevant when you're selling platform to your existing customer (and not a prospect).

Platform, in most cases, is a budgeted investment that falls under "innovation" or "modernization" category. If you're just focused on current spending pattern of your customer you may not be able to generate demand for your platform. It is your job to convince your customer to look beyond how they see you as a vendor and be open to invest into a category that they might be reluctant for.

The next post in this series will be about "why buy mine."

Photo courtesy: Stef

Recruiting End Users For Enterprise Software Applications

As I work with a few enterprise software start-ups I often get asked about how to find early customers to validate and refine early design prototypes. The answer is surprisingly not that complicated. The following is my response to a recent question on Quora, "How do we get a target audience for enterprise applications, when you dont have an enterprise customer yet for rapid prototyping?"

Finding a customer and finding end users are quite different. In enterprise software end users are not the buyers and the buyer (customer) may or may not use your software at all. To recruit end users, there are three options:

Friends and families: Use your personal connections through email and social media channels and ask for their time (no more than 30 minutes) to conduct contextual inquiries and get validation on your prototypes. Most people won't say no. Do thank them by giving them a small gift or a gift card.

Find paid end users: This does seem odd but it works. I know of a few start-ups that have used this method effectively. Use Craigslist and other means to recruit people that match your end user role and pay them to participate in feedback sessions. It is worth it.

Guerrilla style: Go to a convention or a conference where you could find enough end users that fit your profile. Camp out at the convention with swag and run guerrilla style recruiting to validate and prototype. Iterate quickly, preferably in front of them, and validate again.

Chasing That Killer Application Of Big Data

I often get asked, "what is the killer application of Big Data?" Unfortunately, the answer is not that simple.

In the early days of enterprise software, it was the automation that fueled the growth of enterprise applications. The vendors that eventually managed to stay in business and got bigger were/are the ones that expanded their footprint to automate more business processes in more industries. The idea behind the killerness of some of these applications was merely the existence and some what maturity of business processes in alternate forms. The organizations did have financials and supply chain but those processes were paper-based or part-realized in a set of tools that didn't scale. The objective was to replace these homegrown non-scalable processes and tools and provide standardized package software that would automate the processes after customizing it to the needs of an organization. Some vendors did work hard to understand what problems they were set out to solve, but most didn't; they poured concrete into existing processes.

Traditional Business Intelligence (BI) market grew the same way; the customers were looking for a specific set of reporting problems to be solved to run their business. The enterprise applications that automated the business processes were not powerful enough to deliver the kind of reporting that organizations expected to gain insights into their operations and make decisions. These applications were designed to automate the processes and not to provide insights. The BI vendors created packaged tools and technology solutions to address this market. Once again, the vendors didn't have to think about what application problems the organizations were trying to solve.

Now with the rise of Big Data, the same vendors, and some new vendors, are asking that same question: what's the killer application? If Big Data turns out to be as big of a wave as the Internet or cloud we are certainly in a very early stage. This wave is very different than the previous ones in a few ways; it is technology-led innovation which is opening up new ways of running business. We are at an inflection point of cheap commodity hardware and MPP software that is designed from ground up to treat data as the first class citizen. This is not about automation or filling a known gap. I live this life working with IT and business leaders of small and large organizations worldwide where they are struggling to figure out how best they can leverage Big Data. These organizations know there's something in for them in this trend but they can't quite put a finger on it.

As a vendor, the best way to look at your strategy is to help customers with their Big Data efforts without chasing a killer application. The killer applications will be emergent when you pay attention and observe patterns across your customers. Make Big Data tangible for your customers and design tools that would take your customers away from complexity of a technology layer. The organizations continue to have massive challenges with semantics as well as the location and format of their data sources. This is not an exciting domain for many vendors but help these organizations bring their data together. And, most importantly, try hard to become a trusted advisor and a go-to vendor for Big Data regardless of your portfolio of products and solutions. Waiting for a killer application to get started or marketing your product as THE killer application of Big Data are perhaps not the smartest things to do right now.

Big Data is a nascent category; an explosive, promising, but a nascent category. The organizations are still trying to get a handle on what it means to them. The maturity of business processes and well-defined unsolved problems in this domain are not that clear. While this category plays out on its own don't chase those killer applications or place your bets on one or two killer applications. Just get started and help your customers. I promise you shall stumble upon that killer application during your journey.

About the picture: I took this picture inside a historic fort in Jaisalmer, India that has rich history. History has taught me a lot about all things enterprise software as well as non-enterprise-software.

Empathize Not Sympathize

Many enterprise software vendors sympathize. "We know it's a bad experience" or "We will fix the usability." One of the reasons the software is not usable is because the makers never had any empathy for the end users who would use it. In many cases the makers didn't even know who their end users were; they only knew who would buy the software. As far as enterprise software is concerned people who write checks don't use the software and people who use software don't write checks and have a little or no influence in what gets bought. Though the dynamics are now changing.

Usability is the last step; it's about making software usable for the tasks that it is designed for. It's not useful at all when the software is designed to solve a wrong problem. Perfectly usable software could be completely useless.

It's the job of a product manager, designer, and a developer to assess the end user needs—have empathy for them—and then design software that meets or exceeds their needs in a way that is usable. That way they don't have to sympathize later on.

Design Thinking encourages people to stay in the problem space for a longer duration without jumping to a solution. What problem is being solved—needs—is far more important than how it is solved—usability. Next time you hear someone say software is not usable, ask whether it's the what or how. The how part is relatively easy to fix, what part is not. For fixing the "what" you need to have empathy for your end users and not sympathy.

Enterprise Software Needs Flow And Not Gamification

I don't believe in gamifying enterprise applications. As I have argued before, the primary drivers behind revenue and valuation of consumer software companies are number of users, traffic (unique views), and engagement (average time spent + conversion). This is why gamification is critical to consumer applications since it is an effort to increase the adoption of an application amongst the users and maintain the stickiness so that the users keep coming back and enjoy using the application. This isn't true for enterprise applications at all. This is not only not true for enterprise applications, but gamifying enterprise applications is couterproductive that makes existing task more complex and creates an artificial carrot that does not quite work.

A design philosophy that we really need for enterprise applications is flow. I am a big fan of Mihaly Csikszentmihalyi and his book "Flow: The Psychology of Optimal Experience." I would highly recommend you to read it. Mihaly describes flow as a series of autotelic experiences as an activity that consumes us and becomes intrinsically rewarding. The core intent of gamification is to make the applications a pleasure to use. What people really want is enjoyment and not just pleasure. They are different. Enjoyment is about moving forward and accomplishing something. Enjoyment happens due to unusual investment of attention. It comes from tasks that you have a chance to complete, has clear goals, provides feedback, and makes you lose your self-consciousness.

All the gamification efforts by new innovative entrants that I see seem to be disproportionately focused on "edge" applications since it's relatively easy for an entrant to break into edge applications to beat an incumbent as opposed to redesigning a core application. But most users I know spend their lives using the core systems. They have no intrinsic or extrinsic motivation to use these systems. Integrate flow in these systems to create intrinsic rewards that creates autotelic experiences. Application designers have traditionally ignored flow since it's a physical element that is external to an application, but life and social status extend beyond the digital life and enterprise applications. You get to be known as that finance guy or that marketing gal who is really awesome at work and helps people with their problems to get work done. Needless to say, helping people and getting work done are intrinsically rewarding. Help these people with their core activities and make non-core activities as minimum or transparent as possible. If I am hiking, make my drive to the trail head as easy as possible but make my hike as rewarding as possible. That should be the design principle of how you integrate flow into enterprise applications. Also, focus on perpetual intermediaries; design applications to reduce or eliminate learning curve but introduce users to advanced features as they make progress to increase their productivity on performing repeated tasks. This helps create an intrinsic reward of having learned and mastered a system. As people learn new things they become more complex and unique human beings, and believe it or not, you can influence that in your design of your enterprise software that they spend their lives using it.

Photo Courtesy: Mark Chadwick

Building And Expanding Enterprise Software Business In Brazil

While in Brazil, describing his country, one of my friends said, "We have all the natural resources that we need to be a self-sufficient country and we have had no natural disasters such as earthquakes and hurricanes. The only disaster that we had: we lost the worldcup."

This pretty much summarizes Brazil.

A helipad in front of my hotel in São Paulo.

On one side, São Paulo, the seventh largest city in the world, has one the largest per capita helipads in the world where the rich people don't like to drive around in traffic in cheap cars to avoid getting kidnapped at stop lights. On the other side, it is one hell of a city, just like Mumbai - large, organized chaos, and money. It is growing and it's growing fast. While income inequality has been on a steep rise in emerging economies as well as in the western world, it is declining in the Latin American countries, especially in Brazil.

If you're thinking of building or expanding enterprise software business in Brazil, now is the time. This is why:

Developing to a developed economy

Brazil has been boxed into BRIC economies but in reality it behaves more like a developed economy with lingering effects of a developing economy. Even though corruption is rampant in Brazil, it exists at much higher level and a common man typically doesn't suffer as miserably as he/she would suffer in other countries such as India. Being a resourceful country, there are all kinds of jobs. The bureaucracy will break and the infrastructure will also catch up very soon due to the soccer world cup in 2014 followed by the Olympics in 2016. Don't apply your BRIC strategy to Brazil. Consider Brazil as a developed nation and aggressively expand.

Courtesy: Economist

Stronger middleclass

Middleclass has money and they are willing to spend. Brazilian tax laws are the most complex laws that I have ever seen.  Even though the global retail brands are present in Brazil, they are outrageously expensive. Making a weekend trip to Miami to shop is quite common. Even after paying for a plane ticket and hotels it is cheaper shop in the US. The retailers in Brazil are trying to better understand this behavior and the global brands are also looking at several different ways to market to this middleclass. As an ISV this is a gold mine that you should not be ignoring.

Local to Global

Following the nation's growth many local companies in Brazil are aspiring to go global, establishing their business in developed economies. Local ISVs neither have scale nor features to support these efforts. These companies (typically mid to large) are looking at global ISVs for help, and yes, they are willing to spend.

Then you ask, if it is this obvious, why aren't global ISVs already doing this. They are. It's obvious, but it is not that easy. These are the challenges you would run into:

Complex localization

Many global ISVs have given up localizing their software for the Brazilian market. The tax laws are extremely complex and so are other processes. If you are truly interested in the Brazilian market you need to build from scratch in Brazil for Brazil. Hire local talent, empower them, and educate them on your global perspective. Linux and related open source software talent is plentiful in São Paulo. These developers are also excited about the cloud are are building some amazing stuff. I would also suggest to either hire or partner with local domain experts as consultants, who can work with a product manager, to truly understand the nuts and bolts of local processes, laws, and regulations.

Rough sales cycles

Selling into large accounts is not easy. Work with partners for a joint go-to-market solution or have them lead or participate in your sales cycle. The sales cycle is not fair and square and the purchase decisions are not just based on merits of your offering. Even if customer likes a product, commercial discussion are a huge drag, from the sponsor, to buyer, to all the way up to purchasing. Be patient and take help of local experts to navigate these roads.

My taxi driver watching a live soccer game while driving

Language and culture

Speaking Portuguese is pretty much a requirement to get anything done. But, if you speak Spanish, you could get around and also pick up a little bit of conversational Portuguese. English-only approach won't work. Do not even attempt. Also, Brazilians don't like to be called Latin Americans. They like to be called Brazilians; avoid any Latin American references. While you are there, learn a thing or two from an average Brazilian about fitness. Unlike Americans, the Brazilians are not into junk food. At a churrascaria, they eat salad followed by meat followed by some more meat. If you wonder why they are so fit, especially in Rio, this diet perhaps explains. They do enjoy their lives and sip Cachaça at the beach, but they are damn serious about working out.

Analytics-first Enterprise Applications

This is the story of Tim Zimmer who has been working as a technician for one of the large appliance store chains. His job is to attend service calls for washers and dryers. He has seen a lot in his life; a lot has changed but a few things have stayed the same.

The 80's saw a rise of homegrown IT systems and 90's was the decade of standardized backend automation where a few large vendors as well as quite a few small vendors built and sold solutions to automate a whole bunch of backend processes. Tim experienced this firsthand. He started getting printed invoices that he could hand out to his customers. He also heard his buddies in finance talking about a week-long training class to learn "computers" and some tools to make journal entries. Tim's life didn't change much. He would still get a list of customers handed out to him in the morning. He would go visit them. He would turn-in a part-request form manually for the parts he didn't carry in his truck and life went on. Not knowing what might be a better way to work Tim always knew there must be a better way. Automation did help the companies run their business faster and helped increased their revenue and margins but the lives of their employees such as Tim didn't change much.

Mid to late 90's saw the rise of CRM and Self-Service HCM where vendors started referring to "resources" as "capital" without really changing the fundamental design of their products. Tim heard about some sales guys entering information into such systems after they had talked to their customers. They didn't quite like the system, but their supervisors and their supervisors' supervisors had asked them to do so. Tim thought somehow the company must benefit out of this but he didn't see his buddies' lives get any better. He did receive a rugged laptop to enter information about his tickets and resolutions. The tool still required him to enter a lot of data, screen by screen. He didn't really like the tool and the tool didn't make him any better or smarter, but he had no other choice but to use it.

Tim heard that the management gets weekly reports of all the service calls that he makes. He was told that the parts department uses this information to create a "part bucket" for each region. He thought it doesn't make any sense - by the time the management receives the part information, analyzes it, and gives me parts, I'm already on a few calls where I am running out of parts that I need. He also received an email from "Center of Excellence" (he couldn't tell what it is, but guessed, "must be those IT guys") whether he would like to receive some reports. He inquired. The lead time for what he thought was a simple report, once he submits a request, was 8-10 weeks and that "project" would require three levels of approval. He saw no value in it and decided not to pursue. While watching a football game, over beer, his buddy in IT told him that the "management" has bought very expensive software to run these reports and they are hiring a lot of people who would understand how to use it.

One day, he received a tablet. And he thought this must be yet another devious idea by his management to make him do more work that doesn't really help him or his customers. A fancy toy, he thought. For the first time in his life, the company positively surprised him. The tablet came with an app that did what he thought the tool should have done all along. As soon as he launched the app it showed him a graphical view of his service calls and parts required for those calls based on the historic analysis of those appliances. It showed him which trucks has what parts and which of his team members are better of visiting what set of customers based on their skill-set and their demonstrated ability in having solved those problems in the past. Tim makes a couple of clicks to analyze that data, drills down into line-item detail in realtime, and accepts recommendations with one click. He assigns the service calls to his team-members and drives his truck to a customer that he assigned to himself. As soon as he is done he pulls out his tablet. He clicks a button to acknowledge the completion of a service call. He is presented with new analysis updated in realtime with available parts in his truck as well as in his teammates' trucks. He clicks around, makes some decisions, cranks up the radio in his truck, and he is off to help the next customer. No more filling out any long meaningless screens. His view of his management has changed for good for the very first time.

As the world is moving towards building mobile-first or mobile-only applications I am proposing to build analytics-first enterprise applications that are mobile-only. Finally, we have access to sophisticated big data products, frameworks, and solutions that can help analyze large volume of data in real time. The large scale hardware — commodity, specialized, or virtualized — are accessible to the developers to do some amazing things. We are at an inflection point. There is no need to discriminate between transactional and analytic workload. Navigating from aggregated results to line-item details should just be one click instead of punching out into a separate system. There are many processes, if re-imagined without any pre-conceived bias, would start with an analysis at the very first click and will guide the user to a more fine-grained data-entry or decision-making screens. If mobile-first is the mindset to get the 20% of the scenarios of your application right that are used 80% of the times, the analytics-first is a design that should thrive to move the 20% of the decision-making workflows used 80% of the time that currently throw the end users into the maze of data entries and beautiful but completely isolated, outdated, and useless reports.

Let's rethink enterprise applications. Today's analytics is an end result of years of neglect to better understand human needs to analyze and decide as opposed to decide and analyze. Analytics should not be a category by itself disconnected from the workflows and processes that the applications have automated for years to make businesses better. Analytics should be an integral part of an application, not embedded, not contextual, but a lead-in.

A Lean Greentech Approach

I am a greentech enthusiast and I have been closely following the greentech VC investment landscape. The VCs like Kleiner Perkins who have had a large greentech portfolio including companies such as Bloom Energy are scaling down on greentech investment. Their current investment is not likely to get any returns close to what a VC would expect. The fundamental challenge with such greentech (excluding software) investment is that they are open ended capital-intensive; you just don't know home much time it would take to build the technology/product, how much it would cost, and how much you would be able to sell it for. The market fluctuations make things even worse. This is not only true in the case of start-ups but also true for the large companies; Applied Materials' grand plan to revolutionize thin-film solar business ended up in a bust.  

There's a different way to approach this monumental challenge.

Just look at how open source has evolved. It started out as non-commercial academia projects where a few individuals challenged the way the existing systems behaved and created new systems. These open source projects found corporate sponsors who embraced them and helped them find a permanent home. This also resulted in a vibrant ecosystem around it to extend those projects. A few entrepreneurs looked at these open source projects and built companies to commercialize them with the help of VC funding. Time after time, this business model has worked. Technologists are great at building technology, companies are great at throwing money at people, entrepreneurs are great at extending and combining existing technology to create new products, and VCs are great at funding those companies to help entrepreneurs build businesses. What VCs are not good at is doling out very large sum of money to bet on technology that doesn't yet exist.

If we need to make it work, we need a three-way relationship. People in academia should work on capital-intensive greentech technology projects that are funded by corporations through traditional grants. These projects should become available in public domain with an open source like license or even a commercial license. The entrepreneurs can license these technology, open source or not, and raise venture money to build a profitable business. The companies that are constantly contributing their greentech initiatives to public domain should continue to do so. Facebook's Open Compute project is gaining traction in its second year and Google continues to share their green data center design.

The important aspect is to differentiate technology from a product. The VCs are not that good at investing into (non-software) technology but are certainly good at investing into products. For many greentech companies, technology is a key piece such as a battery, a specific kind of a solar film, a fuel cell etc. Commercializing this technology is a completely different story. This requires setting up key partnerships such as eBay's new data center using Bloombox and Israeli government committing to a nationwide all-electric car infrastructure with Better Place.

Many large companies have set up their incubators or "labs" to find something that is fundamentally disruptive that could help their business. Later, there have been a very few success stories of these incubators or labs because the start-up world is way more efficient to do what big companies want to do. These labs are also torn between technology and products. My suggestion to them would be to go back to what they were good at - hiring great scientists from academia and working with academia on the next-generation technology to create a business model by either using that technology in your products or to license it to others who want to build business. This shifts the investment from a few VCs to a relatively large number of corporations.

What we really need is a lean greentech approach.

Photo Courtesy: Kah Wai Lin

Loving What I Do For Living

A few months back, I was helping a very large customer of ours to help simplify as well as automate their process of trading financial instruments. During one of my many visits to their office, I met a person who was trying to explain to me his job in supporting the people that are involved in this super complex process. I always ask a lot of questions — until they're totally annoyed and ready to kick me out of the room — to get a complete understanding of the business rationale behind whatever they're thriving for and their personal motivation behind it. Something unusual happened at this meeting. Instead of getting into the gory technical details of how they get things done, he chose to tell me a short and simple story.

"You know, um.. there's this early morning meeting everyday that Peter goes to with a bunch of other people. They all gather around a large table in a dimly lit conference room with a bunch of printed spreadsheets, a laptop, and a large calculator. Peter has a cup of coffee in one hand and a cigarette in the other hand talking to people who have coffee cups in their one hand and cigarettes in the other hand. This is their lives. I am concerned about Peter and I want him to stop smoking. Can you please help me?"

Now, this is the job that I love that makes me get out the bed and run for it. This is the human side of enterprise software. It's not boring.

Photo Courtesy: Jane Rahman

Social Shaming

An interaction designer, Joshua Kaufman, had his MacBook stolen a few days back. He is a smart dude. He had installed an app called Hidden on his MacBook before it was stolen. He tracked down the thief and asked the Oakland PD to catch him. They said no. He was frustrated, obviously. He published all the details regarding the theft including the picture of the guy who stole his MacBook on his blog. This story went viral on Twitter and Facebook and made it almost impossible for the cops to ignore it. Oakland PD found the guy and arrested him. Since then the story has been picked up by many major media outlets and became sort of a sensation.

Social shaming works.

There's a fine line between peer pressure and social shaming. Many car dealerships in the US have a whiteboard that tracks which sales reps sold how many cars. They also ring a bell every time someone sells a car. It's a cheesy thing to do, but it sends a clear message to other people to be more aggressive; it's indeed a form of peer pressure. It's also an efficient technique to motivate the kids.

In fact, it's one of the most important gamification elements.

Public shaming has been used in many different ways e.g. send an email out to all the sales people with a list of people highlighted in red that haven't updated the CRM system. I know of a company that had a practice in place to publicly give a "D'oh! award" to a developer who broke the nightly build. Social shaming is essentially public shaming using social media. During my discussion with many enterprise social software vendors, analysts, and thought leaders I have repeatedly argued that changing end users' behavior is less likely to succeed unless there's a significant upside for the end users. What is more likely to work is codifying the real life end user behavior in the software that they use. Social shaming is one of those. One of the ways to achieve this could be by designing software that promotes radical transparency, signals one's successes to the other, and nudges them to excel without embarrassing them.

Gamification Of Enterprise Applications

Gamification is a hot topic for consumer applications. It is changing the way the companies, especially the start-ups, design their applications. The primary drivers behind revenue and valuation of consumer software companies are number of users, traffic (unique views), and engagement (average time spent + conversion). This is why gamification is critical to consumer applications since it is an effort to increase the adoption of an application amongst the users and maintain the stickiness so that the users keep coming back and enjoy using the application.

This isn't true for enterprise applications at all.

For consumer applications, the end user and the buyer (if they pay to use) are the same. e.g. Amazon, eBay, Google, Facebook, LinkedIn etc. For enterprise applications, the end user is not the buyer. The buyers of enterprise applications write a check but don't use the applications, and even worse, the end users have a little or no influence on what gets bought. The on-premise ISVs don't directly benefit from user adoption, once the software is sold. This is also true for cloud or SaaS solutions except that there is no shelfware in SaaS. I would argue that the enterprise ISVs, on-premise as well as SaaS, would in fact benefit, in short term, from reduced user adoption since they would save money by supporting fewer users and reduced activity. Obviously, this is a very short-sighted and myopic view. I hope that the enterprise ISVs don't actually think that way since broader user adoption and deeper engagement are certainly important for longer term growth that allows the ISVs to build brand loyalty, develop stronger customer base, and gain an opportunity to up-sell and cross-sell.

The fundamental reason behind poor adoption of the enterprise applications is that they are simply not easy-to-use and they almost always come in the way to get the actual work done. In many cases, they are designed to be orthogonal to the actual business process that it is supposed to help an end user with. Also, in most cases, these applications are designed top-down to serve the needs of senior management and not the real needs of end users e.g. a CRM system that helps management to run pipeline reports but doesn't help a rep to be more efficient and agile. In cases where broader adoption for enterprise applications is required, it is typically achieved via a top-down mandate e.g. annoying reminder emails to fill out time sheets. The end users don't see themselves as a clear beneficiary of these applications.

Simply put, the approach to gain user adoption for consumer applications is a "carrot" and for the enterprise applications it is a "stick". But, it doesn't have to be that way. There's a significant potential to apply gamification elements to increase the end user engagement for the enterprise applications, make them sticky and fun to use, and make it a win-win situation for the buyers as well as the end users.

Cater to perpetual intermediaries:

Have you ever played Angry Birds? If not, I would highly encourage you to do so. It serves the category of people known as "casual gamers". These games have pretty much zero adoption barrier for a novice, but when you get serious, there are enough challenges in the game as you progress to keep you entertained and bring you back. The equivalent of casual gamers in the enterprise applications are known as "perpetual intermediaries". They don't want to become power users, but they don't want to stay beginners as well. The tool should have zero barrier for a first time user and should have affordances that encourages users to explore and learn more. Microsoft has done a pheneomenal job with Word and Excel. They are extremely easy to use for a person who has never used these tools before and they provide further discovery via contextual menus and reassurance via drop-down menus (and ribbon in later versions) in the journey of becoming a perpetual intermediary. That's exactly how I expect all the enterprise applications should behave.

Let users leverage serendipity:

One of the early features of Google Apps that I really liked: when user logs into Google Apps for a specific domain, she can see other people in the same domain (same company) who are also using Google Apps. This was not a task that someone explicitly wanted to accomplish, but sheer serendipity allowed them to discover other people and eventually helped collaborate with them. If there's an element of surprise in any app, that experience typically leaves positive impact on a user. How many times did you run into someone at a cafetaria or in a hallway and found that short and tacit conversation extremely valuable? The ISVs should thrive to create this experience in their applications. Foursquare's feature to let users know who else is at a venue, Facebook Places' push notification to notify when friends check-in at a place close by, and certain activity feeds that passively push information to users are all examples that leverages serendipity.

Design for teams over individuals:

The gamification elements for consumer applications target individuals, but that's not how corporations are run. In these corporations, the work gets done by a team and not by individuals — it's a team sport. It's the team and not the individuals that wins and loses. Also, for the most consumer applications, the individuals don't compete with other individuals on aspects beyond the application. The employees in a corporation aren't necessarily known for healthy competition and the gamification rewards might aggravate the existing rivalry. The badges are a digital reward, an accomplishment of some kind. Consumer companies are still struggling to take the badges beyond the reputation. I clearly see an opportunity to link the reputation, gained through some kind of contribution, to an economic reward. I know of a case where a manager had set aside 20% team bonus based on contribution to a group WIki as means to open up information and help others. It did work. However, I would be careful in setting up these kind of systems. The reward model, if not applied correctly, could backfire. But, on the other hand, it's a gamification element that holds significant potential. It'a dagger, use it carefully.

Balance simplicity and productivity:

Simplicity is one of the simplest (no pun intended) yet the most ignored and least understood gamification element. As I mentioned above, the systems that are designed for the perpetual intermediaries should be simple to get started. These systems could potentially get far more complex as you explore more and more features. But, there's another class of systems that people only occasionally use e.g. leave request, annual goal setting etc. It's far more important to keep these systems simple at all levels. Imagine the experience of going from one carnival stall to another and play all the games. You need very little or no instructions. These games at carnival are derived from a few basic games with a few twists, but these twists do not require people to go through a steep learning curve. That's how the applications that people rarely use should be designed; it should use the affordances and principles that the users have witnessed and experienced some place else and it should be broken down like carnival stalls to make the journey easy and fun.

The serious gamers prefer power over simplicity. They like to use shortcuts and a zillion combinations of all the keys on their consoles to get moving quickly inside the game. This is exactly the behavior of the power users of enterprise applications. An Accounts Receivables (AR) interface should not force an AR clerk to learn how to create an invoice every time she opens the application. She has learned the ropes and she expects to be productive and she wants to be faster and better than others. The tools should provide enough "power" features to such users to make them successful.

Photo credit: ccarlstead

Selling To Enterprise - Power Struggle Between IT And Line Of Business

During my several interactions with - CIOs, senior IT leaders, and Line of Business (LoB) heads - I have firsthand observed the power struggle between LoB and IT and a slow but continuous tarnish in their relationship due to cloud and SaaS offerings. IT and LoB work for the same company but they build their little and in some cases huge empires within a company. Even if the end goal of a company is to leverage technology to gain competitive advantage, they all have orthogonal goals that appear to be conflicting from the outside. In a negotiation, it's imperative to recognize that both parties never want the same thing. It's about getting to a deal that's a win-win situation. Regardless of the kind of ISV you represent and who the buyer is, I suggest you make the both - IT as well as LoB - work in your favor.

The ISVs that typically face these challenges fall into one of these three categories: 1) On-premise vendors that sell into IT find it difficult to compete against SaaS vendors selling similar solutions to LoBs 2) SaaS vendors that primarily sell into LoBs find it difficult to get pass IT 3) On-premise vendors aspiring to sell on-premise as well as their new SaaS solutions to LoBs find lack of relationship with LoBs challenging. Not only the ISVs need to understand which category they belong to, but they also need to understand the conflicting goals between LoB and IT and have a strategy and a solution to overcome that. It's not black and white and there's no prescriptive approach. It does vary across customers, their IT maturity, industries, and regions.

The LoB is always about time to value. They want a solution today and they want it now. This is the reason SaaS has a compelling value proposition - nothing to install, no software to purchase, and relatively shorter implementation cycle - to serve the LoBs. On the other hand, IT wants governance, risk management, and integration. They see SaaS solutions as silo one-off solutions popping up everywhere in the company, keeping the CIO up in the night. IT sees technology and LoB sees solutions. This is also a function of how IT operates. I have seen many different variations of the same thing. If you have a clear value proposition for LoB, do cater to them, but don't bypass IT. It's tempting, but don't do it, instead make them your friends. Bypassing IT might help in the short-term but eventually you will run into issues.

I would recommend a few things:

Help IT scale: If you believe that IT wants control and hence wants to do everything on their own, you're most likely wrong. It turns out that IT doesn't mind at all if business can perform certain functions in a self-service way, as long as the IT is ensured that they have underlying control over data and (on-premise) infrastructure. The private clouds are flourishing for very same reasons. This is great news for on-premise vendors that are struggling to sell into IT with dwindling budgets. Focus your innovation on simplifying IT landscapes and making on-premise deployments more self-service for LoBs. For SaaS vendors, this is where you win over the on-premise vendors by providing instant value to an LoB and giving IT control over data security, governance, and integration.

Don't compete based on price alone: I have heard many times that compete based on price and you will win, regardless of whether IT or LoB is a buyer. Competing based on price could be a good thing, but it's not everything. Personally, I have observed quite a few bake-off situations and learned that price alone does not determine the final outcome. The IT as well as LoB do look for things beyond a vendor offering a cheap solution. If you're expensive, you need to have an end-to-end value proposition that is far better than your competitor and if you're cheap, you have to be cheaper by a magnitude to the second cheapest competitor for a customer not to ignore you. Also, the on-premise and SaaS offerings have not-to-easy price comparison since they have different CapEX/OpEx models resulting into potentially different TCO for a customer.

Follow the money trail: IT and LoB have their own budgets. Traditionally, on average, IT spends 80% of their budget on "keeping the lights on". The rest is spent on "innovation" or "strategic projects". While this is a broad generalization, this could vary from customer to customer. The most progressive CIO that I have so far worked with has the exact opposite number - 80% on innovation. As a vendor, not only you need to understand who has the power to write a check, but which bucket has the most money left with the least hoops to jump through. In some cases, IT has chargeback (to business) models and LoB-sponsored projects. Follow the money trail and understand the aspirations on both sides and position your solution accordingly. If there's no pain, there's no gain. Spend time on finding the biggest pain-point and a budget to fix it instead of educating a customer that they may have a problem.

Happy selling!

Research Report: 2011 Cloud Computing Predictions For Vendors And Solution Providers

This blog post was jointly authored by @Chirag_Mehta (Independent Blogger On Cloud Computing) and @rwang0 (Principal Analyst and CEO, Constellation Research, Inc.)

Part 1 was featured on Forbes: 2011 Cloud Computing Predictions For CIO’s And Business Technology Leaders

As Cloud Leaders Widen The Gap, Legacy Vendors Attempt A Fast Follow

Cloud computing leaders have innovated with rapid development cycles, true elasticity, pay as you go pricing models, try before buy marketing, and growing developer ecosystems. Once dismissed as a minor blip and nuisance to the legacy incumbents, those vendors who scoffed cloud leaders now must quickly catch up across each of the four layers of cloud computing (i.e. consumption, creation, orchestration, and infrastructure) or face peril in both revenues and mindshare (see Figure 1). 2010 saw an about face from most vendors dipping their toe into the inevitable. As vendors lay on the full marketing push behind cloud in 2011, customers can expect that:

Figure 1. The Four Layers Of Cloud Computing

General Trends

• Leading cloud incumbents will diversify into adjacencies: The incumbents, mainly through acquisitions, will diversify into adjacencies as part of an effort to expand their cloud portfolio. This will result into blurry boundaries between the cloud, storage virtualization, data centers, and network virtualization. Cloud vendors will seek tighter partnerships across the 4 layers of cloud computing as a benefit to customers. One side benefit - partnerships serve as a pre-cursor to mergers and as a defensive position against legacy on-premises mega vendors playing catch up.
  
  
• Cloud vendors will focus on the global cloud: The cloud vendors who initially started with the North America and followed the European market, will now likely to expand in Asia and Latin America. Some regions such as Brazil, Poland, China, Japan, and India will spawn regional cloud providers. The result - accelerated cloud adoption in those countries, who resisted to use a non-local cloud provider. Cloud will prove to be popular in countries where software piracy has proven to be an issue.
  
  
• Legacy vendors without true Cloud architectures will continue to cloud wash with marketing FUD: Vendors who lack the key elements of cloud computing will continue to confuse the market with co-opted messages on private cloud, multi-instance, virtualization, and point to point integration until they have acquired or built the optimal cloud technologies. Expect more old wine (and vinegar, not balsamic but the real sour kind, in some cases) in new bottles: The legacy vendors will re-define what cloud means based on what they can package based on their existing efforts without re-thinking the end-to-end architecture and product portfolio from grounds-up.
  
  
• Tech vendors will make the shift to Information Brokers: SaaS and Cloud deployments provide companies with hidden value and software companies with new revenues streams. Data will become more valuable than the software code. Three future profit pools willl include benchmarking, trending, and prediction. The market impact - new service based sub-categories such as data-as-service and analysis-as-a-service will drive information brokering and future BPO models.

SaaS (Consumption Layer)

• Everyone will take the SaaS offensive: Every hardware and system integrator seeking higher profit margins will join the Cloud party for the higher margins. Software is the key to future revenue growth and a cloud offense ensures the highest degree of success and lowest risk factors. Hardware vendors will continue to acquire key integration, storage, and management assets. System integrators will begin by betting on a few platforms, eventually realizing they need to own their own stack or face a replay of the past stack wars.
• On-premise enterprise ISVs will push for a private cloud: The on-premise enterprise ISVs are struggling to keep up with the on-premise license revenue and are not yet ready to move to SaaS because of margin cannibalization fears,lack of scalable platforms, and a dirth of experience to run a SaaS business from a sales and operation perspectives. These on-premise enterprise software vendors will make a final push for an on-premise cloud that would mimic the behavior of a private cloud. Unfortunately, this will essentially be a packaging exercise to sell more on-premise software. This flavor of cloud will promise the cloud benefits delivered to a customer's door such as pre-configured settings, improved lifecycle, and black-box appliance. These are not cloud applications but will be sold and marketed as such.
• Money and margin will come from verticalized cloud apps: Last mile solutions continue to be a key area of focus. Those providers with business process expertise gain new channels to monetize vertical knowledge. Expect an explosion of vertical apps by end of 2011. More importantly, as the buying power shifts away from the IT towards the lines of businesses, highly verticalized solutions solving specific niche problems will have the greatest opportunities for market success.
• Many legacy vendors might not make the transition to cloud and will be left behind: Few vendors, especially the legacy public ones, lack the financial where with all and investor stomachs to weather declining profit margins and lower average sales prices. In addition, most vendors will not have the credibility to to shift and migrate existing users to newer platforms. Legacy customers will most likely not migrate to new SaaS offerings due to lack of parity in functionality and inability to migrate existing customizations.
• Social cloud emerges as a key component platform: The mature SaaS vendors that have optimized their "cloud before the cloud" platform, will likely add the social domain on top of their existing solutions to leverage the existing customer base and network effects. Expect to see some shake-out in the social CRM category. A few existing SCRM vendors will deliver more and more solutions from the cloud and will further invest into their platforms to make it scalable, multi-tenant, and economically viable. Vendors can expect to see some more VC investment, a possible IPO, and consolidation across all the sales channels.

DaaS & Paas (Creation and Orchestration Layers)

• Battle for PaaS begins with developers: Winning the hearts and minds will drive the key goals of PaaS providers. As mobile, social, and cloud intersect, expect new battle lines to be drawn by existing vendors seeking entry in the cloud. The first platform to enable write once deploy any how will win. PaaS vendors will seek to incorporate the latest disruptive technologies in order to attract the right class of developers and drive continuous innovation into the platform.
• Vendors must own the platform (both DaaS and Saas) to survive: ISV’s who give up on investing in their own cloud platform to other ISV’s will be relegated to second class citizens. Despite the tremendous upfront cost savings, these platform moves cut-off future revenue streams as the stack wars move to the cloud. For example, ISV’s will avoid Java to mitigate risk with Oracle or IBM. The ability to control information brokering services will be limited to the platform owner.
• Tension between indirect channel partners and vendors in the cloud will only increase: Cloud shifts customer account control to the vendor. Partners who wholeheartedly embrace the cloud risk losing direct relationships with their customers. In the case of .NET development in Azure, greater allegiance by partners to Microsoft will result in less account control with Azure.
• PaaS will be modularized and niche: New PaaS vendors will focus on delivering specific modules to compete with end-to-end application platforms. One approach - dominate niche areas int the cloud such as programming language runtimes, social media proxies, algorithmic SDK, etc. Expect more players to jump into fill big gaps in big data, predictive analytics and information management.
• Mobile app development will move to the cloud: App dev professionals and developers want one place to reach the mobile enterprise to build, mange, and deliver. The app dev life cycles will follow the delivery models and device management will prove to be the keystone in ensuring the complete development experience. Vendors should expect the cloud to be the predominant delivery channel for mobile apps to end users. Success will require seamless management of extensions and disconnected support.

IaaS (Infrastructure Layer)

• Cloud management will continue to grow and consolidate: Cloud management tools saw significant growth and investment in the last couple of years. This trend will continue. Expect to see a lot more investment in this category as increasing customer adoption drives demand for tools to manage hybrid landscapes. Also expect consolidation in this category as several VC-backed start-ups seek profitable and graceful exits.
• Cloud storage will be a hot cake: Explosive growths in information in many verticals for early adopters already factor into this fast-growing category. With more and more data moving to the cloud, customers can anticipate significant innovation in this category including SSD-based block storage, replication, security, alternate file systems, etc. Data-as-a-service and NoSQL PaaS category will further boost the growth.
• NoSQL will skyrocket in market share and acceptance: Substantial growth in the number of NoSQL companies reflect an emerging trend to dump the infrastructure of SQL for non-transactional applications. The cloud inherently makes a great platform for NoSQL and that further drives the growth for data-as-a-service and storage on the cloud.

The Bottom Line For Vendors (Sell Side)

Cloud ushers a new era of computing that will displace the existing legacy vendor hegemony. Many vendors caught off guard by the shift in both technology and user sentiment must quickly make strategic course corrections of face extinction. Here are some recommendations for vendors making the shift to Cloud:

1. Embrace, don't wait, don’t even hesitate: Which is worse; cannibalizing your margins or not having margins to cannibalize? Faster time to market and greater customer satisfaction will pay off. The move to cloud ensures a seat at the table for the next generation of computing.
2. Begin all new development projects in the cloud: The rapid development cycles for cloud projects ensures that innovation will meet today’s time to market standards. Test out new projects in the cloud and experience rapid provisioning and elasticity. However, don’t forget to fail fast and recover quickly.
3. Avoid investing in platform led apps: Apps should drive platform design not the other way around. Form really does follow function in the Cloud. Platform designs must focus on agility and scale. Apps prove out what’s really needed versus what’s theoretical. Plan for social, mobile, analytics, collaboration, and unified communications but deliver only when it makes business sense.
4. Focus on developers, developers, and developers: Steve Ballmer is right. Success in the cloud will require bringing the developers with along on the PaaS journey. Don't make them wait until the platform is done. Otherwise, it may be too late for the company and developer ecosystem.
5. Prioritize power usage effectiveness (PUEs): As with the factories during the last turn of century, IaaS will be the heart of delivery. Companies with the lowest cost of computing will win and be able to pass cost savings onto their customers or pocket the margin. Further, data center efficiencies do their part in green tech initiatives.
6. Help customers simplify their landscape: Build compelling business cases to shift from legacy infrastructure to cloud efficiencies. Lead the race to optimize legacy at your competitor’s expense.

Disclaimer: The views expressed in this post are mine and not of my current or past employers'. This is my independent blog.