Feb
22
2021
--

Winning enterprise sales teams know how to persuade the Chief Objection Officer

Many enterprise software startups at some point have faced the invisible wall. For months, your sales team has done everything right. They’ve met with a prospect several times, provided them with demos, free trials, documentation and references, and perhaps even signed a provisional contract.

The stars are all aligned and then, suddenly, the deal falls apart. Someone has put the kibosh on the entire project. Who is this deal-blocker and what can software companies do to identify, support and convince this person to move forward with a contract?

I call this person the Chief Objection Officer.

Who is this deal-blocker and what can software companies do to identify, support and convince this person to move forward with a contract?

Most software companies spend a lot of time and effort identifying their potential buyers and champions within an organization. They build personas and do targeted marketing to these individuals and then fine-tune their products to meet their needs. These targets may be VPs of engineering, data leaders, CTOs, CISOs, CMOs or anyone else with decision-making authority. But what most software companies neglect to do during this exploratory phase is to identify the person who may block the entire deal.

This person is the anti-champion with the power to scuttle a potential partnership. Like your potential deal-makers, these deal-breakers can have any title with decision-making power. Chief Objection Officers aren’t simply potential buyers who end up deciding your product is not the right fit, but are instead blockers-in-chief who can make departmentwide or companywide decisions. Thus, it’s critical for software companies to identify the Chief Objection Officers that might block deals and, then, address their concerns.

So how do you identify the Chief Objection Officer? The trick is to figure out the main pain points that arise for companies when considering deploying your solution, and then walk backward to figure out which person these challenges impact the most. Here are some common pain points that your potential customers may face when considering your product.

Change is hard. Never underestimate the power of the status quo. Does implementing your product in one part of an organization, such as IT, force another department, such as HR, to change how they do their daily jobs?

Think about which leaders will be most reluctant to make changes; these Chief Objection Officers will likely not be your buyers, but instead the heads of departments most impacted by the implementation of your software. For example, a marketing team may love the ad targeting platform they use and thus a CMO will balk at new database software that would limit or change the way customer segment data is collected. Or field sales would object to new security infrastructure software that makes it harder for them to access the company network from their phones. The head of the department that will bear the brunt of change will often be a Chief Objection Officer.

Is someone’s job on the line?

Another common pain point when deploying a new software solution is that one or more jobs may become obsolete once it’s up and running. Perhaps your software streamlines and outsources most of a company’s accounts payable processes. Maybe your SaaS solution will replace an on-premise homegrown one that a team of developers has built and nurtured for years.

Feb
18
2021
--

Why do SaaS companies with usage-based pricing grow faster?

Today we know of HubSpot — the maker of marketing, sales and service software products — as a preeminent public company with a market cap above $17 billion. But HubSpot wasn’t always on the IPO trajectory.

For its first five years in business, HubSpot offered three subscription packages ranging in price from $3,000 to $18,000 per year. The company struggled with poor churn and anemic expansion revenue. Net revenue retention was near 70%, a far cry from the 100%+ that most SaaS companies aim to achieve.

Something needed to change. So in 2011, they introduced usage-based pricing. As customers used the software to generate more leads, they would proportionally increase their spend with HubSpot.  This pricing change allowed HubSpot to share in the success of its customers.

In a usage-based model, expansion “just happens” as customers are successful.

By the time HubSpot went public in 2014, net revenue retention had jumped to nearly 100% — all without hurting the company’s ability to acquire new customers.

HubSpot isn’t an outlier. Public SaaS companies that have adopted usage-based pricing grow faster because they’re better at landing new customers, growing with them and keeping them as customers.

Image Credits: Kyle Poyar

Widen the top of the funnel

In a usage-based model, a company doesn’t get paid until after the customer has adopted the product. From the customer’s perspective, this means that there’s no risk to try before they buy. Products like Snowflake and Google Cloud Platform take this a step further and even offer $300+ in free usage credits for new developers to test drive their products.

Many of these free users won’t become profitable — and that’s okay. Like a VC firm, usage-based companies are making a portfolio of bets. Some of those will pay off spectacularly — and the company will directly share in that success.

Top-performing companies open up the top of the funnel by making it free to sign up for their products. They invest in a frictionless customer onboarding experience and high-quality support so that new users get hooked on the platform. As more new users become active, there’s a stronger foundation for future customer growth.

Jan
22
2021
--

Drupal’s journey from dorm-room project to billion-dollar exit

Twenty years ago Drupal and Acquia founder Dries Buytaert was a college student at the University of Antwerp. He wanted to put his burgeoning programming skills to work by building a communications tool for his dorm. That simple idea evolved over time into the open-source Drupal web content management system, and eventually a commercial company called Acquia built on top of it.

Buytaert would later raise over $180 million and exit in 2019 when the company was acquired by Vista Equity Partners for $1 billion, but it took 18 years of hard work to reach that point.

When Drupal came along in the early 2000s, it wasn’t the only open-source option, but it was part of a major movement toward giving companies options by democratizing web content management.

Many startups are built on open source today, but back in the early 2000s, there were only a few trail blazers and none that had taken the path that Acquia took. Buytaert and his co-founders decided to reduce the complexity of configuring a Drupal installation by building a hosted cloud service.

That seems like a no-brainer now, but consider at the time in 2009, AWS was still a fledgling side project at Amazon, not the $45 billion behemoth it is today. In 2021, building a startup on top of an open-source project with a SaaS version is a proven and common strategy. Back then nobody else had done it. As it turned out, taking the path less traveled worked out well for Acquia.

Moving from dorm room to billion-dollar exit is the dream of every startup founder. Buytaert got there by being bold, working hard and thinking big. His story is compelling, but it also offers lessons for startup founders who also want to build something big.

Born in the proverbial dorm room

In the days before everyone had internet access and a phone in their pockets, Buytaert simply wanted to build a way for him and his friends to communicate in a centralized way. “I wanted to build kind of an internal message board really to communicate with the other people in the dorm, and it was literally talking about things like ‘Hey, let’s grab a drink at 8:00,’” Buytaert told me.

He also wanted to hone his programming skills. “At the same time I wanted to learn about PHP and MySQL, which at the time were emerging technologies, and so I figured I would spend a few evenings putting together a basic message board using PHP and MySQL, so that I could learn about these technologies, and then actually have something that we could use.”

The resulting product served its purpose well, but when graduation beckoned, Buytaert realized if he unplugged his PC and moved on, the community he had built would die. At that point, he decided to move the site to the public internet and named it drop.org, which was actually an accident. Originally, he meant to register dorp.org because “dorp” is Dutch for “village or small community,” but he mistakenly inverted the letters during registration.

Buytaert continued adding features to drop.org like diaries (a precursor to blogging) and RSS feeds. Eventually, he came up with the idea of open-sourcing the software that ran the site, calling it Drupal.

The birth of web content management

About the same time Buytaert was developing the basis of what would become Drupal, web content management (WCM) was a fresh market. Early websites had been fairly simple and straightforward, but they were growing more complex in the late 90s and a bunch of startups were trying to solve the problem of managing them. Buytaert likely didn’t know it, but there was an industry waiting for an open-source tool like Drupal.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com