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

Tuesday, October 21, 2014

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


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

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

Specific business case

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

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

Leveraging the excitement

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

Knowing who will sign the check

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

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

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

Happy selling!

Photo Courtesy: Wierts Sebastien