Monday, June 20, 2016

Disconnect To Reconnect


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

Making Design Thinking real

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

Be part of foundation of something disruptive

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

Fuel the insane growth of SAP HANA

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

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

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

Incubate a completely new class of data-first cloud solutions

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

Practice the General Manager model with a start-up mindset

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

Be part of a transformative journey

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

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

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

I want to disconnect to reconnect.

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

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

Thursday, March 24, 2016

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


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

Here are some interesting insights:

Occupation

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

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

Age

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

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

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

Gender disparity

This continues to be the most depressing statistics.

92.8% “developers” are male.

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

Diversity

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

Education

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

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

Technology

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

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

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

Employment

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

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

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

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

Source: Stack Overflow 2016 Developer Survey

Salary

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

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

Photo courtesy: Thomas Hawk

Tuesday, October 13, 2015

What Makes You A Good Product Marketing Manager?


"A Pretty Package Can’t Sell A Poor Product” - Bill Walsh

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.

Wednesday, July 8, 2015

The Discriminatory Dark Side Of Big Data


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

Wednesday, April 22, 2015

The Art Of Delegation - My Ten Principles For Healthy Team Culture


"Delegate almost to the point of abdication" - Warren Buffet

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

Monday, March 16, 2015

Chasing Unknown Unknown, The Spirit Of Silicon Valley


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

Tuesday, December 30, 2014

Did SAP Overpay For Concur?


Since SAP announced to acquire Concur and eventually closed the acquisition for $8.3B many people have reached out to me asking whether SAP overpaid for Concur. I avoid writing about SAP on this blog even though I work for SAP because this is my personal blog. In this case, I decided to write this post because this is the largest enterprise SaaS acquisition ever and this question unpacks the entire business model of SaaS enterprise software companies.

If you’re looking for a simple “yes” or “no” to this question you should stop reading this post now. If not, read on.

People reaching out to me asking whether SAP overpaid for Concur in itself is a misleading question because different people tend to compare Concur with different companies and have a specific point of view on whether the 20% premium that SAP paid to acquire Concur is justified or not.

Just to illustrate financial diversity amongst SaaS companies, here are some numbers:


This is based on a combination of actual and projected numbers and I have further rounded them off. The objective is not to compare the numbers with precision but to highlight the financial diversity of these companies based on their performance and perceived potential.

Market cap is what the market thinks the company is worth. The market doesn’t necessarily have access to a ton of private information that the potential acquirer would have access to when they decide what premium to pay. While the market cap does reflect the growth potential it is reflected in a standalone pre-acquisition situation and not post-acquisition.

The purchase price, including the premium, is a function of three things: revenue, margins, and growth (current, planned, and potential). However, not all three things carry the same weight.

Revenue

For SaaS companies, annual recurring revenue (ARR) is perhaps the most important metric. It is not necessarily same as recognized revenue what you see on a P&L statement and ARR alone doesn’t tell you the whole story either. You need to dig deeper into deferred revenue (on the balance sheet and not on P&L), customer acquisition cost (CAC), churn, and lifetime value of a customer (LTV) that companies are not obligated to publicly report but there are workarounds to estimate these numbers based on other numbers.

Margin

If you’re a fast growing SaaS company the street will tolerate negative margins since you’re aggressively investing in for more future growth. Margin is less interesting to evaluate a fast growing SaaS company, for acquisition purposes or otherwise, because almost all the revenue is typically invested into future growth and for such SaaS companies the market rewards revenue and growth more than the margins.

Margin by itself may not be an important number, but the cost of sales certainly is an important metric to ensure there is no overall margin dilution post acquisition. Mix of margins could be a concern if you are mixing product lines that have different margins e.g. value versus volume.

Growth

Current and planned growth: This is what the stock market has already rewarded pre-acquisition and the acquirer assumes responsibility to meet and exceed the planned or projected growth numbers. In some cases there is a risk of planned growth being negatively impacted due to talent leaving the company, product cannibalization, customers moving to competitors (churn) etc.

Growth potential: This is where it gets most interesting. How much a company could grow post-acquisition is a much more difficult and speculative question as opposed to how much it is currently growing and planned to grow pre-acquisition (about 29% in case of Concur) as this number completely changes when the company gets acquired and assumes different sales force, customer base, and geographic markets. This is by far the biggest subjective and speculative number that an acquirer puts in to evaluate a company. 
 
To unpack the “speculation” this is what would/should happen:

LTV 

This number should go up since there are opportunities to cross-sell into the overall joint customer base. LTV does reduce if customers churn, but typically preventing churn is the first priority of an acquiring company and having broader portfolio helps strengthen existing customer relationship. Also, churn is based on the core function that the software serves and also on the stickiness of the software. The most likely scenario for such acquisitions is a negative churn when you count up-selling and expansion revenue (not necessarily all ARR).

CAC

This should ideally go down as larger salesforce gets access to existing customer base to sell more products and solutions into. The marketing expenses are also shared across the joint portfolio driving CAC down. This is one of the biggest advantages of a mature company acquiring a fast growing company with a great product-market fit. 

Revenue growth

As LTV goes up and churn goes down overall ARR should significantly increase. Additional revenue generated in the short term through accelerated growth (more than the planned growth of the company pre-acquisition) typically breaks even in a few quarters justifying the premium. This is an investment that an acquiring company makes and is funded by debt. Financing an acquisition is a whole different topic and perhaps a blog post on that some other day.

Margin improvement

This is a key metric that many people overlook. Concur has -5.3% operating margin and SAP has promised 35% margin (on-prem + cloud) to the street by 2017. To achieve this number, the overall margins have to improve and an acquiring company will typically look at reducing the cost of sales by leveraging the broader salesforce and customer base.

This is a pure financial view. Of course there are strategic reasons to buy a company at premium such as to get an entry into a specific market segment, keep competitors out, and get access to talent pool, technology, and ecosystem.

Based on this, I’ll let you decide whether SAP overpaid for Concur or not.


Disclaimer: I work for SAP, but I was neither involved in any pre-acquisition activities of Concur nor have access to any insider Concur financial data and growth plans. In fact, I don’t even know anyone at Concur. This post is solely based on conventional wisdom and publicly available information that I have referenced it here. This post is essentially about “did x overpay for y?,” but adding SAP and Concur context makes it easy to understand the dynamics of SaaS enterprise software. 

Photo courtesy: Iman Mosaad