While many successful businesses have been built that are not disruptive, the disruption model lends itself well to the technology industry where new innovations are able to change the market. This gets at the heart of how disruption works. Disruption occurs when an inferior solution for an unattractive market changes the rules of the game. Following on from the prior post on disruption, here are some practical tips on navigating the choppy waters of competing against much larger incumbents.

Disruption often emerges as the ugly duckling, overlooked and then scorned by bigger companies that know better. When you are building a business that is disruptive, it is helpful to keep in mind that the larger incumbent vendors will act rationally to serve their largest, most profitable customers. The disruptor is better served by focusing on use cases and customers that are below the incumbent’s radar. In other words, don’t moon the giant.

You don’t have to be better than the incumbents. You have to be different. Generally speaking, disruptive products are worse than the incumbents when evaluated using conventional criteria. However, there must be one key way in which the disruptor is better for the underserved market.

Avoid Head-on Competition

When I was at MySQL and Duo Security, two companies that were disruptive, I knew we had a limited amount of time to build our business before the incumbents caught on. In both cases, we focused on fringe customers (mid-market companies, startups, web companies, universities and the like) avoiding direct competition with the big guys. We were grateful that the incumbents weren’t paying much attention. But it made sense. They were focused on large customers in traditional markets: Fortune 1000, financial services, healthcare, government, and so on.

In the case of both MySQL and Duo Security, the disruptive solutions were much less sophisticated than the incumbent’s offerings. We were feature poor in comparison, but much easier to use. MySQL was famous for its “fifteen minute rule” meaning a novice could download and start running MySQL in fifteen minutes, compared to the weeks of training required for Oracle. In the case of Duo Security, customers could sign up for a free trial and the majority were up and running with a cloud-based solution in under 48 hours, something almost unheard of in the world of cyber security at that time.

The ease of use of our products was in stark contrast to the incumbents. Oracle and RSA were all about meeting the needs of the most demanding experts in the most demanding companies in the most demanding industries. Easy just wasn’t in their vocabulary. The concept likely confused them.

For us, making a product that was limited but easy to use, was key to getting new users. Our customers weren’t sophisticated Enterprise DBAs and security experts. They were network engineers tasked with implementing security, or developers looking for a web database. They weren’t experts by any means. Often they didn’t how to begin evaluating potential solutions. So if we could help them get results quickly and give them confidence, there’d be no reason for them to evaluate more complex solutions. That turned out to be a great strategy.

In the case of Duo Security, we were able to show that users not only liked our product, they loved it. That was completely unheard of in the world of cyber security. Duo provided an easy, fun mobile experience that was vastly simpler than what people experienced with other security products. We routinely achieved an NPS (Net Promoter Score) in the 70s, higher than well-regarded consumer companies like Apple. This became a powerful part of our marketing as the best loved security company.

Incumbents Are Predictable And Rational

If you find yourself operating as a disruptor in the market, keep in mind that the incumbents will act rationally to serve their best, largest customers. If you can build your business by catering to customers in segments they don’t care about, you’ll avoid direct competition, at least for a while. And remember, making something better does not necessarily make it disruptive. It’s only disruptive if it opens up a new market that uses a different buying criteria. Your goal is to build a product that is “good enough” to get the underserved to buy from you.

You’ll likely find yourself in meetings with larger companies who will tell you they can’t buy from you until you have certain key features. And once you’ve implemented those, they’ll have another even longer set of additional required features. Don’t worry about that. It’s better to focus more on the the kinds of customers who actually do buy, rather than prospects who tell you why they cannot. Look for new use cases in neglected markets. Target customers who understand the disruptive model and are unlikely to buy from the incumbents.

Stay True To What Makes You Disruptive

Most importantly, avoid the pitfalls of the disruptive model. Don’t try to compete with the incumbents on their turf. That’s a loosing game. Duo Security never had all the features that RSA offered. We never tried to build on an-premise version. We stayed true to our cloud strategy and sought customers who were open to that approach. After all, we’d seen customers embrace the cloud for their applications and customer data. It was only a matter of time before they adopted it for security.

In fact, that became an important buying pattern for us. If a customer hadn’t already adopted several cloud applications, we knew they would stall out in the purchase cycle. It’s difficult to change customer behavior. Instead, focus on prospects who are already moving in the right direction.

As I mentioned in the prior post about disruption, at MySQL we had a great respect for Oracle, not only their technology, but also their people. But we still sometimes poked fun at them. The photo at the top of this post is MySQL co-founder David Axmark piloting his boat in front of Larry Ellison’s yacht in the Stockholm harbor.

We worked closely with Ken Jacobs, known to many as “Dr DBA.” Ken was Oracle’s second-longest running employee after Larry Ellison. Officially, Ken was our ambassador / handler inside of Oracle. But he was much more than that and became a friend to all of us.

 

The photo above is from the MySQL conference in 2006 where we named Oracle “partner of the year” following their acquisition of the InnoDB storage engine upon which we relied. Ken, recognizing the humor, was unfailingly gracious. Following Oracle’s acquisition of Sun, Ken retired from Oracle in 2010 after 30 years of service. It is with great sadness I learned that Ken Jacobs passed away in 2021.

 

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.

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.

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.

One of the biggest challenges in scaling a company comes when the Engineering and Product functions expand beyond the founders. What started out as a tight-knit effort between a small, high-functioning group turns into any number of problems:

• Feature creep
• Blown schedules
• Projects in limbo that never ship
• Teams get larger but fewer things make it out the door
• Major unplanned rework of features, user interface or architecture
• Corners are cut in QA or performance testing
• Overtime evenings and weekends in crunch mode
• Engineering burnout, low morale
• Marketing is surprised to learn that several key features got cut
• Sales doesn’t know how to sell it
• Product features don’t land with customers

Over the years, I’ve seen all these issues and more. While it’s tempting to blame the outcome on the head of Engineering (whose head must surely roll), changing out the leadership without changing the process is likely to yield only an incremental improvement.

If you’ve suffered from some of the problems, you might break into a cold sweat thinking about past situations. But rest assured, it doesn’t have to be that way.

In several companies, I have helped implement a Product Council and review process that can provide  better visibility and predictability as well as a standardized process that addresses many of the problems above. It’s not a panacea, but it can make things run much smoother. Software development is part art and part science. This requires a balance of exploration and constraints.

You’re also trying to create an environment where Engineering is going to take on some risky projects and if they don’t succeed, you redirect or shut down the efforts fairly quickly and without a huge stigma.

The development activities of any given Engineering team or squad is determined by the Product Manager and Engineering Manager working together. They are the leaders of the team, and if the team is failing or wildly successful, it ultimately reflects this leadership. The features under development should fit into the overall priorities of the company, the roadmap, competitive situation, customer feedback, etc. The team, represented by the leadership of Product and Engineering, should be building features and improvements that are measurably improving the company’s business outcomes and the customer experience. If they are not, you need to redirect and change tactics to get better results in the next cycle.

The Product Council is built on several fundamental ideas:

• The job of the Product Council is to periodically review an Engineering team’s progress toward defined objectives. Typically, I have found that a 90 day window works well, with a kick-off at the beginning of the quarter, a mid-point check-in and an end-of-quarter review.
• The Product Council should include the head of Product, the head of Engineering as well as representation from Marketing, Sales, Customer Success. Key leaders (or proxies in their stead) represent the core functions of the business. This ensures every department is in sync and aware of what is being built and why.
• The Product Manager and Engineering Manager together present their team’s plans to the Product Council for review and approval. They can also ask for guidance, input, more resources, etc. The EM and PM must work together at all times. There can be no finger-pointing.
• The council membership (the key leaders of various functions) must provide guidance, ask for more detail, approve, redirect or cancel any product development when it is under review.

A Product Council meeting typically runs 45 minutes. Materials and artifacts are shared ahead of time and it’s expected that the product council membership reads these materials in advance. It’s usually a good idea for the EM and PM to walk through the material with the VP of Engineering and/or the VP of Product in advance to identify areas that need more customer research, more data, and so on. Doing a “dry run” helps avoid surprises and can often improve the session for all attendees with more strategic insight, clearer communication, identification of risks or potential problems.

The EM and PM should present a plan that identifies what they propose the team works on for the next cycle (typically 90 days). This should encapsulate why the work is being done, what the technical risks are, plans for mitigating the risk, what a successful outcome looks like and how it will be measured. For example, if customers are complaining about the speed of the product, there should be a clear proposal for how the problem will be solved, and the resulting performance gain they are aiming for. If there are competitive features being addressed, how will the new features be better than the competition? If there is technical debt to be corrected, how will it improve customer experience or reduce the support burden?

This is not a meeting in which the product council members are meant to sit back and throw rocks at a squad. As I often told the PMs and EMs, it’s not a PhD thesis defense. The Product Council is there to contribute  and help the team.

Avoid Surprises

A key element in reviewing the product plan in the Product Council is to make sure that Marketing and Sales are bought in and hopefully see some major new capabilities that will expand the market or reduce sales obstacles. If Marketing and Sales don’t see major headline features, that should be considered a red flag. At the very least, it might suggest revisiting the marketing launch efforts. It’s always better to find out early in the process when something can still be done, changed, or strategy shifted rather than when the product pages go live.

The mid-quarter check-in meeting is done in order to verify progress is being made and also to consider taking more drastic action for any items that are not going as planned.

I first used the Product Council process way back in the day at Borland. It helped us get several key projects on track, sometimes by cutting back features. I’ve used a modified version of this in other companies from time to time. At Gatsby, Dustin Schau, then VP of Product rolled out the Product Council to provide much needed focus and discipline. While it placed an added burden with a cluster of meetings (one for each squad) it made our Engineering and Product delivery process far more predictable and aligned across Product, Engineering, Marketing, and Sales As Dustin sometimes would say, if we’re going to have a meeting, we’re going to make it valuable, and Product Council certainly was a valuable meeting for all functions.

Find and Fix Problems Early

As an example from Gatsby, in a mid-quarter check-in we learned that an experimental feature we had dubbed “Luda Mode” didn’t reliably deliver the 10x performance gains the team had planned when testing with customers. Rather than treat this as a failure, the team took feedback from the Product council session and identified and delivered other performance gains that, while not quite 10x, delivered a marked improvement to the customer experience and one that Sales and Marketing could still trumpet with minor changes. This is a good example of embracing a “failure,” learning what can be done, and using the mechanism to communicate and discuss openly the right, customer-focused strategy. Best of all, everyone was in sync.

By now, you get the idea. Product council exists to drive alignment, awareness, and strategy down to the squad (where it belongs!), upwards to the Product Council, and across all key functions of the business. It can be an effective process to make Engineering more predictable and increase confidence that you are building the right products. Note also, that the Product Council is not a substitute for the normal day-to-day and weekly management of Product and Engineering.

The Product Council works well at high-growth startups, and can be applied equally well in larger organizations to help increase collaboration between Product and Engineering. It also helps reduce the number of surprises when launching products. Try some of the ideas out, make them your own adapting to your unique situation.

If you’ve found these ideas helpful, I hope you’ll share them with your team.