cloud computing View RSS

When I decided to leave SAP to take a short sabbatical I didn’t really know what to expect. Six months later I am happy to report that it was one of the best decisions I ever made. These were some of the best weeks and months of my life. After this short period of disconnecting to recharge and rejuvenate myself I am reconnecting to the professional world. I have accepted an offer with Google to lead the API Ecosystem for Google Cloud to help drive adoption and monetization of the Google Cloud portfolio of platform and products, at scale, by working with various partners as well as coordinating efforts internally at Google with product management and engineering.

As I disconnected I felt the life slowed down and I had more time on hands and a fewer things to do. I met with many people during my sabbatical to learn from them and bounce off my thoughts. We tend to postpone taking certain decisions and don’t spend a lot of time thinking about many things in life, personal as well as professional, simply because we are compressed on time and each task, activity, or a decision only gets a fraction of overall available time we have. I tried hard not to work hard. Just slowing down and soaking it all in helped clear up many things. Taking time off also helped me prioritize what I really wanted to do. I am a big believer in unstructured free time where there is nothing planned ahead of time; wake up and take each day as it goes. I enjoyed doing mundane tasks and that took my attention off a typical rapid life of a technologist in the Silicon Valley. I would highly encourage you to take a short sabbatical in your career if the circumstances allow you to do so.

To a lifelong learner and a “product" person nothing excites me more than immersing myself into breadth of possible opportunities at the intersection of technology and business to create meaningful impact at Google. I have always admired Google for its ability to take risk by going after some of the hardest problems that require massive scale, foster innovation, and embrace failure as part of its culture. I have always been impressed with the talent Google manages to hire and retain. I am looking forward to be surrounded by people much smarter than me and learn from them. It’s going to be an exciting ride!

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.     

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

I am a big fan of Bill Walsh and his management philosophy. Following is an excerpt from his book The Score Takes Care Of Itself.

To promote sales of season tickets, I came up with an ambitious (and time-consuming) plan called “Pick-a-Seat Day” in which we put bright red ribbons on all available season ticket seats and invited the public to buy their favorites. And that’s not all. 

On the big promotion day we offered balloons, free donkey rides, ethnic foods, and clowns for the kiddies. Also, free popcorn, soft drinks and hot dogs, jugglers, a Dixieland band, and magicians. It was really a great family event for the thousands of folks who came out to Candlestick Park.

The next morning I arrived at the office early to see what the results of my “Pick-a-Seat Day” promotion were. Or, more accurately, weren’t. Total season tickets sold: seven. (I bought three more myself on the fifty-yard line, just so I could report that we’d hit double digits. In fact, our family still has those seats.) 

“Pick-a-Seat Day” was a total flop, but it was a flop that taught me something very important: A pretty package can’t sell a poor product. Results— in my profession, winning football games— are the ultimate promotional tool. I was trying to sell a bad product, a team that was the worst franchise in sports, that had lost twenty-seven straight road games, and whose record at home wasn’t much better. 

From that point on, I focused my energies exclusively on creating a quality product, a team that was worth spending money to see. When that was achieved, we also achieved a ten-year waiting list to buy a 49ers’ season ticket. 

In your efforts to create interest in your own product, don’t get carried away with premature promotion— creating a pretty package with hype, spin, and all the rest. First, make sure you’ve got something of quality to promote. Then worry about how you’re going to wrap it in an attractive package. The world’s best promotional tool is a good product.

I see this as a chronic problem in the software industry and many product marketing managers make it even worse. They tend to impose their own belief system in isolation while marketing to prospects without championing product and customer views as well as ignoring competition and where the product fits in the market. Over a period of time I have learned a few lessons observing and woking with them as well as being one of them for some part of my work.

Amplify the value proposition, don’t recreate it: One of the most common mistakes I observe product marketing managers make is to recreate value proposition of a product instead of amplifying it. A lot goes into making a great product - finding the end user needs, designing compelling experiences, and enabling them with technology. Product managers and engineers spend a lot of time making great products. Don’t reinvent the wheel; it’s precisely those stories and the unique characteristics of the product you want to amplify. As a product marketing manager your job is to tell great stories and not to rewrite them. Find the right medium and use it to your own advantage. Get customers excited and help them see the possibilities.

Sell the problem, not the solution: I have seen people focus on a very narrow definition of competitive differentiation, pricing and positioning. It’s not just about pricing and positioning; customers shop in categories for a specific set of problems or challenges they may have. As a vendor you need to have empathy for your customers on their buying process. Spending time articulating how your products solve their problems is far more important than outlining features and outsourcing the task of matching features with JTBD of your customers. Product marketing managers tend to fixate on what they are selling as opposed to what customers are buying.

Apple commercials are a great example of bringing products to life in scenarios and stories without marketing a product feature-by-feature. These commercials are designed to emotionally connect with consumers in their lives on why they need to buy Apple products and what they might use them for. Communicating with buyers on how you understand their problems is far more important than telling them they can do whatever they want with your products. This is especially hard when you’re selling technology and what customers are buying is a solution.

You need to understand the market, competition, and customers, not in isolation, but how they move with each other. Most product marketing managers I have seen take either a market view and force products to customers or take a customer view in justifying how it meets demands of the customers, but fail miserably articulating how their products fit in the market with the competition because they ignore the market. You have to do both. You could decide to ignore what you don’t prefer but your prospects won’t.

Focus on what customers are buying and not what you’re selling: Most successful go-to-market strategies are the ones that are profoundly simple. I have observed product marketing managers fail at one of the most basic tasks to ensure the prospects understand what they are buying. With complicated pricing, packaging, and a combination of deployment options, more often than not, customers are confused about what they are buying even if a product could potentially solve their problems. This confusion creates friction and customers end up buying what they understand in simple terms and that may not be your product even if it is superior to your competition. If you can’t simplify the value proposition in simple English without any jargon and offer an extremely clear explanation of what they are buying and how they can operationalize it with the lowest time to the highest value you’re not doing your job well.

Leverage irrationality: Software is rational, human beings are not. I have seen product marketing managers take a classical demand-supply economics as their go-to-market basis. They strongly feel that the product (supply) should somehow fit into an existing need (demand). While, to large extent, I do hope product managers (and not product marketing manages) are looking at those opportunities, but not all products are designed that way. It’s your job to tap into this very irrationality, the behavioral economics, to create demand for the product. Make customers want your products and not just need them. Better understand behavioral economics to decide how you will market the product, how you will package it, and how you will sell it. Customers don’t make decisions based on the product merit alone; good sales people know this and they leverage these aspects in their sales cycle. What I find strange, especially in enterprise software, is that product marketing managers stay oblivious to the fact that customers don’t always make rational choices. Perhaps it’s the formal business education or the “knowledge curse” that gets in their way and they overthink a human behavior situation and make it an economics issue.

Footnote: This is not an attempt to stereotype all product marketing managers and make them look stupid. In fact I have met and worked with some really bright product marketing manager. This is simply an attempt to outline how they might be able to channel some of their energy in a different way to be more effective in certain situations.

It has happened again. Researchers have discovered that Google’s ad-targeting system is discriminatory. Male web users were more likely to be shown high paying executive ads compared to female visitors. The researchers have published a paper which was presented at the Privacy Enhancing Technologies Symposium in Philadelphia.

I had blogged about the dark side of Big Data almost two years back. Latanya Sweeney, a Harvard professor Googled her own name to find out an ad next to her name for a background check hinting that she was arrested. She dug deeper and concluded that so-called black-identifying names were significantly more likely to be the targets for such ads. She documented this in her paper, Discrimination in Online Ad Delivery. Google then denied AdWords being discriminatory in anyway and Google is denying to be discriminatory now.

I want to believe Google. I don’t think Google believes they are discriminating. And, that’s the discriminatory dark side of Big Data. I have no intention to paint a gloomy picture and blame technology, but I find it scary to observe that technology is changing much faster than the ability of the brightest minds to comprehend the impact of it.

A combination of massively parallel computing and sophisticated algorithms to leverage this parallelism as well as ability of algorithms to learn and adapt without any manual intervention to be more relevant, almost in real-time, are going to cause a lot more of such issues to surface. As a customer you simply don't know whether the products or services that you are offered or not at a certain price is based on any discriminatory practices. To complicate this further, in many cases, even companies don't know whether insights they derive from a vast amount of internal as well as external data are discriminatory or not. This is the dark side of Big Data.

The challenge with Big Data is not Big Data itself but what companies could do with your data combined with any other data without your explicit understanding of how algorithms work. To prevent discriminatory practices, we see employment practices being audited to ensure equal opportunity and admissions to colleges audited to ensure fair admission process, but I don't see how anyone is going to audit these algorithms and data practices.

Disruptive technology always surfaces socioeconomic issues that either didn't exist before or were not obvious and imminent. Some people get worked up because they don't quite understand how technology works. I still remember politicians trying to blame GMail for "reading" emails to show ads. I believe that Big Data is yet another such disruption that is going to cause similar issues and it is disappointing that nothing much has changed in the last two years.

It has taken a while for the Internet companies to figure out how to safeguard our personal data and they are not even there, but their ability to control the way this data could get used is very questionable. Let’s not forget data does not discriminate, people do. We should not shy away from these issues but should collaboratively work hard to highlight and amplify what these issues might be and address them as opposed to blame technology to be evil.

Photo courtesy: Kutrt Bauschardt

I have worked with numerous leaders at all levels and have seen the best and worst practices in how they delegate or they don’t. Here are my 10 principles of delegation that I practice and advocate based on the lessons I have learned by being on both ends of the spectrum.

1. Delegating is not simply about asking someone to do something for you; it’s about setting expectations on desired outcome and offering to help.

2. Delegating does not mean being a slacker but shifting focus instead on right things; as a leader, more often than not, doing right things is more important than doing things right.

3. Delegating something that you typically won’t is the best way to empower your employees; all other empowering talk is cheap.

4. Never take credit for what you delegate; in fact never take credit for anything that you accomplish.

5. Delegation leads to transparency; most employees struggle to get a bigger picture and don’t have insights into what their managers do.

6. Don't say, “I trust you,” instead delegate a task where an employee understands she would not have gotten an opportunity to work on it unless the manager had her trust.

7. Put yourself in the shoes of whom you are delegating to; manage their concerns, emotions, and challenges instead of yours.

8. If afraid of delegating a task imagine the worst case scenario before you delegate it and mitigate the situation by setting expectations and periodically monitoring the progress to make you comfortable delegate.

9. If still afraid of delegating unpack the task into sub-tasks and start with delegating the first sub-task; it’s always the first step that is incredibly hard to take.

10. Share with your employees what you don’t want to delegate; help them build empathy for what you do and motivate them to step up for that task the next time.

Photo courtesy: tanakawho

A framework that I use to think about problems disruptive technology could help solve is based on what Donald Rumsfeld wrote in his memoir, Known and Unknown:

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.

A couple of decades ago technology was seen as means to automate manual processes and bring efficiency. While largely automation is a prerequisite in the modern economy the role of technology has significantly changed to create unique differentiation and competitive advantage against peers in an industry. Many people are working on making things betters, cheaper, and faster or a combination of these three. This approach—solving known known—does provide incremental or evolutionary innovation and market does reward it.

But, the Silicon Valley thinks differently.

The Silicon Valley loves to chase known unknown problems, the moonshots, such as self-driving vehicles, providing internet access to every single human being on the earth, and private shuttles to space. These BHAG are totally worth chasing. To a certain degree, we do know and experience what the actual problem is and we can even visualize what a possible solution could look like. As counterintuitive as it may sound, but it is relatively easy to have entrepreneurs and investors rally towards a solution if they can visualize an outcome even if solving a problem could mean putting in a monumental effort.

"We can be blind to the obvious, and we are also blind to our blindness.” - Daniel Kahneman

Most disruptive products or business models have a few things in common: they focus on latent needs of customers, they imagine new experiences and deliver them to customers, and most importantly they find and solve problems people didn’t know they had and couldn’t imagine it could be solved - the unknown unknown.

Chasing unknown unknown requires bold thinking and a strong belief in you quest and methods to get there. Traditional analytical thinking will take you to the next quarter or the next year with a double digit growth but won’t bring exponential growth. These unknown problems excite me the most and I truly enjoy working on them. Unknown unknown is the framework that I use to understand the potential of disruptive technology such as Big Data and Internet of Things. If technology can solve any problem which problem you want to have it solved is how I think.

Chasing unknown unknowns is not an alternative to go for moonshots; we need both and in many cases solving an unknown unknown journey starts by converting it to a known unknown. The key difference between the two is where you spend your time -  looking for a problem and reframing it or finding a breakthrough innovation for a known corny problem. A very small number of people can think across this entire spectrum; most people are either good at finding a problem or solving it but not at both.

Discovering unknown problems requires a qualitative and an abductive approach as well as right set of tools, techniques, and mindset. Simply asking people what problems they want to have it solved they don’t know they have won’t take you anywhere. I am a passionate design thinker and I practice and highly encourage others to practice qualitative methods of design and design thinking to chase unknown unknowns.

I wish, as Silicon Valley, we don’t lose the spirit of going after unknown unknown since it is hard to raise venture capital and rally people around a problem that people don’t know exist for sure. Empowering people to do things they could not have done before or even imagined they could do is a dream that I want entrepreneurs to have.

Photo courtesy: Ahmed Rabea

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  

A lorry is a symbol of Indian logistics and the person who is posing against it is about to rethink infrastructure and logistics in India. Jeff Bezos is enjoying his trip to India charting Amazon’s growth plan where competitors like Flipkart have been aggressively growing and have satisfied customer base. This is not the first time Bezos has been to India and he seems to understand Indian market far better than many CEOs of American companies. His interview with a leading Indian publication didn’t get much attention in the US where he discusses Amazon’s growth strategy in India.

When asked whether he is in panic mode:

For 19 years we have succeeded by staying heads down, focused on our customers. For better or for worse, we spend very little time looking at our competitors. It is better to stay focused on customers as they are the ones paying for your services. Competitors are never going to give you any money.

I always believe in focusing on customers, especially on their latent unmet needs. Many confuse not focusing on competitors as not competing. That’s not true at all. Compete hard in the market but define your own rules and focus on your customers. Making noise about your competitors and fixating on their strategies won’t take you anywhere.

But there's also some opportunity to build infrastructure from scratch. When you think of facilitation commerce between small shops and the end-consumer there would be things you would build - I don't know what they are, we will have to invent some of these things - that you might not build in other geographies where infrastructure grew for different purposes.

All emerging economies are different and India is a very different market. Bezos does seem to comprehend that. Things that you take for granted and things that you would invest into in the western countries are vastly different in India. Amazon has a great opportunity to rethink logistics and infrastructure.

The three things that I know for sure the Indian customer will still want 10 years from now: vast selection, fair, competitive prices and faster, reliable delivery. All the effort we put into adding energy into our delivery systems, reducing defects and making the customer experience better, I know those things will be appreciated 10 years from now. We could build a business strategy around that.

Innovating doesn’t mean reinventing strategy, the "what." What holds true in the US is likely hold true in India as well. It’s the execution—the “how”—will be different.

Speaking of Amazon as a growth company:

I like a quote from Warren Buffet who famously said: You can hold a ballet and that's okay and you can hold a rock concert and that's okay. Just don't hold a ballet and advertise it as a rock concert. Are we holding a ballet or are we holding a rock concert? Then, investors get to select. They know we have a long-term viewpoint. They know that we take cash flow that gets generated from our successful businesses and invest in new opportunities. India is a great example of that happening.

Even though Amazon has been in business for a long time with soaring revenue in mature categories the street sees it as a high growth company and tolerates near zero margin and surprises that Jeff Bezos brings in every quarter. Bezos has managed to convince the street that Amazon is still in heavy growth mode and hasn't yet arrived. In short term you won’t see Amazon slowing down. They will continue to invest their profit in their future to build even bigger businesses instead of paying it out to investors.

When asked whether Google is Amazon’s biggest rival:

I resist getting in to that kind of conversation because it is not how I think about our business. There are companies who in their annual planning process literally start with: Who are our three biggest competitors? And they'll write them down. This is competitor number one, two and three. Then they'll develop strategies for each of them. That's not how our annual planning is done. We do have an annual planning process and actually we are right in the middle of it now. We start with,`What'll we deliver to our customers? What are the big ideas, themes?'

Amazon has innovated by focusing on what customers really care about and not what the competitors do. This approach has paid off and I can see why Bezos is keen to do the same in the Indian market.

I really liked what he said when asked about being gifted and being kind:

I believe that humans would achieve anything that we are determined to achieve, if we work hard. So, celebrate your gifts but you can only be proud of your choices. And, cleverness is gift. You cannot become Einstein no matter how much you work. You have to really decide on how you're going to make choices in your life. You get to decide to be a good husband and a good father.

I strongly believe in why making right choices is more important than being gifted. I share this with as many people as I can and I also tell them, “you control your effort and not the outcome.”

Photo courtesy: Times of India

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 

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

The flow, a concept developed by one of my favorite psychologists, Mihaly Csikszentmihalyi, matches the popular performance versus potential matrix that many managers use to evaluate and calibrate their employees. For people to be in the flow they need to be somewhere in the middle moving diagonally up. Ideally, this is how employees should progress in their careers but that always doesn't happen. To keep employees in the flow you want to challenge them enough so that they are not bored but you don't want to put them in a situation where they can't perform and are set up for a failure.

Despite of this framework being used for a long period of time I see many organizations and managers continue to make these three mistakes:

Mistaking potential for performance

Performance, at the minimum, is about given skills and experience how effectively person accomplishes his or her goals. Whereas potential is about what person could do if the person could a) acquire skills b) gain access to more opportunities c) get mentoring. We all have seen under-performers who have more potential. In my experience, most of these people don't opt to underperform but they are put in a difficult situation they can't get out of. We routinely see managers not identifying this as a systemic organizational problem but instead shift blame to employees confusing potential for performance suggesting to them, "you could have done so much but you didn't; you're a slacker." A similar employee with equal performance but less potential would not receive the same remarks on his/her performance.

Treating potential as an innate fixed attribute

One of the biggest misconceptions I come across is managers looking at potential as innate fixed attribute. Potential is a not a fixed attribute; it is something that you help people develop.

These out-performers who are not labelled as "high potential" are mostly rewarded with economic incentives but they don't necessarily get access to opportunities and mentoring to rise above their work and a chance to demonstrate their potential and make a meaningful impact.

Fixating on hi-potential out-performers

Not only managers fixate on hi-potential out-performers but they are also afraid that these employees might leave the organization one day if they have no more room to grow and if they run out of challenges. As counterintuitive as it may sound this is not necessarily a bad thing.

We all live in such a complex ecosystem where retaining talent is not a guarantee. The best you can do is develop your employees, empower them, and give them access to opportunities so that they are in a flow. As a company, create a culture of loyalty and develop your unique brand where employees recognize why working for you is a good thing. If they decide to leave you wish them all the best and invest in them: fund their start-up or make them your partners. This way your ecosystem will have fresh talent, place for them to grow, and the people who leave you will have high level of appreciation for your organization. But, under no circumstances, ignore the vast majority of other employees who could out-perform at high potential if you invest into them.

Joey Votto is one of the best hitters in the MLB who plays for Cincinnati Reds. Lately he has received a lot of criticism for not swinging on strikes when there are runners on base. Five Thirty Eight decided to analyze this criticism with the help of data. They found this criticism to be true; his swings at strike zone pitches, especially fastballs, have significantly declined. But, they all agree that Votto is still a great player. This is how I see many Big Data stories go; you can explain "what" but you can't explain "why." In this story, no one actually went (that I know) and asked Votto, "hey, why are you not swinging at all those fastballs in the strike zone?"

This is not just about sports. I see that everyday in my work in enterprise software while working with customers to help them with their Big Data scenarios such as optimizing promotion forecast in retail, predicting customer churn in telco, or managing risk exposure in banks.

What I find is as you add more data it creates a lot more noise in these quantitative analysis as opposed to getting closer to a signal. On top of this noise people expect there shall be a perfect model to optimize and predict. Quantitative analysis alone doesn't help finding a needle in haystack but it does help identify which part of haystack the needle could be hiding in.

"In many walks of life, expressions of uncertainty are mistaken for admissions of weakness." - Nate Silver

I subscribe to and strongly advocate Nate Silver's philosophy to think of "predictions" as a series of scenarios with probability attached to it as opposed to a deterministic model. If you are looking for a precise binary prediction you're most likely not going to get one. Fixating on a model and perfecting it makes you focus on over-fitting your model on the past data. In other words, you are spending too much time on signal or knowledge that already exists as opposed to using it as a starting point (Bayesian) and be open to run as many experiments as you can to refine your models as you go. The context that turns your (quantitative) information into knowledge (signal) is your qualitative aptitude and attitude towards that analysis. If you are willing to ask a lot of "why"s once your model tells you "what" you are more likely to get closer to that signal you're chasing.

Not all quantitative analyses have to follow a qualitative exercise to look for a signal. Validating an existing hypothesis is one of the biggest Big Data weapons developers use since SaaS has made it relatively easy for developers to not only instrument their applications to gather and  analyze all kinds of usage data but trigger a change to influence users' behaviors. Facebook's recent psychology experiment to test whether emotions are contagious has attracted a lot of criticism. Keeping ethical and legal issues, accusing Facebook of manipulating 689,003 users' emotions for science, aside this quantitative analysis is a validation of an existing phenomenon in a different world. Priming is a well-understood and proven concept in psychology but we didn't know of a published test proving the same in a large online social network. The objective here was not to chase a specific signal but to validate a hypothesis— a "what"—for which the "why" has been well-understood in a different domain.

About the photo: Laplace Transforms is one of my favorite mathematical equations since these equations create a simple form of complex problems (exponential equations) that is relatively easy to solve. They help reframe problems in your endeavor to get to the signal.

Google has published a paper outlining their approach on using machine learning, a neural network to be specific, to reduce energy consumption in their data centers. Joe Kava, VP, Data Centers at Google also has a blog post explaining the backfround and their approach. Google has one of the best data center designs in the industry and takes their PUE (power usage effectiveness) numbers quite seriously. I blogged about Google's approach to optimize PUE almost five years back! Google has come a long way and I hope they continue to publish such valuable information in public domain.



There are a couple of key takeaways.

In his presentation at Data Centers Europe 2014 Joe said:  

As for hardware, the machine learning doesn’t require unusual computing horsepower, according to Kava, who says it runs on a single server and could even work on a high-end desktop.

This is a great example of a small data Big Data problem. This neural network is a supervised learning approach where you create a model with certain attributes to assess and fine tune the collective impact of these attributes to achieve a desired outcome. Unlike an expert system which emphasizes an upfront logic-driven approach neural networks continuously learn from underlying data and are tested for their predicted outcome. The outcome has no dependency on how large your data set is as long as it is large enough to include relevant data points with a good history. The "Big" part of Big Data misleads people in believing they need a fairly large data set to get started. This optimization debunks that myth.

The other fascinating part about Google's approach is not only they are using machine learning to optimize PUE of current data centers but they are also planning to use it to effectively design future data centers.

Like many other physical systems there are certain attributes that you have operational control over and can be changed fairly easily such as cooling systems, server load etc. but there are quite a few attributes that you only have control over during design phase such as physical layout of the data center, climate zone etc. If you decide to build a data center in Oregon you can't simply move it to Colorado. These neural networks can significantly help make those upfront irreversible decisions that are not tunable later on.

One of the challenges with neural networks or for that matter many other supervised learning methods is that it takes too much time and precision to perfect (train) the model. Joe describing it as a "nothing more than series of differential calculus equations " is downplaying the model. Neural networks are useful when you know what you are looking for - in this case to lower the PUE. In many cases you don't even know what you are looking for.

Google mentions identifying 19 attributes that have some impact on PUE. I wonder how they short listed these attributes. In my experience unsupervised machine learning is a good place to short list attributes and then move on to supervised machine learning to fine tune them. Unsupervised machine learning combined with supervised machine learning can yield even better results, if used correctly.

I have worked with many product managers on a product vision exercise. In my observation the place where the product managers get hung up the most is when they confuse product vision for product definition. To use an analogy, product vision is a trailer and product definition is a movie. When you're watching a movie trailer it excites you even though you fully don't know how good or bad the movie will be.

Abstract and unfinished

A trailer is a sequence of shots that are abstract enough not to reveal too much details about the movie but clear enough to give you the dots that your imagination could start connecting. Some of the best visions are also abstract and unfinished that leave plenty of opportunities for imagination. Product visions should focus on "why" and "what" and not on "how" and most importantly should have a narrative to excite people to buy into it and refine it later on. Vision should inspire the definition of a product and not define it.

I am a big believer of raw or low fidelity prototypes because they allow me to get the best possible feedback from an end user. People don't respond well to a finished or a shiny  prototype. I don't want people to tell me, "can you change the color of that button?" I would rather prefer they say, "your scenario seems out of whack but let me tell you this is what would make sense."

Non-linear narratives

Movie trailers are also the best examples of non-linear thinking. They don't follow the same sequence as a movie - they don't have to. Most people, product managers or otherwise, find non-linear thinking a little difficult to practice and comprehend. Good visions are non-linear because they focus on complete narrative organized as non-linear scenarios or journeys to evoke emotion and not to convey how the product will actually work. Clever commercials, such as iPad commercials by Apple, follow the same design principles. They don't describe what an iPad can do feature by feature but instead will show a narrative that help people imagine what it would feel like to use an iPad.

Means to an end

The least understood benefit of a product vision is the ability of using the vision as a tool to drive, define, and refine product requirements. Vision is a living artifact that you can pull out anytime during your product lifecycle and use it to ask questions, gather feedback, and more importantly help people imagine. I encourage product managers not to chase the perfection when it comes to vision and focus on the abstract and non-linear journey because a vision is a means to an end and not an end itself.

Photo courtesy: Flickr 

Recently Google slashed price for their cloud offering. Amazon, as expected, also announced their 42nd price reduction on their cloud offerings since its inception. Today, Microsoft also announced price reduction for their Azure offerings.

Unlike many other people I don't necessarily see the price reduction by Amazon as waging a price war against the competition.

Infrastructure as true commodity: IaaS is a very well understood category and Amazon, as a vendor, has strong desires to move up in the value chain. This can only happen if storage and computing become true commodity and customers value vendors based on what they can do on top of this commodity storage and computing. They become means to an end and not an end itself.

Amazon is introducing many PaaS like services on top of EC2. For example, RedShift is the fastest growing service on EC2. These services create stickiness for customers to come back and try out and perhaps buy other services. These services also create a bigger demand for the underlying cloud platform. Retaining existing customers and acquiring new customers with as little barrier as possible are key components of this strategy.

Reducing hardware cost: The hardware cost associated with computing and storage have gradually gone down. Speaking purely from financial perspective existing assets depreciate before they are taken out from service. Also, new hardware is going be cheaper than the old hardware (at the original cost). If you do pass on the cost advantage to your customers it should help you reduce price and compete at the same or a little less margin. However, hardware cost is a fraction of overall operations cost. In the short term, Amazon being a growth company will actually spend a lot more on CapEx and not just OpEx to invest and secure the future.

Economies of scale: The cost to serve two computing units is not the sum of cost to serve two one computing units. There are many economies of scales in play such as increasing data-center utilization, investment in automation, and better instance management software. Confidence in predicting minimum base volume and reducing fluctuations also gives Amazon better predictability to manage elasticity. As the overall volume goes up the elasticity or the fluctuations as percentage of overall volume go down. On top of that offerings such as Reserved Instances also are a good predictor of future demand. Amazon views Reserved Instances as how banks view CDs but many customers are looking for a "re-finance" feature for these Reserved Instances when price drops. These economic and pricing implications are great to watch.

To offer competitive pricing to win against  incumbents and make it almost impossible for new entrants to compete on the same terms is absolutely important but it would be foolish to assume it is the sole intent behind the price reduction.

Photo courtesy: Flickr

For an ISV (Independent Software Vendor) it is everyone's job to ensure customer success but it is no one person's job. This is changing. I see more and more companies realizing this challenge and want to do something about it.

Sales is interested in maintaining relationship with customers for revenue purposes and support works with customers in case of product issues and escalations. Product teams behave more like silos when they approach their customers because of their restricted scope and vision. Most chief technology officers are fairly technical and internal facing. Most of them also lack the business context—empathy for true business challenges—of their customers. They are quite passionate about what they do but they invariably end up spending a lot of time in making key product and technical decisions for the company losing sight of much bigger issues that customers might be facing. Most chief strategy officers focus on company's vision as well as strategy across lines of businesses but while they have strong business acumen they are not customer-centric and lack technical as well as product leadership to understand deep underlying systemic issues.

Traditional ways to measure customer success is through product adoption, customer churn, and customer acquisition but the role of a Chief Customer Success Officer (CCO) extends way beyond that. One of the best ways to watch early signs of market shift is to very closely watch your progressive customers. Working with these customers and watching them will also help you find ways to improve existing product portfolio and add new products, organically or through acquisitions. Participating in sales cycles will help you better understand the competition, pricing points, and most importantly readiness of your field to execute on your sales strategy.

I often get reached out by folks asking what kind of people they should be looking for when they plan to hire a CCO. I tell them to look for the following:

T-shaped: Customer don't neatly fall into your one line of business and so is your CCO. You are looking for someone who has broad exposure and experince across different functions through his or her previous roles and deep expertise in one domain. The CCO would work across LoBs to ensure customers are getting what they want and help you build a sustainable business. Most T-shaped people I have worked with are fast-learners. They very quickly understand continuously changing business, frame their point of view, and execute by collaborating with people across the organization (the horizontal part of T) due to their past experience and exposure in having worked with/for other functions.

Most likely, someone who has had a spectacular but unusual career path and makes you think, "what role does this person really fit in?" would be the the right person. Another clue: many "general managers" are on this career track.

Business-centric: Customers don't want technology. They don't even want products. They want solutions for the business problems they have. This is where a CCO would start with sheer focus on customers' problems—the true business needs—and use technology as an enabler as opposed to a product. Technology is a means to an end typically referred to as "the business."

Your CCO should have a business-first mindset with deep expertise in technology to balance what's viable with what's feasible. You can start anywhere but I would recommend to focus your search on people who have product as well as strategy background. I believe unless you have managed a product—development, management, or strategy—you can't really have empathy for what it makes to build something and have customers to use it and complain about it when it doesn't work for them.

Global: Turns out the world is not flat. Each geographic region is quite different with regards to aptitude and ability of customers to take risk and adopt innovation. Region-specific localization—product, go-to-market, and sales—strategy that factors in local competition and economic climate is crucial for global success of an ISV. The CCO absolutely has to understand intricacies associated with these regions: how they move at different speed, cultural aspects of embracing and adopting innovation, and local competition. The person needs to have exposure and experience across regions and across industries. You do have regional experts and local management but looking across regions to identify trends, opportunities, and pace of innovation by working with customers and help inform overall product, go-to-market, and sales strategy is quite an important role that a CCO will play.

Outsider: Last but not least, I would suggest you to look outside instead of finding someone internally. Hiring someone with a fresh outside-in perspective is crucuial for this role. Thrive for hiring someone who understands the broader market - players, competition, and ecosystem. This is a trait typically found in some leading industry analysts but you are looking for a product person with that level of thought leadership and background without an analyst title.

About the photo: This is a picture of an Everest base camp in Tibet, taken by Joseph Younis. I think of success as a progressive realization of a worthwhile goal.

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.

My brother is an ophthalmologist in a small town in India. In his private practice, patients have two options to see him: either take an appointment or walk in. Most patients don't take an appointment due to a variety of cultural and logistics reasons and prefer to walk in. These patients invariably have to wait anywhere from 15 minutes to an hour and half on a busy day. I always found these patients to be anxious and unhappy that they had to wait, even if they voluntarily chose to do so. When I asked my brother about a possible negative impact due to unhappiness of his patients (customers) he told me what matters is not whether they are unhappy while they wait but whether they are happy or not when they leave. Once these patients get their turns to see my brother for a consultation, which lasts for a very short period of time compared to how much they waited, my brother will have his full attention to them and he will make sure they are happy when they leave. This erases the unpleasant experience from their minds that they just had it a few minutes back.

I was always amused at this fact until I got introduced to the concept of experience side versus memory side by my favorite psychologist Daniel Kahneman, explained in his book Thinking, Fast and Slow and in his TED talk (do watch the TED talk, you won't regret it). While the patients waited the unpleasant experience was the experience side which they didn't remember and the quality time they spent in the doctor's office was the memory side that they did remember.


Airlines, hotels, and other companies in service sectors routinely have to deal with frustrated customers. When customers get upset they won't remember series of past good experiences they had but they would only remember how badly it ended - a cancelled flight, smelly hotel room or production outage resulting in an escalation. Windows users always remember the blue screen of death but when asked they may not necessarily remember anything that went well on a Windows machine prior to a sudden crash resulting into the blue screen of death. The end matters the most and an abrupt and unrecoverable crash is not a good end. If the actual experience matters people will perhaps never go back to a car dealership. However people do remember getting a great deal in the end and forget the misery that the sales rep put them through by all the haggling.

Proactive responses are far better in crisis management than reactive ones but reactive responses do not necessarily have to result in a bad experience. If companies do treat customers well after a bad experience by being truly apologetic, responsive, and offering them rewards such as free upgrades, miles, partial refund, discounts etc. people do tend to forget bad experiences. This is such a simple yet profound concept but companies tend not to invest into providing superior customer support. Unfortunately most companies see customer support as cost instead of an investment.

This is an important lesson in software design for designers and product managers. Design your software for graceful failures and help people when they get stuck. They won't tell you how great your tool is but they will remember how it failed and stopped them from completing a task. Keep the actual user experience minimal, almost invisible. People don't remember or necessary care about the actual experiences as long as they have aggregate positive experience without hiccups to get their work done. As I say, the best interface is no interface at all. Design a series of continuous feedback loops at the end of such minimal experiences—such as the green counter in TurboTax to indicate tax refund amount—to reaffirm positive aspects of user interactions; they are on the memory side and people will remember them.

In enterprise software, some of the best customers could be the ones who had the worst escalations but the vendors ended their experience on a positive note. These customers do forgive vendors. As a vendor, a failed project receives a lot worse publicity than a worst escalation that could have actually cost a customer a lot more than a failed project but it eventually got fixed on a positive note. This is not a get-out-of-jail-free-card to ignore your customers but do pause and think about what customers experience now and what they will remember in future.

Photo courtesy: Derek 

I am a big fan of software design patterns. A design pattern is a general reusable solution to a commonly occurring problem within a given context. Software design patterns are all about observing technical abstractions in complex problems by identifying patterns and applying well known solutions to them.

My management style is largely based on abstractions. When things get muddy I step away from complexity for a few minutes and explore abstractions. This helps me keep in touch with the bigger picture while I look for solutions to a given problem. When you're too close to a topic you do tend to fixate on complexity leaving sight of the bigger picture. I make a conscious attempt to go between complexity and abstraction when I need to. And, that's perhaps the only way to manage it effectively in pursuit of working smart and not just working hard. Complexity invariably makes people get into an analysis paralysis mode resulting into a decision gridlock that affects the bigger picture. In many cases, not being able to make a decision has far worse consequences than not solving a problem which may or may not be important in long run. Abstracting complexity helps me make a decision with focus on consequences as opposed to a short term solution. Abstraction also allows me to spot behavioral and systemic problems as opposed to tactical and temporal problems.

Ask yourself what you remember the most about a couple of complex problems that you solved last year and the answer most likely won't be how great your solution was but it very well would be what the problem actually taught you. It's not the complexity that you will cherish but the simplicity, the abstracted experience, is what will stay with you for the rest of your life to help you find solutions to similar problems in future.

Photo courtesy: miuenski 

As more and more on-premise software vendors begin their journey to become SaaS vendors they are going to face some obvious challenges. Here's my view on what they might be.

The street is mean but you can educate investors

Sharp contrast between Amazon and Apple is quite clear. Even though Amazon has been in business for a long time with soaring revenue in mature categories the street sees it as a high growth company and tolerates near zero margin and surprises that Jeff Bezos brings in every quarter. Bezos has managed to convince the street that Amazon is still in heavy growth mode and hasn't yet arrived. On the other hand despite of Apple's significant revenue growth—in mature as well as in new disruptive categories—investors treat Apple very differently and have crazy revenue and margin expectations.

Similarly, traditional pure SaaS companies such as Salesforce is considered a high growth company where investors are focused on growth and not margins. But, if you're an on-premise vendor transitioning to SaaS the street won't tolerate a hit on your margins. The street would expect mature on-premise companies to deliver on continuous low double digit growth as well as margins without any blips and dips during their transition to SaaS. As on-premise vendors change their product, delivery, and revenue models investors will be hard on them and stock might take a nosedive if investors don't quite understand where the vendors are going with their transition. As much as investors love the annuity model of SaaS they don't like uncertainty and they will punish vendors for lack of their own understanding in the vendor's model. It's a vendor's job to educate investors and continuously communicate with them on their transition.

Isolating on-premise and SaaS businesses is not practical

Hybrid on-premise vendors should (and they do) report on-premise and subscription (SaaS) revenue separately to provide insights to investors into their revenue growth and revenue transition. They also report their data center related cost (to deliver software) as cost of revenue. But, there's no easy way, if at all there's one, to split and report separate SG&A costs for their on-premise and SaaS businesses. In fact combined sales and marketing units are the weapons incumbents on-premise vendors have to successfully transition to SaaS. More on that later in this post.

The basic idea behind achieving economies of scale and to keep the overall cost down (remember margins?) is to share and tightly integrate business functions wherever possible. Even though vendors sometime refer to their SaaS and on-premise businesses as separate lines of businesses (LoBs), in reality they are not. These LoBs are intertwined that report numbers as single P&L.

Not being able to charge more for SaaS is a myth

Many people I have spoken to assume that SaaS is a volume-only business and you can't charge customers what you would typically charge your customers in your traditional license and maintenance revenue business model. This is absolutely not true. If you look at some of the deal sizes and length of SaaS contracts of pure SaaS companies they do charge a premium when they have unique differentiation regardless of volume. Customers are not necessarily against paying premium - for them it is all about bringing down their overall TCO and increasing their ROI with reduced time to value. If a vendor's product and its delivery model allow customers to accomplish these goals they can charge them premium. In fact in most cases this could be the only way out. As a vendor transitioning from on-premise to SaaS their cost is going to go up; they will continue to invest into building new products and transitioning existing products and they will significantly assume the cost of running operations on behalf of their customers to deliver software as a service. They not only will have to grow their top-line to meet the growth expectations but to offset some of the cost to maintain the margins.


Prime advantage on-premise incumbents have over SaaS entrants

So, what does work in favor of on-premise vendors who are going through this transition?

It's the sales and marketing machine, my friends.

The dark truth about selling enterprise software is you need salespeople wearing suits driving around in their BMWs to sell software. There's no way out. If you look at high growth SaaS companies they spend most of what they earn on sales and marketing. Excluding Workday there is not much difference in R&D cost across vendors, on-premise or SaaS. Workday is building out its portfolio and I expect to see this cost go down in a few years.

Over a period of time, many on-premise vendors have built a great brand and achieved amazing market penetration. As these vendors go through SaaS transition they won't have to spend as much time and money educating the market and customers. In fact I would argue they should thank other SaaS vendors for doing the job for them. On-premise vendors have also built an amazing sales machine with deep relationship with customers and reliable sales processes. If they can maintain their SG&A numbers they will have enough room to deal with a possible initial hit on revenue and additional cost they would incur as they go through this transition.

Be in charge of your own destiny and be aggressive

It's going to be a tough transition regardless of your loyal customer base and differentiating products. It will test the execution excellence of on-premise vendors. They are walking on a tight rope and there's not much room to make mistakes. The street is very unforgiving.

Bezos and Benioff have consistently managed to convince the street they are high growth companies and should be treated as such. There's an important lesson here for on-premise vendors. There is no reason to label yourself an on-premise vendor simply making a transition. You could do a lot more than that; invest into new disruptive categories and rethink existing portfolio. Don't just chase SaaS for its subscription pricing but make an honest and explicit attempt to become a true SaaS vendor. The street will take a notice and you might catch a break.

Growing up as an engineer and as a programmer I was reminded every step along the way that resources—computing as well as memory—are scarce. The programs were designed on these constraints. Then the cloud revolution happened and we told people not to worry about scarce computing. We saw rise of MapReduce, Hadoop, and countless other NoSQL technology. Software was the new hardware. We owe it to all the software development, especially computing frameworks, that allowed developers to leverage the cloud—computational elasticity—without having to understand the complexity underneath it. What has changed in the last two to three years is a) the underlying file systems and computational frameworks have matured b) adoption of Big Data is driving the demand for scale out and responsive I/Os in the cloud.

Three years back, I wrote a post, The Future Of The BI In Cloud where I had highlighted two challenges of using cloud as a natural platform for Big Data. The first one was to create a large scale data warehouse and the second was lack of scale out computing for I/O intensive applications.

A year back Amazon announced RedShift, a data warehouse service in the cloud, and last week they announced high I/O instances for EC2. We have come a long way and more and more I look at the current capabilities and trends, Big Data, at scale, on the cloud, seems much closer to reality.

From a batched data warehouse to interactive analytic applications:

Hadoop was never designed for I/O intensive applications, but Hadoop being a compelling computational scale out platform developers had a strong desire to use it for their data warehousing needs. This made Hive and HiveQL popular analytic frameworks but this was a sub optimal solution that worked well for batch loads and wasn't suitable for responsive and interactive analytic applications. Several vendors realized there's no real reason to stick to the original style of MapReduce. They still stuck to the HDFS but significantly invested into alternatives to Hive which are way faster.

There are series of such projects/products that are being developed on HDFS and MapReduce as a foundation but by adding special data management layers on top of it to run interactive queries much faster compared to plain vanilla Hive. Some of those examples are Impala from Cloudera and Apache Drill from MapR (both based on Dremel), HAWQ from EMC, Stinger from Hortonworks and many other start-ups. Not only vendors but the early adopters such as Facebook created Hive projects such as Presto, an accelerated Hive, which they recently open sourced.

From raw data access frameworks to higher level abstraction tools: 

As vendors continue to build more and more Hive alternatives I am also observing vendors investing in higher level abstraction frameworks. Pig was amongst those first higher level frameworks that made it easier to express data analysis programs. But, now, we are witnessing even higher layer rich frameworks such as Cascading and Cascalog not only to write SQL queries but write interactive programs in higher level languages such as Clojure and Java. I'm a big believer in empowering developers with right tools. Working directly against Hadoop has a significant learning curve and developers often end up spending time on plumbing and other things that can be abstracted out in a tool. For web development, popularity of Angular and Bootstrap are examples of how right frameworks and tools can make developers way more efficient not having to deal with raw HTML, CSS, and Javascript controls.

From solid state drives to in-memory data structures: 

Solid state drives were the first step in upstream innovation to make I/Os much faster but I am observing this trend go further where vendors are investing into building in-memory resident data management layers on top of HDFS. Shark and Spark are amongst the popular ones. Databricks has made big bets on Spark and recently raised $14M. Shark (and hence Spark) is designed to be compatible with Hive but designed to run queries 100x times faster by using in-memory data structures, columnar representation, and optimizing MapReduce not to write intermediate results back to disk. This looks a lot like MapReduce Online which was a research paper published a few years back. I do see a UC Berkeley connection here.

Photo courtesy: Trey Ratcliff

As part of my job I have to go to a lot of meetings. As it turns out, all meetings are not equally important. Many times, either during a meeting or after the meeting, I end up asking myself why the hell did I go to this meeting. Sounds familiar?

A couple of yeas back, instead of just whining about it, I decided to do something about this situation. I set a personal goal to cut down the meetings that I would go to by 20%. Not only I succeeded but I kept the same goal the year after and I accomplished that as well.

This is how I did it:

Ask for prep documents and an upfront agenda

If the meeting that I am invited to does not have an agenda in the meeting request, I ask for it before I commit to it. This approach has two positive effects: 1) it forces an organizer to think what he/she wants to accomplish that invariably results in a productive meeting b) I have an opportunity to opt out if I don't receive an agenda or the agenda doesn't require my presence. I also ask for prep documents for a meeting; I prepare for all my meetings and I firmly believe that meeting time should be judiciously used to discuss what people think about the information and make important decisions as opposed to gathering information that could have been accomplished prior to a meeting.

Opt-out with an alternative ahead of a meeting

If I believe the agenda is partially useful but I won't add any value by being part of the meeting, I connect with an organizer ahead of the meeting to clarify a few things or give my input, either in person or via email or phone. In most cases, me reaching out to an organizer serves the purpose and I don't have to go to the actual meeting. If I do end up having to go for such meetings I ask an organizer for a permission to either walk-in late or leave early. This saves me a lot of time and I don't have to sit through a meeting when I am not required to be there.

Postpone a non-critical meeting

If I see that I am invited to a non-critical meeting, I ask to postpone it by a few days citing my non-availability. In many cases, the issue would have been resolved in a few days and we won't be required to meet. It is important to decline the original meeting request and ask the organizer to create a new meeting request in future even if you have an intent to postpone and not cancel the meeting. Most people don't create a new meeting request and I won't hear back from them.

DVR the meeting

I ask organizers to record certain meetings when I believe that parts of a meeting would be useful at later stage. I fast forward non-interesting parts of such meetings and listen to the parts that I like. I underestimated the effectiveness of listening to a recording until I organized a few meetings as podcasts and listened to them during my commute. Most fascinating part of this approach, other than an ability to fast forward, is being able to listen to a meeting as an information session without having to worry about understanding all details and anxiety to make decisions.

If everything else fails, multitask

I believe it is somewhat rude and distracting to others when people bring their laptops/tablets to a meeting and keep working on it and not pay attention to the meeting. But, this isn’t true when the meeting is an audio conference. I don't work on my laptop or tablet when I am in a meeting room; I am fully committed to the meeting and completely present. However, for certain meetings, when I know that I don't have an option to opt out and it is going to be a waste of time, I dial into the meeting instead of being there in person. I do continue to work on my laptop while participating into the meeting. This is not to confuse with remote meetings that I participate in or lead when all people are not at the same location. I am fully present for those meetings.

Before you ask, yes, I did meticulously measure the time I saved. I had a simple spreadsheet that did a great job. I was a little hesitant in the beginning to push back for meetings but l became more comfortable as I started saving more and more time. I would highly encourage you to follow these rules or create your own and save yourself some quality time that you can use do other useful things.

Photo courtesy: Ho John Lee