Friday, August 16, 2019

How to Size a Market

Sizing the market opportunity is a key component of any business plan. It’s logical that the senior management, the board, the VCs and other stakeholders want to see how big the market opportunity is before investing any dollars in your plan. Ideally, they will want to see the opportunity size, growth, and also breakdowns by various factors such as industry, geography, and company size.

The expectation is that you “do your homework” and find the relevant Gartner report with hard data that you will be able to quote to management so they can make their tough business decisions. However, no matter how hard you are looking, you discover that neither Gartner nor any other analysts cover your particular product category. And forget about slicing it by geography or vertically!

Market Sizing Available from Industry Analysts

Gartner publishes regular reports and spreadsheets such as the forward-looking Forecast: Enterprise Software Markets and the backward-looking Market Share: All Software Markets. Both do a pretty good job estimating the market size, growth, and the 5-year compound annual growth rate (CAGR) for the main software categories. If you are a Gartner customer, you should definitely get ahold of these reports! If you are not, search around. You might find them or you might find some of the data points relevant to you. Just about every Magic Quadrant states the market size and market growth and those are available for free from many vendors.

Gartner also sizes the submarkets of their main software categories and chooses not to publish those numbers. For example, while they publish the data for the enterprise content management (ECM) market, they also track the subcategories such as document management, digital asset management, and web content management. If you have the right type of subscription, they will share the data with you. They have it for software subcategories, geographies, and to a limited degree, as market shares by company.

Since 2017, Gartner stopped attributing revenue to industry verticals. Knowing how impossible of a task that is, I don’t blame them. I plan to write a separate post about that issue. So unless you are lucky and happened to work with some boutique firm that publishes vertical numbers, you will be out of luck. Of course that won’t stop your bosses from asking for it and so keep reading, because I’ll explain how to move forward.

The Gartner methodology seams to be primarily based on tracking all players in a given category and collecting/estimating their revenue in said market. I find the Gartner methodology plausible and the data credible. The same is true for IDC and their Software Tracker. There are a few other firms that provide some market data including Forrester, ARC and others but only Gartner and IDC have teams of analysts who are primarily responsible for market sizing, as far as I know.

I am somewhat skeptical of the market sizing conducted by firms such as Markets and Markets, Market Research Future, Intense Research, Eminent Market, Orbis Research, etc. I actually suspect that there is a single organization behind all these names but I admit that haven’t bothered to investigate that. Those companies all seem to stem from the India/China region and they are trying to sell me their reports every day. However, none of them have ever spoken to me or to any of my colleagues. I don’t know their analysts, I am not familiar with their methodology, and I am doubtful of their data.

TAM versus Actual Market Size

Now, when talking about market sizing, there are two main data points that are often being confused:

1.     The actual current market size and
2.     Total addressable market (TAM)

The actual market is the sum total of all revenue generated by all market players over the last 12 months. This is what Gartner reports and they are specifically counting all [on premises] license revenue, cloud-based subscription revenue, maintenance, and support revenue. They do not count the professional services revenue in any market as that revenue is often difficult to attribute to a specific software category and the money made by the major players such as Accenture, Deloitte, and Capgemini would skew the numbers dramatically. This is part of the market sizing methodology by Gartner that makes sense to me.
Note: I realize that many companies obsess more about their bookings rather than revenue by product line but I don’t think that Gartner is concerned with that distinction and so let’s ignore it for now.

What Gartner doesn’t report is the TAM. The TAM is the potential market, independent of your company’s ability to capture it. It doesn’t consider your market presence, the amazing appeal of your solution, or your competitive win rate. Basically, if everyone out there purchased everything they possibly could from you, that’s your TAM. This data point is very useful for business planning, and executives, VCs, and other investors are very interested in it. Sometimes, there are other data points used such as the serviceable addressable market (SAM), or the serviceable obtainable market (SOM, aka target market) but if you have the TAM and the actual market size, you are in a good shape as far as your business planning goes.

Estimating Market Size

Now, what do you do when the data you are looking for is simply not available? Yes, you’ve checked with Gartner, with IDC, and with all the other analyst firms in your space and you are coming up empty. Well, it’s time to do your own research and come up with your own data. You think you can’t just make it up? You worry that your data won’t be as credible as Gartner’s? Well, perhaps not. But you are an expert in your field. You know more about it than 99% of the people out there. The No. 1 rule is that an educated estimate from an expert is much better than flying blind. How do you think Gartner comes up with their data?

So, let’s estimate the actual market size. First, list all the market players in your space. That’s usually not that hard. You might even have an additional insight such as which vendors play in the enterprise end of the market and who is focused on SMB. Add a bucket for “Others” because there is no way that you are not forgetting some players; for example, vendors only active in certain geographies. Depending on how mature your market is, the Others group will occupy somewhere between 20-50% of the overall market size. Estimate that percentage and calculate the value based on the overall market.

Now, start estimating the revenue for each of the vendors. Start with yourself, that’s the hard data point you have. You usually know who’s bigger and who’s smaller than you in your space. Estimate by how much – give each vendor a number. If you can’t even dare to estimate, do some more research. Google around – big companies share a lot of data points and hints in their quarterly earning’s calls while the small ones like to brag about themselves at conferences.  Ask co-workers who might have worked at some of your competitors. If you have a competitive intelligence function, check with them. Collect data points and tidbits. Over time, you’ll get a pretty good feel for what the market looks like. At the end of the day, estimate. Yes, guess. Estimate the new business vs upsell vs recurring revenue. Trust me, your guess will be better than you think and certainly better than no data at all.

Now, to be clear, while guessing is OK, do attribute your sources and document your methodology, including our own estimates. In the end, what makes any market-sizing model credible is the methodology. By sharing the methodology with your management, they are free to adjust any estimate as they like. You will be off by some margin…and so is Gartner! Ultimately, it makes relatively little difference for your business plan whether your market is $3.9 bln or $4.4 bln. That’s a small enough range and your estimate will be within or close to that range. Add it all together, don’t forget to account for the Others, and voilà, you have market size and market share!

Calculating Market Growth

The next data point that you will need is the market growth. This gets trickier as the more you drill down, the more inaccuracy you’ll be adding. To do that, go through the exercise but estimate the companies’ revenue 12 months ago. You will find some actual numbers through research and your expertise will help you to gauge who’s been growing faster and who slower. Getting actual data from 2-3 companies will significantly improve your ability to estimate. You know much you’ve grown and you should have accurate data about your win rate against each of the competitors. Who’s hot right now? Who’s been very visible at every event? Who’s milking a massive installed base? Who’s showing up with a different reference at every webinar and who keeps using the same customer for every occasion? All that considered will give you some understanding of the relative growth of each vendor.

And just like that, you have the market size, market share, and market growth overall and for each vendor. That’s pretty good! It might feel rough but it’s way better than an empty slide.

Understanding the Limitations

Remember, the more granularity you want the less accuracy you’ll have to accept. That’s why I wouldn’t use this methodology to estimate CAGR over 5 years. This is where Gartner and IDC will beat you – they have been doing it regularly for years and they have a much more accurate history and a much better feel for future growth.

I’d be also careful using this methodology to estimate the market size and revenue for a specific geography or vertical. You can try and leverage some of the country growth data from Gartner, combined with the specific market expertise within your company. But you will find it much less confident and rightfully so. You are making estimates based on estimates and your accuracy will suffer. Again, this is where Gartner and other analysts who’ve been doing it year after year will beat you.

Being Proactive to Be Credible

Ultimately, it is not the coming up with the numbers but the credibility of your data that will be your greatest challenge. It’s easy to dismiss your estimates. But chances are very high that the right chart doesn’t exist and you will have no choice but to come up with your very own take on what the market looks like. Don’t leave this for the night before the business plan is due. This exercise takes time. Start building it today. Iterate on it and fine-tune it over time. Setup a workshop and involve your boss and other key stakeholders. That’s the best way to proactively address the data credibility issue. Remember, an educated estimate is better than no data at all!

In the next post, I will discuss how to estimate the total addressable market, TAM. In the mean time, here’s some recommended reading: Forbes: How To Effectively Determine Your Market Size

Wednesday, March 2, 2016

Platform is a Business Model, Not a Technology

Many software companies have been infected by the platform bug. They market their software as a platform. They have built a platform. Their software comes with tiered architecture, an API, and perhaps even some developer tools. But do they really have a platform?

Well, to have a platform, someone has to “stand” on it. What that really means is there have to be others who have built applications on your platform. If the only applications available on your platform come from you, the world couldn’t care less about your platform. There have to be companies out there that decided to build their applications on your platform and not on someone else’s.

That last point is critical. The application developers are effectively asked to place a bet on your platform. That’s particularly important for commercial application vendors as their application will require your platform to run. That represents a huge commercial risk. The application vendors can usually afford to build their software only for one or two platforms. Supporting more than that becomes very cost prohibitive. So why would the application vendors select your platform over some other one?

This effectively becomes a business decision based on the market presence of the platform. The market presence is critical in determining the total addressable market for the application. It’s only one factor, because your application actually only targets a fraction of that potential target market - there are other factors involved based on the type of the problem the application solves. It is very rare, that customers would adopt a certain platform because of a particular application. They may adopt a platform because of a perceived abundance of applications but rarely because of one application.

Let’s take the mobile devices as an example. If you want to build a mobile application, you need to decide on which operating system platform your application will run. Considering the market presence, your decision is relatively easy - you need to support Android and iOS and then your application will support well over 95% of all mobile devices. Adding a third platform to support - perhaps Windows or Blackberry - makes commercially little sense. It’s a huge development cost for a marginal increase of potential customers.

While the market presence is key for an application vendor to support your platform, the features are not. No matter how rich your API is, how easy your development tools are to use, or how well you ensure security, scalability, reliability, etc., application vendors won’t support your platform if you don’t have a market presence that represents an attractive enough target market. Sure, all those features are important but, commercially, the market potential will always beat features.

There has been a long debate about Enterprise Content Management (ECM) as a platform. All the key vendors provide technically a platform. They have the right architecture, the API, and the developer tools. But let’s take a look at the market from the application software vendor point of view. The market is very fragmented with many players and none of them has more than 15% of market share. If you can only afford to support 1-2 platforms, which ones to you choose? IBM? OpenText? EMC? Box? SharePoint? Picking any one of those two will give you no more than 25% of the market as a potential target audience. Would you as an application vendor bet your business on any one of those platforms?

No. What you do is you build your application in a manner that is agnostic to all those ECM systems and you provide integrations to any one of those ECM repositories. That way, you only need to support one code base while potentially targeting a significant percentage of the ECM market. You have mitigated your commercial risk by not making your application stand on any one platform - there is no business dependency for the application. Your approach, however, makes all those ECM systems just information sources, not platforms.

“Wait a minute”, you might say, “how about the applications that are built by customers rather than commercial vendors?”. True, those applications do make your platform a true platform, even if most of the customer development falls more into the category of customizations rather than applications. But as that line is very blurry, let’s not split hairs. The question to ask is what makes customers who intend to build their own applications choose your platform? And the answer is, yet again, not so much about the features and technology and much more about the skillset availability, which is a function of market presence.   

To be a platform, any system has to devise a business model that compels application developers to bet their applications on a platform’s success. How do you attract developers to build their applications on your platform? How do you make it commercially attractive for them? Without resolving this fundamental issue, all the features and APIs won’t make any difference.

Because a platform is a business model, not a technology.  

Wednesday, November 4, 2015

The Case for Non-Persistency

"Never write if you can speak; never speak if you can nod; never nod if you can wink."
-- Martin Lomasney, Massachusetts state senator

We have collaboration, we have enterprise file sharing, we have enterprise content management systems. It’s secure, efficient, and compliant. Yet, most collaboration is still done using email. Why is that? What does email have that all the collaborative software doesn’t?

What all these tools have in common is that they are persistent. The messages, comments, and documents that we create and share as part of collaboration are meant to remain preserved in the repository for a long time. And, for a good reason. They are part of the organizational body of knowledge, the corporate memory, that can be leveraged by the entire organization today and in the future. Often, there are also compliance reasons that stipulate persistency, sometimes even requiring us to turn all collaboration artifacts into formal records.

Photo: Flickr
But this persistency has a side effect. For one, employees often refuse to commit to bits the communication that they don’t want anyone to forward or discover. No, I don’t mean any politically incorrect jokes or some corporate sexting. I mean useful, productive communication in the form of feedback, opinions, advice, or critique that are often only shared in person. That’s why a lot of this communication either doesn’t happen at all or happens via SMS text messages and consumer instant messaging tools outside of IT control.

Another problem of persistency is vulnerability. That’s the benefit that Snapchat exploits so well when they say that delete is the default. Persistent information can be leaked or hacked. Information that has vanished because it was non-persistent, can’t. Many consumer companies have recently learned a tough lesson when their customer database has been hacked and the customer data has been leaked. If the data wasn’t persistently stored in the database, it wouldn’t have been leaked.

The other side effect of persistency is the added burden on employees. When you are saving a document in a repository where it may be shared with other people, you have to save it responsibly. Responsible collaboration means you have to think about where you save it, what you name it, decide with whom you share it, specify access permissions, assign metadata, add an expiration policy, and perhaps even classify it as a record. If you don’t do that, you are not collaborating responsibly because the organization won’t be able to get much benefit from what you are sharing.

Sure, some of those tasks can be automated and there is an entire industry trying to solve that problem. But some of the steps can’t be and that makes it a hassle. That’s why so many people just email the document to those they need to collaborate with right now. With email, we are free to collaborate irresponsibly -  we don’t need any of that metadata or policies, we don’t even have to name the document. All we need is just to click on Reply to All.

Email is not exactly non-persistent but it seems that way. Sure, some of us might be aware that the emails live on a server somewhere and some might even know that their IT department archives all emails for possible litigation and compliance purposes. But that’s only preventing us from engaging in irresponsible behavior, not in irresponsible collaboration.

There is one more burden that persistency creates. It creates clutter. The more sharing of documents and comments, the more clutter that is being created. If the collaboration artifacts remain persistent, the volume of documents, folders, messages, and comments just keeps growing and growing. Pretty soon the repository becomes difficult to navigate and nobody can find anything anymore. The corporate memory becomes a digital landfill, denying the organization the benefit of future reuse.

In fact, non-persistent collaboration is a gap in the collaboration market. We need a solution where a few people can quickly come together in an asynchronous way and just share, review, comment, and edit information. It could be a single document, a collection of images, or just an idea in the form of a sketch. After the collaboration is concluded, the initiator can decide whether the result should be moved to a persistent area or just leave it upon which it would vanish. The versions, comments, and messages would all vanish too.  The vanishing could be timed or immediate and it would always be the default behavior. Any move to persistence would have to be deliberate and it would notify all participants.

I am not aware of any commercial offerings providing non-persistent collaboration today but they might exist. I know that the US military has been using such a solution in the past, perhaps they still are. Obviously, the security aspects of non-persistency have a great appeal for a security sensitive organization like the military. I should probably also mention Snapchat again here. It is not exactly a commercial offering but it certainly has made a mark with its non-persistent messaging.

Would such non-persistent collaboration finally replace email? Maybe. Probably not. If I had a penny for every time someone declared email for dead… But it would address a gap in people’s needs. I know it goes against the grain of every corporate legal counsel and chief compliance officer but non-persistency would make us more productive.

Thursday, April 2, 2015

They Should Be Business Tools

A few weeks ago, Google decided to quietly sunset Google Glass. They never said it publicly and in fact they might be considering another strategy for the device, but by all measures, Google Glass as we know it has failed. There are many theories for the reasons of this failure ranging from privacy concerns to the lack of social acceptance for walking around with geeky glasses. My theory is that the failure may be related more to the $1,500 price tag as consumer gadgets are simply not supposed to be that expensive.

Sergey Brin wearing Google Glass
That’s perhaps really the problem. Google Glass was certainly too expensive as a gadget for consumers but it likely wouldn’t have been too expensive as a business productivity tool. Most companies wouldn’t have a problem with the devices price, particularly with the customary volume discounts, if it demonstrated tangible benefits.

I can think of numerous business applications for Google Glass – from instructions while operating or repairing complex machinery, to patient records during surgery, to production data on the assembly line and supplier data in the warehouse.

But none of that was ever a priority apparently. Instead, Google put all their efforts into marketing Glass to consumers. The consumers may represent a greater opportunity in terms of volume but the enterprise market may represent a greater opportunity to optimize revenue. Just ask Microsoft.

There have been other technologies that I thought would have benefited from this strategy. Microsoft Kinect for Xbox comes to mind. While popular with gamers, the novelty of gaming via full body motion control is now wearing off. Let’s face it, most gamers want to shoot at aliens while sitting on their sofa and the Kinect is not the optimal weapon for that.

I would have hoped that we’d see Kinect being used in business – the repair technicians with oily hands reviewing designs, foremen at construction sites reviewing blue prints, surgeons with sterile hands reviewing patient records, farmers with dirty hands, lab technicians working in gloves – there are many use cases for gesture-based interaction.

When gestures are not practical, voice-based interaction might be appropriate. This is another technology that might have a greater application in the professional world than in the consumer space, at least given the current state of voice recognition. While the consumers relish in finding out the shortcomings of the still relatively new technologies such as Apple Siri or Amazon Echo, the business use cases may be more feasible. The business vocabulary is more precise and predictable, particularly in the given context. Professionals usually have to learn their business vocabulary as part of their job training and that makes it easier and less ambiguous.

Consumers usually resort to calling a company’s 800-number only after they failed to accomplish something online. At that point, we are exposing the already frustrated consumer to a voice recognition system that is far less mature than the web site and expect it to deliver a great experience. People usually don’t call in to do something that can be done with a smartphone app – like to check their account balance. In the business world, on the other hand, users are already trained to use a fairly precise language and their voice commands are usually in the context of a specific data set or business process.

I need the Q3 revenue data for Europe broken down by product group” is much easier for a machine to understand and act upon than: “I want to buy a companion ticket for my spouse using my miles to match an already issued ticket purchased by my employer”. This relatively common task requires many additional data points - ticket number, flight numbers, account number, name and DOB of the traveler, seating preferences, credit card number, etc. – and that is very difficult for a voice-driven system to piece together.

Apple Watch. Yes, I want one!
A few weeks ago, Apple launched its new Watch. By all measures, it is already a success even though it won’t ship for another few days. The demo by the Apple team was very impressive and the press reviews are glowing. I have no doubt that the Apple Watch will become a success. But I wonder about the practical use cases of the Watch for consumers. So far, most wearable devices have focused on fitness but that market is very saturated already. The serious athletes will be hard to separate from their specialized Garmin, Timex, and Suunto watches. The hobby athletes are well served by the Fitbit, Jawbone, and Nike Fuel fitness trackers or they simply keep using their smartphones.

I can’t help but to wonder about the business use cases for the Apple Watch. There are many possibilities – approving process tasks, participating in simple collaboration activities, delivering business context-relevant information, etc. Smart watches are looking for a killer app and sharing your heartbeat is probably not it.  I suspect that we could find it sooner in business rather than the consumer space. 

Google Glass page on March 31, 2015