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.

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.

One of the topics that comes up a lot in startup companies is around positioning. As in, “we need to hire a marketing consultant / guru who can help position our product.”

Positioning is super important, but it’s not something that can be done after the fact. You can’t build a boat and position it as a car. It works best if you think about how you want to position your product (and your company) before you build it.

While there is some art to all of this, at a minimum you should answer the questions:

• Who is the product for?
• What problem does it solve?
• What are the competing options customers have?
• How does your product solve the problem better than any others?

There is a huge discipline in modern product management around “jobs to be done” which can help you build a good perspective. If someone buys your product, what is the job they are hiring your product to do? This works equally well for consumer products as business products.

You must focus on how your product is the best and how you want it to evolve over time. Keep in mind “best” is in the eye of beholder. It has to matter to your buyer.

For a CIO buying a SaaS product “better” might mean:

• Fastest implementation time
• Easiest for users so there’s less training
• Most secure / least risk
• Most advanced reporting
• Integrates with the broadest range of products

When you start, you might only be better in one way. But as you build your product strategy over many releases, it’s good to continue to concentrate your strengths.

Positioning is by no means easy. But there is a template I have used many times. This came from some “bullet-proof positioning” workshops my friend and colleague Jeff Wiss ran for dozens of different companies including MySQL, Duo Security and others.

It’s based on a deceptively simple template to factually describe a product’s key attributes. Positioning written in this style is not intended to drive a tagline or creative marketing. Rather it should be used to evaluate whether your marketing is “on message” to your target audience. 

Here’s the template:

To Target Market, XYZ Product is the Frame of Reference or Category that Point of Difference because Justification.

Here’s how Fed Ex’s early positioning would be described in the template:

To deadline-oriented business people, Federal Express is the overnight package delivery service that is the most reliable because of its sophisticated package tracking system.

The key point of positioning in this way is to identify a singular vector of differentiation and the supporting proof or feature. In the above example Fed Ex could show they were the most reliable by pointing to their sophisticated package tracking system. This was the proof behind “how” they were able to be more reliable. This positioning worked for Fed Ex because their customers wanted to make sure that if they sent something via Fed Ex it got there the next day. Otherwise, they would have just sent it by regular postal service.

Of course, the positioning template is not the slogan Fed Ex used in their print and television advertising. They used a creative embodiment of the position: “When it absolutely positively has to be there overnight.” Which resonated emotionally with the buyer.

However, if you start by writing the tagline, it’s almost impossible to get to clarity. Instead you will likely end up arguing over the adjectives for hours “wordsmithing” the tagline until everything sounds the same.

Here’s a second example template that illustrates Amazon’s early positioning:

To people that like to read, Amazon.com is the online bookstore that is the best place to purchase books because it has the widest selection.

The creative rendition was: The world’s largest bookstore. That’s a very focused message for people who are looking for a wide range of books they might not find at their local mall store.

Finally, here’s the positioning statement that we developed for MySQL:

For web developers and DBAs, MySQL is the world’s most popular open source database because it reduces the Total Cost of Ownership by 90%.

While the template is simple, it can take many hours to work through an exercise in positioning. Jeff and I led several such workshops when MySQL was acquired by Sun Microsystems in order to help other teams throughout the company improve their positioning. In many cases it resulted in greater clarity for the team about what their appeal was in the market place.

However, in a few cases, it became apparent that positioning alone was not going to be sufficient. I remember when we met with one of the hardware server teams. We went around and around for a long time when finally I asked what I hoped would be a question to get them enthused. I asked “How will you win?” 

After a bit of hemming and hawing it was clear that no one on the team thought that they could win. Their product line had suffered from two years of delay and was far behind the competition. Commodity Intel x86 servers were destroying the traditional price/performance ratios and no one wanted to pay Sun’s premium prices for higher levels of reliability. That said, there was still an installed base who would continue to buy Sun’s servers. So we helped them focus on that. It was a grim reminder that no amount of positioning can make up for a product that is not competitive.   

The most important thing about positioning is to focus your efforts on what makes your product uniquely valuable to your customers. When done right, positioning acts as your North Star to provide a clear direction in which to expand your company’s capabilities for many years.

How would you describe your company’s position using the template above? If someone goes to your home page is it obvious within 10 seconds who the product is for and who it’s not for? Is it clear how it’s better than the competition? Does everyone in the company understand your positioning?

Does your positioning stand out? Let me know by posting a comment below.

The toughest thing about building a startup is to be honest with yourself about product-market fit. Product-market fit is a fancy way of saying “Does anyone care about the thing you’ve built?”

The mistake most founders make, is they spend months or even years building something before they determine whether it matters to customers. For a hobby project that scratches your itch, that’s fine. However, if your goal is to build a sustainable business, remember, the answer is always outside, in the marketplace.

When I first joined Duo Security, they were doing just over $5 million in annual recurring revenue (ARR.) The product had some traction, particularly with some small and medium-sized companies where the founders knew some of the cyber security leaders. They’d spent the last year on a project code-named Barn Owl which unfortunately didn’t land. Chester, the director of Engineering was discouraged. “I don’t want people working on stuff that doesn’t matter.”

As I talked to one of the investors, Matt Cohler from Benchmark, it was clear that the company had lost a year working on a collection of features that customers didn't need. Compounding that, the head of sales changed the pricing and packaging just 24 hours before launch. No one was happy with the outcome, which I suppose is one of the reasons the founders Dug and Jon brought me into the company.

When I met with the product marketing and product management team that reported to me, one of the first questions I asked was “How many customer visits did you do last quarter?” The answer was none.

No wonder the product hadn’t landed. I immediately set an objective for the team that they had to each do 6 or more customer visits per quarter. “Go make friends with the sales team,” I said. “They’ll be happy to bring you into customer meetings.”

I used an approach I call “active listening” with customers. It involved creating a simple 1 page set of eight to ten questions. The goal was not to tell them about all the cool new features we were working on, but instead to understand the problems they faced. To listen, without bias, to what they said was important and what was not. If we immediately went into showing slides or a demo of what we were working on, we would get a reaction and we would fail to uncover the customer’s true situation. And what customer was really going to be honest in giving their feedback to our plans? It was like showing baby pictures. No one wants to tell you that you have an ugly baby.

The questions focused on the basics:

• What is your role in the company?
• What went well in your last security project? What didn’t go well?
• What surprises did you face? What took longer than expected?
• What systems must be secured? What systems are less important?   
• What happens when you roll out new security capabilities?
• What’s a burden that you face that you wish you could automate?

And so on.

These are not hard questions. The goal was to get customers to open up and speak to us as they might to a colleague, or someone in a similar position over a drink. It was important that the customer spoke about their situation, not what they thought was happening at other companies or in the industry.

The goal in this process is to uncover pain. It is not to validate what you have built. In fact, it’s best if you do this exercise before you build anything. You must approach it with “beginner’s eyes” as if you know nothing about the customer and their space. Don’t make assumptions about what is difficult or painful in their world. Approach it like you are a journalist with no pre-conceived notions and no ego about being right or wrong.

Many of the customers were intrigued by this approach and sometimes they’d still want to get a briefing on what we were up to. But I made the team promise not to disclose anything. So we told the customers we would get back to them. For those who had interest, it probably increased their curiosity.

The reason this approach is so important is that when we whiteboard technical solutions in an office or over zoom, it’s easy to get caught up in the excitement of the pitch. We’re hoping the customer stops us in our tracks, says we’re geniuses, begs to get early access and calls the CFO to immediately approve budget. But that’s our dream. The only person whose view matters is the customer. What they care about is if we are solving a problem that has their attention. 

Many times, I’ve asked customers whether some important idea we’d uncovered was actually a problem for them and sometimes the answer was “yeah, not really.”  Often, they could ignore the problem, or perhaps it was a fifteen minute chore once a week. Or in some cases, they had a suboptimal solution, a manual process that worked well enough and they didn’t see much point in improving it. You might think you have a better solution, but if it’s not a problem the customer cares about, you are pushing rope, my friend.

What you want to identify are the problems where the customer gets emotionally worked up about the lack of a solution, where they lean into it, talk about the hours or weeks of effort, the drudgery, the pain. When you tap into a problem that really bothers them, you will know it. This is the difference between a “must have” and a “nice to have.” Believe me, in a tough market, you want to be selling a “must have” solution to a pressing problem.

If you are so lucky as to uncover a significant unsolved problem that is painful for a company, take note of it. Ask what would be different for the company if this was fixed. Ask who else has the problem. Find out how much it costs this person, their department, the company in lost productivity. And then… resist the urge to tell them how you’re going to fix it.

After you’ve done eight or ten such customer meetings asking the same questions, you may start to see certain patterns that emerge. I like to write notes directly onto the paper with the questions and then spread them out on my desk and take a step back. What problems are the most common? Are they shared by certain individuals or types of organizations?

You don’t need 100% consistency across all prospects to have a pain worth solving if it is representative of a type of person or business. If you’re seeing something occur in 25% of customers you spoke to that may be enough as long as you can figure out what causes someone to be in the group that has the pain. Is it related to their industry? Size of the company? The type of project they are undertaking? Tease out the common elements and then ask yourself how you can reach more people like that.

Steve Jobs quite famously said: “A lot of times, people don't know what they want until you show it to them.” I think this has resulted in an awful lot of companies going to great lengths to create products that no one wants. A better rule of thumb is to consider that customers, especially business customers, are far more expert about knowing the problems they face than any outsider could ever be.

Your job as a founder or leader is to tap into those problems, validate that what you’re building solves their problem and then, only then, show it to them. Believe me, if you really understand their problem, they are going to want to hear from you.

Have you found product-market fit in your company? What told you you were on the right track? Post a comment below.

One of the questions I often ask founders is “What is working and what’s not working in the business today?” What I’m trying to do is identify the patterns they see among customers.

Identifying patterns and reinforcing them is one of the most important elements in building and scaling a startup. Unfortunately, it’s not a common skill, and if you don’t have it yourself, you will want to make sure it exists somewhere on your executive team.

In an early stage startup, it is essential to to seek out patterns among users and prospects to identify those with a higher likelihood of paying you. The patterns are key elements of why your product resonates with certain people and not others.

While it’s tempting to make this a quantitative exercise based on title, company size, vertical market and so on, the question you are trying to answer is: what causes some prospects to buy and not others? Demographic issues have an influence, but it may also come down to the particular problem the customers are trying to solve and the circumstances around it. I have found it helpful to understand the qualitative elements around customer situations and then try to determine ways to enable customers in those situations to put up their hand and identify their need.

At MySQL, we had a scale problem many startup companies would envy. We had millions of users and thirty thousand new downloads every day. The high volume of users made it harder to distinguish between free open source users and corporate customers who might be inclined to pay. A big part of the job in marketing and sales was to identify patterns which put people into one bucket or the other. We developed a content strategy that made it easy for users to self-select into different categories.

For example, we knew that there was a class of applications for embedding a SQL database into an application or hardware appliance for which MySQL was demonstrably better than competing databases from Oracle, Microsoft and others. So we created webinars, white papers and case studies that highlighted how to evaluate MySQL as an embedded solution. These were targeted specifically to engineering managers and product managers who were the most likely decision makers. Now instead of searching for a needle in a haystack, we had a much more clearly set of prospects who were trying to learn all the could about the problem they were trying to solve.

The embedded use of MySQL wasn’t the dominant pattern among our users. It was probably somewhere between 15 and 20%. But we knew they had very specific requirements of low-maintenance, high efficiency, low-memory requirements for which MySQL was ideally suited. And it was a very profitable segment with deal sizes that could be well into six figures.

We developed similar content strategies for CIOs (and those who wanted to become CIOs!) to learn about open source technology, for Database Administrators who wanted to improve SQL performance, for users concerned with security and so on.

Once you uncover patterns about your users, you can use that information to better optimize your sales and marketing approach. These patterns may also suggest opportunities for features which better serve specific segments of the market.

You don’t need a pattern to represent the vast majority of your buyers for it to be useful. As long as it can be identified and targeted, it may be worthwhile. (Or said differently, there is rarely a single unified pattern that meaningfully defines all your users.)  In fact, trying paint such a broad picture of your audience may yield such generic information as to be completely useless. It is better to be laser focused on specific types of customers and use cases than to be a wandering generality.

And although quantitative analysis can be helpful, I have found that the two best ways to uncovering patterns are to talk to customers and talk to sales people. Just ask: why did they buy from you? And listen.  The most successful sales people often have a highly developed intuition around customer patterns. But in my experience, only about 20% of sales people are good at explaining those patterns back to management. So your best bet is to do customer visits with sales people and then ask the sales rep how often they see similar situations. That’s also a good reason to have marketing people take part in customer calls. You want your marketing team seeing what the sales people see and helping to identify patterns. 

What experiments can you run to uncover patterns among your users? What makes some users buy and others stall? And how can you better serve those distinct segments? What changes to your product, marketing or sales process can you use to optimize for patterns?

Are there patterns you've seen in your business that have been helpful? Let me know by posting a comment below.