Choose your TAM wisely and remember to charge a high price, RethinkDB


[O]ur users clearly thought of us as an open-source developer tools company, because that’s what we really were. Which turned out to be very unfortunate, because the open-source developer tools market is one of the worst markets one could possibly end up in. Thousands of people used RethinkDB, often in business contexts, but most were willing to pay less for the lifetime of usage than the price of a single Starbucks coffee (which is to say, they weren’t willing to pay anything at all). Link

How big is the pie?

Any company selling developers tools needs to figure out the overall market size for what they’re selling. Developers, eager to work tools for themselves (typically, in their mid to late 20s developers work on at least one “framework” project) often fall prey to picking a market that has little to no money and, then, are dismayed when “there’s no money in it.”

What we’re looking for here is a market category and a way of finding how much money is being spent in it. As a business, you want grab as much as the money as possible. The first thing you want to do is make sure there’s enough money for you to care. If you’re operating in a market that has only $25m of total, global spend, it’s probably not worth your while, for example.

Defining your market category, too, is important to find out who your users and buyers are. But, let’s look at TAM-think: finding what the big pie of cash looks like, your Total Addressable Market.

The TAMs on the buffett

If you’re working on developer oriented tech, there are a few key TAMs:

Another interesting TAM for startups in the developer space is a combo one Gartner put out recently put together that shows public and private PaaS, along with “traditional” application platforms: $7.8bn in 2015. 451 has a similar TAM that combines public and private cloud at around $10bn in 2020.

I tried to come up with a public and private PaaS TAM – a very, very loose one – last year and sauntered up to something like $20 to $25bn over the next 5-10 years.

There are other TAMs, to be sure, but those are good ones to start with.

Bending a TAM to your will, and future price changes

In each case, you have to be very, very careful because of open source and public cloud. Open source means there’s less to sell upfront and, that, likely, you’ll have a hard time suddenly going from charging $0 to $1,000’s per unit (a unit is whatever a “seat” or “server” is: you need something to count by!). If you’re delivering your stuff over the public cloud, similar pricing problems arise: people expect it to be really cheap an are, in fact, shocked when it adds up to a high monthly bill.

But briefly: people expect infrastructure software to be free now-a-days. (Not so much applications, which have held onto the notion that they should be paid for: buy the low prices in the app store depress their unit prices too.)

In both cases (open source and public cloud delivery), you’re likely talking a drastically lower unit price. If you don’t increase the overall volume of sales, you’ll whack down your TAM right quick.

So, you have to be really, really careful when using backward looking TAMs to judge what your TAM is. Part of the innovation you’re expected to be doing is in pricing, likely making it cheaper.

The effect is that your marketshare, based on “yesterday’s TAMs,” will look shocking. For example, Gartner pegged the collective revenue of NoSQL vendors (Basho, Couchbase, Datastax, MarkLogic, and MongoDB) at $364M in 2015: 1% of the overall TAM of $35.9bn! Meanwhile, the top three Hadoop vendors clocked in at $323.2M and AWS’s DB estimate was $833.6M.

Pair legacy TAMs with your own bottoms-up TAM

In my experience, the most helpful way for figuring out (really, recomputing TAMs in “real time) is to look at the revenue that vendors in that space are having and then to understand what software they’re replacing. That is, in addition to taking analyst TAMs into perspective, you should come up with your own, bottoms-up model and explain how it works.

If you’re doing IT-lead innovation, using existing (if not “legacy”!) TAMs is a bad idea. You’ll likely end up over-estimating your growth and, worse, which category of software you are and who the buyers are. Study your users and your buyers and start modeling from there, not pivot tables from the north east.

The other angle here is that if you’re “revolutionizing” a market category, it means you’re redefining it. This means there will be no TAM for many years. For example, there was no “IaaS” TAM for a long time, at some point, there was no “Java app server TAM.” In such cases, creating your own TAMs are much more useful.

Finally, once you’ve figured out how big (or small!) your pie of money is, adjust your prices accordingly. More than likely you’ll find that you’ll need to charge a higher price than you think is polite…if you want to build a sustainable, revenue-driven business rather than just a good aggregation startup to be acquired by a larger company…who’ll be left to sort out how to make money.

CloudBees launches certification and new private SaaS offering backed by Jenkins 2.0

2014, when the company pivoted away from its public PaaS offering to focus on Jenkins. That seems to have been the right move – headcount has grown from 60 to 164 since then, and revenue increased 150% year over year in 2015.

There’s pricing in there too and some notes on enterprise customers if you have 451 access.

Source: CloudBees launches certification and new private SaaS offering backed by Jenkins 2.0

Better ways of developing software or, coding like a unicorn, government edition

I’m often asked to come speak on, well, the topic of “tell us about the new, interesting stuff out there that makes software development better…but don’t be pitching me anything.” This is my most recent cut at that kind of talk.

You can check out the slides as well.

See these slides and the government edition of them too. This presentation changes slightly each time I give it. Here’s the first, rehearsal run of it as well.

Link: ​Middleware-as-a-service turns enterprise integration on its head – Reseller News

“Global analyst firm Ovum forecasts the global spend on middleware software is expected to grow at a compound annual growth rate (CAGR) of 8.8 percent between 2014 and 2019, amounting to $US22.8 billion by end of 2019.”

Source: ​Middleware-as-a-service turns enterprise integration on its head – Reseller News

Gartner Says Demand for Enterprise Mobile Apps Will Outstrip Available Development Capacity Five to One

“Organizations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic,” said Mr. Leow. “We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging. Mobile strategists must use tools and techniques that match the increase in mobile app needs within their organizations.” And: “Gartner believes organizations will improve their in-house mobile development skills over time, but currently only 26 percent of organizations are adopting an in-house-only development approach, while 55 percent are successfully delivering apps using mixed sourcing.”

Gartner Says Demand for Enterprise Mobile Apps Will Outstrip Available Development Capacity Five to One

CD enables us to deliver the business value inherent in new software releases to our customers more quickly. This capability helps the company to stay a step ahead of the competition, in today’s competitive economic environment.

We noticed that the frequent releases enable the application development teams to get faster feedback from the users of the applications. The feedback enables the teams to work only on the useful features. When a feature is found not useful, no further effort will be spent on it. This helps the team to build the right product.

Before, the team usually got to know the thing that they were building was not useful, until after the next big release. By that time, they had already spent months of efforts on it.