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.

 

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.