Services That Scale


In the software industry, professional services have a bad rap: services don’t scale. Yet for many enterprise software companies, professional services can be a huge enabler of revenues and a significant differentiator. 

Many startups begin with a focus on product-led growth. Companies are started by engineers, often target other engineers and, at least for a while, getting people to download your software or try your SaaS offering on their own is a good way to see if there’s interest. In the early days, you may not have anyone else in the company to provide a lot of assistance, so this is a reasonable strategy.

However, many startups hit a speed bump as they grow. They get some initial traction with product-led growth but then larger companies start trying it out and things slow down. In lean times, Engineering budgets get cut, just like everyone else’s and things stall. 

Selling to Enterprise customers is easier said than done. When the deals happen, they’re larger, which is great. And name brand accounts bring credibility to your company. So, naturally, you hire an Enterprise sales team to build relationships with buyers and navigate the choppy waters of determining who has budget, authority, etc. 

Getting meetings is no problem, but somehow, projects seem to slip. Deals move from Q3 to Q4 and beyond. The customer loves what you’re doing, they have the exact problems you’ve described, they’re excited but somehow… it just keeps slipping. 

I remember one large deal that kept slipping at Gatsby. We eventually realized that because they didn’t have React programming skills on staff, they were overwhelmed with some of Gatsby’s capabilities. Eventually, we proposed a “Concierge” offering whereby we would help them optimize their Gatsby builds for a five figure price. We were clear that we would not be doing coding, but rather identifying areas where their architecture could be improved. Best of all, we structured the deal as subscription service that renewed annually. The initial Concierge deal lead to a larger cloud subscription deal some months later. And because they always had new Gatsby projects underway, they ended up renewing the Concierge services for several years.

Are They Ready To Buy From A Startup?

One thing you will want to test is whether the prospect really has the appetite to buy from a small company. The only proof is if they’ve done it before. Otherwise, you can find yourself in the situation of implementing “must have” customer requirements like SOC-2 compliance, Role-Based Access Control or integration with legacy systems all on spec, hoping that this work will be sufficient to close the deal.

Now if all these features are on your roadmap already, it’s not the worst situation in the world. It’s all part of growing up to serve larger customers. 

Unfortunately, after you’ve implemented the first set of requirements, there’s often another bunch of “must have” features or security requirements that has surfaced from some another group within the company. Even if you closed an initial deal, if the customer doesn’t put your software into production then there’s nothing you can build on.

However, even in the best of situations there is often a mismatch between the skills of the team that is building the product and what the customer is able to figure out and implement on their own. In many cases deals stall because customers don’t know how to proceed. The buyer may lack dedicated resources or skills to use all the fancy new technology you’ve invented. 

There is some irony in the fact that a large Enterprise customer is several orders of magnitude larger than the startup they are buying from, but that’s just how these things go. Often because of how large companies are structured, it’s easier for them to get technical expertise from outside than from within. And this provides a significant opportunity for savvy startups who can help customers with their implementation.

The first thing to remember about Enterprise customers is they are accustomed to paying for premium support. When they have a problem, they don’t want to be out there searching on the forums or stuck in a customer support queue. They want eyes on it immediately. Especially if it’s a production issue impacting their users. 

More importantly for early stage startups, you can greatly improve your odds of finding product market fit by working closely with early Enterprise customers.

Offering professional services can eliminate one of the potential deal killers in selling to large companies: who will do the work?

Customers, who are already busy with existing projects, will be much more open to buying if you are there to provide hands-on assistance during implementation and available to trouble-shoot anything that might go wrong. Best of all, there’s no reason you can’t charge for this. 

For startups entering the Enterprise software market, this is almost always a good approach. It gives you more control on getting to the finish line and it can drastically shorten the time frame from finding out issues and getting them fixed in your product. It also helps build customer focus in your organization. People who have had to roll out software and fix bugs in a live system have much more empathy about getting things right the first time. Additionally, many engineers want to know how their work performs “in the real world.” 

It’s not a bad idea to assign your core engineers to the first half a dozen or more Enterprise implementations. I know you’re wondering: Won’t this take time away from new feature development? Yes, but it means when you get back to it, new features are far more likely to land well with future customers. There is no better way to understand how your product actually works than being on the front-line with the customers, sharing the responsibility to go live. 

One of the best things about helping Gatsby customers improve their performance was we saw all kinds of interesting ways that they misused and abused our technology. That helped us improve our documentation and engineer better defaults and best practices into the product.

After you’ve done a few implementations, you’ll have smoothed off some of the rough product edges that might have otherwise taken you months to discover. The result is going to be a better experience for future customers. 

Ideally you can take what you’ve learned and turn it into a repeatable implementation methodology for future customers. Document all the phases, determine who does what, what kind of systems you need access to, and write down all the details. Future customers and System Engineers will thank you.

Even though human services don’t scale as easily as servers, it’s fairly linear for startups on a path from $1m to $100m in ARR as long as you have the discipline to learn from the experience and improve your product and your services as you go. While there can be margin concerns at large scale, generally speaking if services revenues are 20% or less of total revenue no one is going to worry about it. And sometimes, that 20% professional services is exactly what it takes to close an Enterprise deal.

That said, here are a few additional things to keep in mind:

  • You will need to identify specific steps in your services that are highly repeatable. It’s not going to be completely cookie-cutter, but understanding common patterns makes it much easier. For example, you will need to develop a clear set of questions and guidelines for scoping integration points and performance requirements.

  • Figure out your rough time and costs for implementation work. Then double it. And for early deals, double it again. You will likely want to propose any implementation work at a fixed price with a “not to exceed” number of ours. Keep an eye on the actual implementation times so that you can improve the accuracy of estimates over time. You will occasionally screw up, so make sure enough buffer that you don’t lose your shirt. Remember, you’re delivering real value to your customers, so charge for it.

  • Make sure you create a statement-of-work that defines the milestones, dates and deliverables. Also be clear about what work you will not be doing. (e.g. are you writing integration code or is the customer?)

  • Watch for scope creep. In early projects you’re likely to miss some things. But over time, you want to make sure that implementation projects are 80-90% predictable. Look for ways to continue to make implementations faster and easier. 

  • Ideally after the first six or ten implementations, as you’ve started creating a repeatable methodology, you should be able to use a mix of junior and senior engineers. 

  • You’ll want to get customer-blocking features prioritized on your internal product roadmap. And also ensure that there’s steady communications from the implementation team back to product and engineering so that you’re making things easier and faster over time. This may require building internal tools for your services team. 

  • Engineers who do implementation work have to like working with others. Not everyone is cut out for front line work.

Remember, you’re not just selling a product, you’re making sure the customer gets the solution they need. Good service is a powerful way to differentiate from larger vendors, by showing you’re able to move fast, make decisions and address their concerns.

In contrast, sometimes large companies have terrible service, because they view it as a cost center which they are constantly trying to minimize. You can do much better by actually caring about customers and their outcomes.

Over time as you develop a prescriptive methodology for designing and implementing customer solutions you can use that to build an even bigger services ecosystem led by independent agencies and consultants. You’ll have a much easier time guiding your partners if you’ve led those kinds of projects internally.

Special kudos to Ben Robertson who led the Customer Success team at Gatsby. He not only created the Concierge program that led to more than 50% of our Enterprise deals, but he also helped establish the culture of customer focus.

What Went Wrong with the OpenAI Board?

Clowns 4

This weekend’s drama at OpenAI raises a lot of questions about what makes an effective board. While we don’t know all the details behind Sam Altman’s ouster, the poor communications, board wavering and disastrous outcome indicate a high degree of dysfunction. There have been a few excellent posts by investor Chris Yeh and Hubspot founder Brian Halligan on the specifics of OpenAI so I’ll focus on the lessons for startup founders and CEOs on how to build an effective board.

First of all, it’s worth spending a moment to reflect on  the primary purpose of the board of directors. A board does not run the organization; that’s the CEO’s job. Nonetheless, the CEO has a boss and that’s the board of directors. The board’s role is to ensure the proper governance of the organization and is responsible for hiring and firing of the CEO. That’s it.  

In the case of a typical venture-backed startup, the board has a fiduciary responsibility to shareholders. This was not the case for OpenAI, which had an unorthodox structure as a non-profit with a for-profit division. Surprisingly, OpenAI’s board had no representation from its outside investors Microsoft, Sequoia and Thrive Capital and seemingly no obligation toward them. 

Building A Balanced Board

In a typical for-profit startup, the board consists of the founders and some of the investors. Usually, early stage seed investors don’t take board seats and if they do, they don’t keep them for long. That makes sense given the large number of investments they undertake. Generally early Series A and B venture investors take board seats in order to provide guidance to the founders and keep a watchful eye on things. Later stage investors may or may not get board seats or observer (non-voting) seats. 

I have been on boards with investors like Bill Gurley and Peter Fenton from Benchmark, and there is no doubt that top-notch VCs provide tremendous strategic value to the companies they invest in. That said, VCs with operational experience are fairly thin on the ground. 

If you’re the CEO of a startup, while you work for the board, you’re also responsible for the composition of the board. Venture investors (as opposed to seed investors) won’t usually abdicate a board seat and often their investment agreement may preclude such a change. 

There is usually a provision for the CEO or founders to add one or two independent board members, unaffiliated with the investors. Ideally, independent board members add experience and skills that complement the founders and investors. 

Typically you are looking for people with operational expertise that is relevant to your business and the challenges you’re facing. Unlike investors, independent board members usually have a four-year agreement, though that’s not a hard cutoff date. 

A Board Must Be Helpful

I first decided to become a board member after participating in board meetings at MySQL. The MySQL board was a good one, and had a mix of investors Kevin Harvey (Benchmark), Danny Rimer (Index) and operational executives Bernard Liautaud (BusinessObjects), John Wattin (TietoEnator), Dana Evan (Verisign) and Tim O’Reilly (O'Reilly Media) as well as the founders.

My inspiration came from one particularly complex discussion around our technology strategy where it seemed the input was all over the place. I thought to myself: in this kind of situation, I would like to be the helpful board member.

I have always believed that the board is there to support the CEO. The CEO has a difficult job and the issues that are brought to the board are inherently difficult. A good board can provide help when navigating choppy waters.  

In the case of the OpenAI board, there had been three resignations in 2023 (Reid Hoffman, Will Hird, Shivon Zilis) over the last year leaving the board unbalanced.

The board had also clearly not thought through the implications of firing Altman. They waffled over the weekend and the result has left the company in a vastly weakened state. They jeopardized an active funding round, angered their largest investor and technology partner, alienated employees and showed an extreme level of incompetence. 

Big Moves Should Be Carefully Deliberated

When a founder or C-level executive is moved out of a key role in a company, this is not to be taken lightly. In a good board, such a move would be the subject of weeks if not months of discussion and planning. This includes succession planning, contingency plans, internal and external communications plans and more. It doesn’t appear that the OpenAI board did any of this. 

In extreme cases where criminal behavior or workplace misconduct is suspected, there may be a need for an emergency removal, but even in such a case there must be careful consideration to operational details to ensure they don’t lose the trust of employees.

The OpenAI board indicated that they “lost confidence” in Altman. Further there were rumors of rifts between co-founder Ilya Sutskever and Altman around a reduction in Sutskever’s responsibilities and Altman’s focus on rapid commercialization over safety. 

It’s not the board’s role to resolve management squabbles. That’s the CEO’s job. I may be reading too much into the reporting but it does appear Altman’s rift with Sutskever became a board level issue. Since Sutskever was a co-founder with a board seat, perhaps it was inevitable. Still, I have seen rifts between founders and CEOs get resolved with a lot less drama than what we saw this week.

When a shit show like this emerges, there’s enough blame to go around for everyone. While I would largely fault the OpenAI board, Altman has admitted he should have done a better job managing the board.  

Final Thoughts for Founders and CEOs

When there is a fundamental disagreement on strategy or direction, whether at the board or management level, it is up to the CEO to get everyone on the same page. Neither the board nor the executives should ever be confused about who is running the show. That is the CEO’s job. The board provides input, but it is the CEO who steers the ship.  

So if you’re a founder or CEO of a startup, what lessons should you take from this train wreck? 

  • In the unlikely event that you have an unorthodox board structure serving multiple masters, you’ve got to make sure all constituencies are represented. Similarly, you must create mechanisms for resolving conflicts that will likely arise, whether the issue is balancing commercialization and security, openness and censorship, content moderation etc. 

  • You should strive for a balanced board with diverse views. If your board consists exclusively of investors, consider adding an independent board member with operational experience that can provide guidance as you scale.

  • Don’t leave board seats empty for too long. Not because you might need the votes, but because you’re missing out on potentially valuable input.

  • Resolve operational issues and management rifts before they become board-level problems. With co-founders this is sometimes easier said than done. If executives cannot work together, they must be removed. 

  • Keep your board apprised of what you’re doing and what you’re thinking. A board relationship must be high trust. There should be no surprises. Whether it’s good news or bad news, share it. 

  • If there is conflict, get it out into the open. You must be able to discuss complex strategic issues with the board and get to a shared understanding of the best way to proceed.  

I have found it useful to schedule regular communications with board members in order to stay in sync. I provided updates at least every six weeks (mid-quarter, end of quarter) in addition to the regular board meeting. For sensitive issues, I would reach out to them as soon as I was aware of a problem, let them know my plan and ask for additional input. 

No doubt we’ll learn more in the days and weeks ahead about the fate of OpenAI, Sam Altman and Microsoft. Few companies go through this level of public drama. And perhaps with more thought to board composition we can avoid similar blow ups in the future. What lessons do you take from this? Post a comment below.

The Power of Disruption

Over the years, I’ve been asked many times about the common elements across the companies I’ve worked in. Borland, Active Software, MySQL, Zendesk, Duo Security, were all quite different. However there were several factors they had in common which might be helpful for those thinking of joining or creating a new startup company.

Each of these companies helped usher in a new technology wave that enabled growth across the industry. Borland was part of the first stage of the PC software industry and later helped usher in the Windows era as well as Client/Server computing. MySQL helped drive the acceptance of open source software for the web. Zendesk was one of the early SaaS cloud vendors. Duo security fueled the growth of B2B smartphone applications to make the internet more secure. 

At the time, these bets were not at all obvious. There had been open source products before MySQL and SaaS companies before Zendesk. But these were by no means proven business models. Still, if you squinted right, you could see a future that would continue to grow. Nonetheless, there was considerable risk, and many peer companies fell by the wayside. 

Part of what made the future interesting for these companies was the size of the total available market (TAM). In the early 2000s, the database industry was a stable and mature business, generating around $9 billion in revenue for Oracle, IBM, Microsoft, Sybase and a handful of others. I joined MySQL when the company was doing about $5m in ARR and there had been no new breakout database business in the prior ten years. As I did my research on MySQL it became clear that there was a large market, and that customers were deliriously happy. The same pattern held true at Zendesk and Duo Security. The final piece of the puzzle that made these companies successful was that the strategy was disruptive. 

The term disruption, gets thrown around a lot by founders and investors to the point of it becoming synonymous with “new, cool stuff.” But when I speak of disruption, I am holding to the definition by Clayton Christensen in his book The Innovator’s Dilemma

Many successful businesses have been built without fitting in to Christensen’s theory of disruption. But if you are able to tap into its power, disruption is like having the wind at your back in a marathon. It’s still a marathon, but you’ve got some staying power.

Christensen distinguishes between sustaining innovation and disruptive innovation. Sustaining innovation (such as incremental improvements in a product’s performance or price) favors the incumbent catering to their existing customers. Startups generally should avoid pursuing sustaining innovation as these improvements are easy for incumbents to adopt, even if it takes them some time. 

If your new, cool, VC-backed company creates a product that is twenty or even thirty percent better (faster, cheaper, easier) than the big guys, it’s going to be extremely difficult to lure customers to a new, unproven startup. Customers who buy from large vendors often think: “we’ll just wait a year or two, and we’ll get those features, too.”

The Rules of Disruption

Christensen defines disruptive innovation as a radical change in the market that targets a new audience with different buying criteria. They aren’t seeking something “just a little better.” They are representative of a new emerging market. There are four key elements of disruption: 

1. There must be a large existing market

2. There are existing incumbent vendors  

3. A new entrant plays by different rules to serve an underserved market

4. The incumbents are unable or unwilling to adopt the disruptive strategy

The third item is really the trickiest. But let’s examine this further using MySQL as an example. 

1. $30b market… check!

2. Large incumbents included Oracle, IBM, MSFT… check!

3. New entrant with different rules… MySQL is open source… check!

4. The incumbents won’t open source their products or offer them free… check!

Let’s drill further into MySQL’s strategy and what was going on at that time. During the so-called “database wars” of the late 1980s and early 1990s vendors like Oracle, Informix, Sybase, IBM were all focused on TPC-C benchmark performance. Each was trying to outdo the other with new features, faster disk drives, bigger processors. This was truly an era of sustaining innovation with vendors launching advanced features, more tuning options and faster benchmark scores. The result of many years of sustained improvement was that databases had become increasingly complex. Specialist DBAs were required to tune databases in order to ensure fast performance. 

Finding the Underserved Market

MySQL was not the first open source database, but it was the first one that catered to web developers. In this early period of web development, the dominant tools were HTML editors and scripting languages such as PhP, Perl and Python. As web developers sought to create more dynamic sites, they looked to use a database. MySQL became the default database for web development by virtue of three factors:

  • It was easy to learn

  • It integrated well with popular web development languages 

  • It was free when used under an open source license

So while the incumbents were fighting over a massive Enterprise market that focused on advanced features and performance, MySQL was being used by people who would never have bought Oracle, SQL Server or IBM DB2. To web developers, the existing database products were:

  • Too complex

  • Too hard to learn

  • Prohibitively expensive

  • Required management approval

The very features that made Oracle and others attractive to Enterprise customers made them overkill for newcomers. Web developers were seeking a “good enough” solution for building dynamic web sites and applications. They didn’t need or understand most of Oracle’s features. 

In effect, MySQL snuck in the side door by focusing on an under-the-radar market. The big vendors targeted major enterprise applications in finance, manufacturing, retail and ERP systems. They didn’t care about web developers. That market barely existed and certainly wasn’t large enough to attract their high-priced sales teams. 

When the incumbents looked at MySQL, they dismissed it as a toy. It was a primitive database with just a fraction of the features of their products. Worse yet, MySQL users were webmasters and web developers who worked for, ugh, startups whose budgets were a fraction of those found in the Fortune 1000.  

The Growth of a New Market

Over a few years, that tiny, underserved market grew by leaps and bounds, bringing a far bigger opportunity for MySQL and other web technology vendors. MySQL was part of the LAMP stack (Linux, Apache, MySQL, PhP/Perl/Python) an alternative to traditional development stacks offered by Microsoft and others. The LAMP stack became the default development approach for the Web 2.0 era.

To be clear, the LAMP stack was a marriage of convenience, more of a clever acronym than an actual software architecture. The pieces worked together, but it took more work than Microsoft’s fully integrated tools. Nonetheless, the LAMP stack provided freedom to developers that wanted to avoid vendor lock-in. With Microsoft, Oracle and others, the more technology you used, the more you had to pay in annual server license and maintenance fees. The LAMP stack enabled companies to develop a scaling strategy that eliminated the “success tax” as they grew. 

Google, Facebook, Wordpress, YouTube, Wikipedia, all were built on the LAMP stack, as were thousands of startups over the next 15 years. The LAMP stack became the de facto standard for building web sites and we-based companies.

Imitation Is The Most Sincere Form of Plagiarism

Part of the reason MySQL had such unprecedented growth was that the business model was hard for the incumbent leaders to replicate. We routinely promoted MySQL’s Enterprise commercial offering as being 90% cheaper than Oracle. Not surprisingly, that wasn’t a price Oracle could match, lest it decimate its growth. MySQL’s open source business model was part and parcel of its disruptive strategy. 

Oracle argued that its products were more sophisticated and more fully-featured,  which was absolutely true. MySQL wasn’t trying to match Oracle features pound-for-pound. MySQL was targeting users whose needs were more modest. In that regard, both products were a good fit for their respective audiences.

As often happens with disruptive innovation, at some point, the incumbents imitate the disruptor. Oracle announced a stripped-down free product called Oracle Express, which had a subset of features and limited storage capacity. Most users looked at Oracle Express and realized that because of its limitations, it was effectively “cripple-ware” and they’d have to upgrade to the regular commercial product as their data sets grew. For developers this was a non-starter. After all, who wants to swap out databases as you grow?

Microsoft, IBM, Sybase all embarked on similar strategies announcing their own creatively named free products: SQL Server Express, DB2 Express, Sybase Express. All failed to make any mark in the industry and MySQL’s growth was unimpeded. Nonetheless, the moved helped validate the market by showing that what MySQL was doing was worth copying. 

The Billion Dollar Question

MySQL continued to embrace the disruptive strategy, adopting a subscription model and integrating with new emerging programming languages and tools. While there was often discussion about limiting the features of the open source product, we knew that we could not walk away from the open source model without losing our disruptive mojo. There were still plenty of challenges, but the open source approach made us unique.

We grew the company to around $100m in recurring revenue before we were approached by Sun Microsystems with a billion dollar acquisition offer. Oracle also made overtures including an 11th hour bid to match Sun’s offer. 

Working at Sun provided me further insights into the power of disruption. I got an inside view of how an early innovator like Sun could be devastated by disruptive technology, in this case the commoditization of the server industry through a combination of Windows, Linux and Intel processors. Sun, like most companies facing disruption, predictably and rationally focused on their biggest and most valuable Enterprise customers, rather than embracing new emerging technology markets. Less than two years after MySQL was acquired, Sun was acquired by Oracle. 

While MySQL had a somewhat contentious relationship with Oracle, we always respected them and felt that they understood the power of disruption. Oracle has remained a remarkably good steward of MySQL.

So what can you take from all of this? 

Silicon Valley founders and investors are great at hyping technologies. But it is still fairly rare for a company to fit Christensen’s definition of disruption. Nonetheless, the theory of disruption is a useful model for evaluating new technologies and understanding whether they are truly disruptive or simply “new and cool.” If you can find a technology that is opening up new markets, the disruption model can be a guide for making decisions to keep you on the right path. But be careful of falling into the trap of thinking that making something slightly better, faster, cheaper is necessarily disruptive.

I hope this post provided some clarity around how to think about disruption. In a follow-up post, I provide practical information on how maximize the impact of a disruptive strategy.

Taming the Annual Budget


While you are thinking about the overall strategy and initiatives for the upcoming year, you must also prepare a budget that enables you to fund these efforts. Generally speaking I’m in favor of a bottoms-up approach to management. However, when it comes to budgeting, a top-down approach is more efficient. The senior team (CEO, CFO, COO) should develop an overall financial model which includes top-line growth targets for bookings, ARR (Annual Recurring Revenue) and expenses including headcount. This budget model should include sufficient investment to ensure that the top initiatives will succeed.

Think carefully about the skills and headcount required on new initiatives so that you’re not inadvertently overloading people and undermining initiatives that are strategic to the company. For example, if you’ve got a critical new Engineering project, it needs an owner who is 100% focused on that. It can’t be a part-time job for someone who already has more than a full-time role already.

Typically, you might converge on the financial targets using a couple of different approaches:

  • Extrapolation from prior year performance based on a targeted growth rate

  • Bottoms up quota-based revenue model, factoring in retention, expansion, churn

  • Deal-based revenue model, based on average deal size, segments, geographic regions

  • New initiatives to expand the product offering, distribution channels or geographic reach

In the startup stage, there is no one-size-fits-all model for the annual forecast. It typically requires a triangulation of multiple approaches. For example, if you grew at 70% in the prior year you might adjust that number up to reflect your optimism around new product initiatives and your desire to be attractive to new investors in anticipation of further fundraising.

If you’ve got a direct sales model, you’ll want to understand how much new bookings are required and whether you have enough sales people to achieve those targets. If you’re seeing traction with larger customers or anticipate a new premium priced offering, you might expect larger deals and some expansion with existing customers.

There’s no one single way to build the model, but you want to make sure that you’re funding the right initiatives and staffing to achieve the desired results. If you’re expecting sales to double, you want to make sure there’s sufficient management, training, headcount and lead generation to support those efforts. As the number of customers expands, so does the requirement for customer success, support and so on.

Each department should create their own annual plan and budget. This will not be as sophisticated as the company’s annual plan, but should fit in with major initiatives. For example, if there’s an overall company goal to expand into Europe that will have implications for language translation, local sales and marketing, local language support, marketing events and so on. 

Each department will have their own departmental specific initiatives through the year. For example Engineering might have goals related to improving uptime or performance. Sales might have goals related to hiring and training. Marketing will have goals around product launches, lead generation, pipeline, analyst relations, PR, etc. A departmental plan could be as short as one or two pages, and ideally no longer than five. The plan should include a definition of what success will look like and identification of any key risks that should be addressed.

Departments Must Be In Sync

You’ll want to make sure that there is coordination between the departments so that Product, Engineering, Marketing, Sales are all in sync. If there’s a product launch expected in Q2, you want to make sure Engineering and Product are clear about delivery dates and major features. Marketing and Sales need to be collaborating on launch plans, training, lead generation and so on. You also need to make sure that you don’t set every major initiative and new hire to start in Q1. You will need to temper ambitions so that things are spread through the year.

I have found the best way to do this is to have departmental leaders share their plans with their peers and collaborate together to understand who is doing what and when. This works best if the executives can get on the same side of the table and work out their needs and priorities together. It also helps to understand the “client relationship” between departments. For example, Engineering is there to build the features that the Product team needs to win in the market. Marketing is signed up to deliver content and lead generation so that Sales can close more bigger deals, faster.

While you might not get 100% alignment across every issue facing every department, you want to avoid too many gaps. I have found that Sales always wants more leads than Marketing will sign up for. But if they can narrow the gap to 15%, that’s close enough. Especially, if there’s a possibility of larger deal sizes, or expansion which can provide some relief for required lead generation. But you want to avoid a gap that’s larger or requires a miracle in the fourth quarter.

Drive Toward Efficiency

Once a company has product-market fit and traction beyond $5-10m in ARR, you will typically want to drive increasing operational efficiency. So, if revenues are to double in the next year, that may require doubling or close to doubling the size of the Sales team to ensure proper quota coverage. However, you want to be careful that other departments such as Marketing, Sales, Support, Engineering, HR, Finance expand at a slower rate. Otherwise you may never get to break-even cash flow positive. 

There can be some back-and-forth discussion or negotiation with the department heads on headcount requirements. Are they hiring individual contributors or managers? At what level of seniority or location? Also consider whether to trade-off headcount for program expenses such as use of part-time contractors for specialized skills. Asking departmental leaders to create their own bottoms-up budgets and headcount plans without top-level targets and constraints takes too long to converge. You are best off assigning them their departmental headcount and dollar budgets and asking the departmental leaders to live within those constraints. How they spend the money and what roles they require is up to them.

Be Flexible

No plan or budget can be set in stone. The business will evolve as things proceed and it pays to be flexible. For example, if instead of hiring more Engineers, there’s a need for more QA, that’s a trade-off that the head of Engineering should be able to make, as long as they are living within the overall budget constraints.

It’s worth having a mid-year check-in on the budget to make sure that things have not gone off the rails. In particular, if hiring and expenses are running high and revenues are lagging, that may require you to reconsider which initiatives to double down on and which should be scaled back.

That said, you want to be careful not to set the expectation there’s more headcount to be had with an all-new budget process. You want to make sure you’re building a disciplined approach to growing the company.

Conquering the Dreaded Annual Plan


As we enter into the autumn season, it’s time to consider the dreaded annual plan. Most startups begin work on this in November and with the Christmas holidays and end of quarter, a lot of work gets crammed into the last week of December. Then departmental budgets and plans come together in January, jammed between the Sales kickoff and the board meeting. It’s a lot of pressure, but somehow everything gets done. And then next year, in an effort to reduce the pressure, the process starts a couple of weeks earlier. Yet the same dynamic plays out. It’s still a last minute scramble. You can try to tame the beast by giving it more time, but the budget process never gets any better. What’s going on?

For most startups, spending more time on the annual plan and budget doesn’t materially improve the business. And there’s a good argument that beyond a certain effort, more time spent on planning reduces time that could be spent on execution. (The Germans, depressed souls that they are, have a word for this. Verschlimmbesserung: an attempted improvement that only makes things worse.)

The annual planning process is important. But don’t mistake the map for the territory. I’ve rarely seen a plan make it all the way through the year without some adjustment. Think of it as a first draft for what you hope will happen in the coming year. It’s important to have a plan, but there’s no such thing as a perfect plan. A good plan is one that states your priorities, what you’re trying to accomplish and what resources you need to do it. It’s also good to identify the things you are saying “no” to in order to stay focused.

SWOT Analysis

If you’re not sure where to start, one approach I have used it so create the MBA standard SWOT analysis. This is a useful framework for identifying internal Strengths and Weaknesses and external Opportunities and Threats. Writing is a great way to clarify your thinking and focus on the top challenges your business faces. 

Think carefully about what is working and what’s not working. Where are you hitting your goals and where are you missing? How is your product landing with customers? What do customers like? What is unique in your offering? Where do you miss the mark? Are some segments performing better than others? Why? When customers churn what do they tell you? 

From your SWOT analysis you should identify a handful of top initiatives for the company. This should include hard unsolved problems. These are often complex problems (or opportunities) that span multiple departments. Are there new features, integrations or distribution methods that could open up additional markets? Are there limitations in your product that are preventing you from closing large deals? Are there additional opportunities in the market that your company is uniquely qualified to solve? Don’t get too hung up on which category items belong to. But generally speaking remember: Strengths and weaknesses are internal, opportunities and threats are external.

It’s unlikely that there will be easy answers to these questions. It may take days or weeks of contemplation, discussion and refinement before you get a clear picture of the priorities and what can and should be done. I have found that writing the SWOT process helped me identify internal problems as well as market opportunities. Sharing early drafts to executives and getting feedback, helped crystalize my thinking. Sometimes creative ideas would present themselves at strange times, during a long run, in the shower, driving or other times when the normally critical brain functions are not as dominant. 

Your annual plan might include a handful of strategic initiatives. These might be product related, market related, or something else. Here are a few examples of initiatives from when I was at Duo Security:

  • Expand the business into Europe with a field sales and support office 

  • Develop a partner / reseller channel

  • Launch a new Enterprise product and go-to-market strategy

  • Develop a vertical market plan for health care

  • Launch a new premium service offering

Each of the initiatives you embark upon will require additional focus and headcount. So be careful of taking on too many things at once. If you can identify projects that are no longer a priority, that can be useful to free up resources. You want to make sure that all departments are working together to make these initiatives successful and everyone is pulling in the same direction. Each department must be aware of their contributions and how things rank in priority to the routine day-to-day operations.

Can Your Team Scale?

Think also about the management team. Who’s running a good operation? Who is struggling? Who has capacity to take on more? If the company doubles over the next year, who will be in over their head? Who are the up and comers who should be challenged to take on more? Who is strategic in their thinking? Who has the pulse of customers? Who is thinking about the competition and how we can beat them? If there’s a need to drive a new strategic initiative, who has the skills and bandwidth to do so?

If your team can continue to take on new growth and the related initiatives with high confidence, that is the best situation. But most executives have a range (span of control, number of products or functions) and when you get beyond their upper bound, it’s normal to bring in people with more experience and a broader range. Someone you hired to grow sales from $1m - $10m in product-led growth is probably not the ideal candidate to grow revenues to $100 million in Enterprise sales. If they want to learn from a more experienced mentor, you may be able to retain them and have the continue to contribute, while you expand the skills and range of the executive team.

Let me know if this has been helpful. In a follow-up post next week, I will provide guidance on how to tie together departmental plans and develop the annual budget.