Archive of posts with tag 'Saas'

If you’ve been involved in investing or fundraising activities in the past, you’ve likely heard about “TAMs” (total addressable market), as in “So what’s your TAM look like?” The general idea is to determine a metric that communicates in few words the nature of a given market for a product or service. Investors want to know how a company thinks about its market opportunity (investors generally want large ones), and startup founders need to have a sense for what they can realistically target, build for, sell to, and capture to build a business. You may also have heard of TAM’s cousins, like SAM and SOM (serviceable addressable market and serviceable obtainable market), but let’s stick to the big one here.

TAM is part of the lingua franca of the fundraising process, a term thrown around casually and understood in a variety of ways by investors and operators alike. For those of us on the operator side of the table, calculating your TAM is a necessary part of the company-building and fundraising process. Most founders don’t start with the question of “What’s the biggest TAM I could target?” before starting on their idea. Picking apart the market specifics is typically downstream of prototyping an idea for a job to be done. As a founder you have to think about how to effectively communicate just enough here to be useful to the audience. But how is TAM useful? What is an investor doing with those numbers beyond saying “Yep, this is big enough”?

What TAM analysis is good for

Firstly, a TAM serves to communicate how a company thinks about its target customer. Let’s say you build a team collaboration tool for cross-company projects. Who are the targets? What size companies? Is there a narrower industry focus? Generally the wider your target, the harder it will be to convincingly portray a useful TAM. Simply saying “anyone on Earth could be a customer, our TAM is $500 trillion” won’t persuade anyone, not to mention you’ve got quite the uphill battle to build and sell to such a broad audience. Being narrower isn’t a flaw, it’s a feature.

Which brings me to the second use for TAM: signaling the quality of your thinking about your business. A thoughtful, concise TAM analysis functions not only as a means to convey who your target is, but also as a sign of how thoroughly you’ve thought about the prospects of the business itself, meaning how to tackle a go-to-market. If you can tell a persuasive story about your target market, it lends credibility to why an investor should trust you with their money. A sloppy, or overconfident, or poorly-articulated market description (even if you have a baller product) doesn’t reassure anyone that you’ll be a good steward of the dollars. It’s like some people say about college degrees: they’re useful as signals of wherewithal and commitment as much as they are on their own merits of intelligence. They signal that you see something through to the end, a quality in higher demand by some employers than whether you have a BS in physics or a BA in philosophy.

But enough about the reasons why TAM matters. Let’s cover some reasons it’s not very useful, at least beyond a “qualifying variable” stage.

Then what’s wrong with TAMs?

Well, nothing is “wrong” with them, but they are quite often overvalued. For investors, how you read a TAM analysis and what emphasis to place on it is something to be circumspect about.

For one, markets aren’t static fixtures; they move, expand, and contract all the time. They’re moving targets. Sure, even with an understanding of this factor, a TAM can be useful as a snapshot in time as it stands the moment a deal is getting done. Even well-defined categories move all over the place. It’s more informative to look at it directionally — whether the market is expanding, or if it’s shrinking or being subsumed by an adjacent one.

Some of the best startups are great precisely because they’re targeting a strange combination of submarkets, or they’re in the early stages of creating a category, where there isn’t even an agreed-upon way of describing it yet. Conjuring TAMs for startups like this involves a mixture of alchemy and storytelling that can sometimes be unconvincing in the early days¹.

For example, I’ve been building a low-code platform for field service organizations since 2011, but I’d never heard the term “low-code/no-code” (and we didn’t use it) until the mid-2010s sometime. Had we oriented on the “TAM” of no-code back then, what would we have determined? If you could even define a known boundary around the category at that time, it was probably in the 10s of millions or maybe $100 million total. Now the market is expanding at a CAGR of 30%, headed north of $180 billion by 2030, from around $10 billion in 2019. This market became a known one gradually over time. Initially it was just an undifferentiated, messy mass of people and companies doing things that looked similar to one another with app-builder tools, WYSIWYG editors, and pluggable integrations. Over time the ecosystem became legible and better understood, and now it’s a named category tracked by the likes of G2 and Gartner. But, importantly, some of the best investments in the space happened long before analyst acknowledgement. These are lagging indicators if you’re looking to be the first in, funding the most exciting new ideas.

But an even more important reason why TAMs are dangerous is that even if a market itself is relatively stable over time, your company doesn’t need to be stable. A company has agency. A great product team doesn’t stand still and let their market “happen to” them. Dimitri Dadiomov nails it here — couldn’t have said it better myself:

A hill I'll die on: to calculate a TAM is to insult your product team.

Amazon's TAM was never book sales. Sony's TAM was never rice cookers. Starbucks's TAM was never whole beans.

"TAM" presumes zero future creativity - if you believe that, definitely don't invest in that team!

— Dimitri Dadiomov (@dadiomov) September 13, 2022

Part of the calculus with investing in an early product is measuring the future potential of the founders and the company. How a TAM is computed given the current status of a market, or the fitness of a product to said market, is irrelevant to capturing the future potential. A great product team will not stand by and let a better market, or a more focused market pass them by. In the best instances of this, in fact, startups can be singularly responsible for (or close to it) the creation of a market from whole cloth. Or at minimum they can greatly accelerate the realization of latent, obscured demand. Think iPad for tablet devices, Dropbox for personal cloud storage, Salesforce for CRM.

All of this is largely academic if you’re researching your market size to communicate with stakeholders. Take these tips for sizing and refining your definition and run just enough with them to communicate clearly. Just be wary not to internalize too directly the left and right bounds of your market. That’s not to say that defining ideal customer profiles is a bad thing… Far from it! But there’s a difference between “Alex here is the type of persona we’re building for” and “Our market is X big, and defined in this specific way.” Taking to heart what your market looks like without appreciating your own ability to change it can drive fatalistic behavior on the team. If your success in a market is flagging, or you’re making discoveries that the go-to-market angles into a specific customer set aren’t working, you have the steering wheel. You can change course, experiment your way into new markets, and make your TAM simply a snapshot of where you are, not a strict destiny.

An interesting post from Sandy on the “stealth objection”: when a customer, investor, user, employee — anyone — harbors some resistance to what you’re selling them, but doesn’t make it explicit.

My experience here is mostly in getting users to buy or adopt our product. Anytime you’re showing off what you’ve got and selling them on the concept, some objections are out in the open. “It’s too expensive”. “It doesn’t support SSO”. “I can’t integrate with X”. These ones are on the easy end of the spectrum. At least you know where you stand!

But a stealth objection can actually look like like acceptance! You see this particularly when seeking feedback from people on a new thing you’ve built. You ask “what do you think? Could you see this fitting into your workflow?” And you get responses like “That’s cool. I could see some teams needing that for sure.” It masquerades as validation, but might be a simple platitude to be friendly. They may be thinking “This would never work for us. This adds extra steps in our specific process.” If you run too far with platitudes and compliments and don’t dig for the real truth, you might not even stop at indifference. You might take it as validation.

I really like this example from Sandy:

For example, sometimes someone working for the prospect gains from the same sub-par status quo that a startup’s solution fixes - that gain is the stealth objection.

Sometimes the time, money, compliance, or quality-of-life benefits of your solution run against the incentives of stakeholders in the room. Being aware of this possibility helps you keep your hackles up to make sure there isn’t closet resistance you’re up against.

🧱 Where Are the Robotic Bricklayers?

Brian Potter wonders why work as taxing and seemingly-mechanically simple as brick masonry is difficult to automate:

Masonry seemed like the perfect candidate for mechanization, but a hundred years of limited success suggests there’s some aspect to it that prevents a machine from easily doing it. This makes it an interesting case study, as it helps define exactly where mechanization becomes difficult - what makes laying a brick so different than, say, hammering a nail, such that the latter is almost completely mechanized and the former is almost completely manual?

Even with the number of problems we’ve solved with machines and AI, something as basic as handling mortar still requires the finesse of human hands, a task which, while actually very hard to learn (it’s why masons are still skilled artisans millennia after its invention), can be taught and repeated on autopilot by masons. It turns out non-Newtonian materials are hard for machines:

There seems to be a few factors at work. One is the fact that a brick or block isn’t simply set down on a solid surface, but is set on top of a thin layer of mortar, which is a mixture of water, sand, and cementitious material. Mortar has sort of complex physical properties - it’s a non-newtonian fluid, and it’s viscosity increases when it’s moved or shaken. This makes it difficult to apply in a purely mechanical, deterministic way (and also probably makes it difficult for masons to explain what they’re doing - watching them place it you can see lots of complex little motions, and the mortar behaving in sort of strange not-quite-liquid but not-quite-solid ways). And since mortar is a jobsite-mixed material, there will be variation in it’s properties from batch to batch.

💶 On Medici and Thiel

Rohit Krishnan makes the case for more Genius Grant-style programs.

📊 Airtable: The $7.7B Roblox of the Enterprise

Will Airtable become the “Metaverse for the Enterprise”? In this detailed analysis, Jan-Erik Asplund dives into the bear and bull cases for what could become of the unicorn spreadsheet successor.

The world Airtable is imagining is a world where knowledge workers no longer have to assess different vendors’ offerings when they want to build a new functionality or experiment with some new type of workflow. Instead, Airtable argues, workers should be able to spin up their own tools using building blocks as simple, but capable of as much complexity, as a set of legos.

Morgan Mahlock wrote recently about the promise of Stripe Press, Stripe’s book publishing outfit:

Within the legacy publishing industry, Stripe’s young publishing press is refreshing - it is Sutherland’s electric cover art on a dusty, tired bookshelf. An Authoritative Look at Book Publishing Startups in the United States by Thad McIlroy states, “Book publishing has never been a technology-adept industry; indeed it is historically technology-averse. This is a challenge for the (minority of) startups targeting existing publishing companies.” Stripe Press is different because it was born from a technology company. It is a strategic asset because it allows Stripe to shape and share influential knowledge with its interconnected ecosystem of entrepreneurs, businesses, authors, and technologists.

Her post gives a good summary of why Stripe Press is exciting for the book publishing industry. The catalog only sits today at 10 titles, but I believe 4 those were released this year. The pace has been increasing, but they keep elevating the quality bar.

They’re not only attracting original works like Nadia Eghbal’s excellent Working in Public (2020), but also breathing new life into notable books from the past. Both Martin Gurri’s Revolt of the Public (published in 2014, one of my favorites this year) and Donald Braben’s Scientific Freedom (2007), to name two examples, saw relatively small initial publishing runs. The editorial staff over at Stripe is doing amazing work to bring these books back into wider circulation using a spotless curatorial eye for the noteworthy and influential.

Stripe Press is, of course, producing excellent books for us to read, and giving authors writing about technology a channel for getting their work out there. But it’s also a marketing channel for Stripe.

Content marketing, my favorite of the marketings

I have a soft spot for quality content. The best content marketing doesn’t feel anything like marketing. Its value is so deep you don’t even think about what you’re giving in return to its creator.

The tech companies of the last 20 years didn’t invent content marketing, though our scene talks about it more than any other. Even Ben Franklin used a content marketing play when he published Poor Richard’s Almanack as a way to promote his printing business.

The scene is now full of companies that embrace the multichannel returns they can drive through quality, helpful content. A few favorites of mine:

• Zapier’s technology guides
• 1Password’s combo of business and security practices
• Buffer’s podcast on social media
• Basecamp’s Ryan Singer writing Shape Up, on processes for product teams
• SaaStr’s bottomless resources on Quora (if there was a “SaaS MBA,” you can get one from following @jasonlk)
• Stripe’s fantastic guides for startups

Not only does Stripe do a stellar job at the traditional CM channels — blog, help guides, developer documentation, email — they went farther than anyone and became a book publisher¹.

What differentiates Stripe as a publishing house from the HarperCollinses or Hachettes is that it’s not their core business, but a component that drives other parts of the business. Direct sales revenue is only 1 channel of value they’re deriving from putting this catalog in print. Stripe sees their Press group as a content marketing strategy, especially to raise global interest in technology, pushing their mission to “raise the GDP of the internet.” At the most tactical level, the Press catalog increases interest in tech, creates more founders, who then start companies that become Stripe customers.

Stripe flywheels

I linked a while back to Max Olson’s excellent post Advantage Flywheels, which presents a great framework for analyzing the causal loops that power businesses. Irrespective of Press, Stripe’s built a fantastic advantage with feedback loops combining in powerful ways. Using Max’s same architecture of flywheel archetypes, I took a stab at drawing out what Stripe’s machinery looks like, with its products in blue:

At its core, Stripe serves developers who build applications which expand in usage and generate financial transactions.

Spinning off from those central inputs and outputs are several flywheels that create momentum that feeds back into the core business. Radar does fraud detection, which improves with masses of transaction data. Billing and Sigma are tools that improve finance management and reporting. Atlas helps founders incorporate and get started, thereby generating more customers for Payments, Issuing, and more. That’s where I see book publishing fitting into the machine: as a mechanism to expand the TAM for internet businesses.

Press is unique in this regard for a tech content strategy. Normally something like a blog, video channel, or newsletter would be tied more directly to the “more developers” nexus, but for Stripe, book publishing is playing a longer game. Even though this feedback loop has a long time delay (publishing a book won’t make a new founder overnight), I believe it’s a powerful one. The best strategies serve more than one function; Press is a brand builder, a recruiting tool, a direct revenue driver (from book sales), and most importantly, a way to increase the number of people interested in technology over the long term. Founder Patrick Collison himself described this exact strategy in response to a Hacker News thread:

The vast majority of Stripe employees (and there are now more than 1,000) work on our core functionality today. But we see our core business as building tools and infrastructure that help grow the online economy. (“Increase the GDP of the internet.”) When we think about that problem, we see that one of the main limits on Stripe’s growth is the number of successful startups in the world. If we can cheaply help increase that number, it makes a lot of business sense for us to do so. (And, hopefully, doing so will create a ton of spillover value for others as well.)

Stripe’s long been known for it’s writing culture, so I suppose it’s also not surprising that a company of readers and writers would want to make books.

When you pop the hood on a strong business like Stripe, you’re always likely to find interesting systems dynamics — multiple outputs feeding other inputs. It’s fascinating that an old, traditional business like publishing could be done in a novel way like this. They’re positioned to bring in new innovations for authors (and readers) that they haven’t scratched the surface on yet; it’s still just paper books. If there’s room for innovation in writing books, Stripe will find it.

📕 Stripe’s Guide to SaaS

Stripe Atlas has a great batch of guides on various parts of company-building.

📜 A Few Rules

Some great random clippings from Morgan Housel. I’m currently reading his latest, The Psychology of Money, which is great so far.

📈 The 10x Advantage of Starting a Company Now

In many markets during COVID, startups have a host of advantages over their incumbent competitors:

Consequently, growth and innovation efforts are quickly deprioritized or even fully abandoned. Incumbents place their primary focus on stopping the decline of existing revenue streams rather than creating new ones. This mindset slows them down even more during crises and tethers them to mature and declining business models.

That’s why right now, startups have even more room to maneuver in and around (and even beyond) their bigger competitors than in “good” times. Startups can try more things without attracting a response or even being noticed. It also gives Founders time to iterate and test more, granting more runway for one of the holy grails of startups: product-market fit.

David Skok opens this post on selling with the classic sales training mantra — customers love to buy, but hate to be sold to:

Customers hate being sold to. They don’t mind getting expert help when they want to buy something. But much of the time they are not ready to buy, and one of the most irritating things is to have a salesperson try to get them to buy when they aren’t ready. Unfortunately too many people in marketing and sales positions don’t seem to understand this, and proceed to irritate their potential customers.

As one of the only “sales”people for the first 5 years of Fulcrum’s growth, I can attest to this working well for for myself. In my case my natural distaste for sales and total lack of experience doing it sort of forced me to figure out that this model was the only way I could get customers interested.

A self-service product helps, where you can rely on the ability to get the customer to buy something small at first that they can then grow into — a land-and-expand style of product. In SaaS, the game is all about expansion and retention. For the company, it’s not a life and death situation to maximize customer revenue right out of the gate. In fact, some of the strongest customers you’ll build are the ones that grow into your product organically over time. Champion-led adoption builds incredible gravitational pull around your product if you keep improving and continue expanding the value you’re delivering.

The best thing you can do in the early days is to help. Help prospects not only with your product, but help them with tips and tricks, help clean up their data, help connect other tools, and overall be a source of expertise that they can trust.

Customer success teams in SaaS are most closely associated with measuring and preventing churn in business, often even having compensation or performance metrics tied to churn rates.

We look to CS teams to identify churn early, but the project of reducing it isn’t only in their hands.

This piece from Kyle Poyar makes the case with examples of how other teams should be participating in retention. After all, churn is only a signal of something missing about your business — the support wasn’t there, the product didn’t solve a problem, the pricing model didn’t work for them.

It’s a good thing to remember that churn is not some isolated phenomenon; it’s lagging evidence of a missing link in your value chain. If a customer leaves because you’re missing an integration, that’s a product problem, but one discovered long before they cancel their plan. If they resist adding new seats and are looking for excuses to remove users, perhaps the pricing and packaging model is a wrong fit for the problem being solved. Maybe you pushed to hard on closing the deal and sold to a non-ideal buyer inside an otherwise ideal company.

All of the examples are levers that impact churn, some very directly, some as second- or third-order mechanisms.

Tracking your churn rates is step one to diagnosing where it’s coming from. Approaching churning (or even just stalling) customers with a jobs-to-be-done and pain identification objective should help uncover the deeper causes of churn you can do something about in teams other than customer success.

I recently watched this Mark Roberge session where he had an interesting way of describing the challenge that follows product-market fit. Tons of startup literature is out there talking about p-m fit. And likewise there’s plenty out there about scaling, leadership, and company-building.

One of the most fascinating stages is in between, what he calls “go-to-market fit.” This is where you’ve found some traction and solved a problem, but haven’t figured out how to do it efficiently. Here’s how you think about the key goals in each phase:

• Product-market fit: customer retention
  • If you can attract users but they don’t stick around, you aren’t yet solving a painful problem (assuming you haven’t let pricing and other things get in the way)
• Go-to-market fit: scalable unit economics
  • You know you’re there when you can repeatably deliver something valuable scalably and profitably

In each of these cases the real measurement lags your execution, so you need to find a proxy metric that predicts the goal number.

You can find metrics that are predictive signals of retention, but they’ll shift from product to product pretty widely. Things like active sessions, session lengths, sign in frequency, time-in-app, and the like can track with likelihood to stick around, but you’d have to experiment with ways to measure this if you’re in pre-product-market fit territory.

To predict go-to-market fit, you should know what a set of scalable and profitable metrics look like for your business. If you set down your target unit economics, like the LTV:CAC ratio (Mark uses the industry-common 3:1 as an example), you can work backwards to daily behaviors you can orient your team on to see how sustainable your pricing, packaging, and positioning are. It might take some experimentation given the acceptable goals would vary by company, but what you want to do is pick things you can measure quickly, like driving all the way down to leads per day, so you can adapt and change your tactics to zero in on what works. Waiting around for longer “actuals” to come back from accounting on your revenue means you can’t change quickly enough to sustain unprofitable models long enough to figure it out.

We often think a lot about product-market fit stage being the fast and loose experimental phase of a startup, but what Mark makes clear here is experimentation doesn’t stop — it merely shifts from product and customer success to sales and marketing. Though the tighter all these areas work together to experiment, the better the results.

🧮 Neutrinos Lead to Unexpected Discovery in Basic Math

As long as you consider linear algebra and eigenvectors “basic math”:

They’d noticed that hard-to-compute terms called “eigenvectors,” describing, in this case, the ways that neutrinos propagate through matter, were equal to combinations of terms called “eigenvalues,” which are far easier to compute. Moreover, they realized that the relationship between eigenvectors and eigenvalues — ubiquitous objects in math, physics and engineering that have been studied since the 18th century — seemed to hold more generally.

🚙 Waymo celebrates first year of self-driving taxi service

Progress here seems positive:

The Google-backed service has delivered more than 100,000 trips to more than 1,500 monthly riders in the Phoenix area, according to a blog post. The number of weekly rides has tripled since its first full month of service in January 2019.

🆓 The Three Rules of Freemium

I’ve been reading more lately about freemium models in SaaS, where they work, where they don’t, risks vs. upsides. This is a good one from Christoph Janz on the basics.

Unlike most other enterprise software, which traditionally used to be chosen by the IT department, Dropbox is typically adopted by individual employees from various departments, who then lobby management into switching. As I noted in my piece, Dropbox was one of the early champions of the ‘consumerization of enterprise software’ movement, which was one of the strongest drivers of SaaS success in the last ten years.

But not every SaaS company can be a Dropbox or a Typeform. Done wrong, freemium can end up cannibalizing your paid user base while also draining your company’s precious engineering and customer support resources. So how do you know if launching a freemium product is the right move for your company?

IT consumerization is one of those secular shifts that’s changing many factors in the software space. The key to getting freemium right (assuming your product and market are conducive to it in the first place) seems to be a willingness to experiment with where the boundaries should be between what’s free and what isn’t.

In SaaS there are dozens of common metrics to measure on performance, like a pulse check on your company. Because of the often-high customer-to-revenue ratio with SaaS products, recurring revenue itself becomes a watermark metric to watch as an indicator. Recurrence leads to investing in and measuring customer success metrics, in order to keep that recursion happening indefinitely — customer lifetime value gets large with satisfied customers!

NPS, time-to-value, net retention, and customer health scores are just a few of those metrics that help give you a leading indicator of future revenue potential.

I love the term “second-order revenue” as a way of emphasizing the value of these customer success tactics. First-order revenue is that which is generated directly by a customer. Second-order revenue is money that is a step removed from, but still derived from, that customer. Some examples:

• Customer implements your product at one company, switches to a new company, then rolls it out there, too. One relationship, two accounts.
• Referrals from one customer to other folks in their network — why NPS is so valuable!
• Word of mouth is a type of referral, but is frequently less direct. Customer hears “good things” about your product from people in their network, an event they attended, or similar, then buys for themself.

For a company with good product-market fit and a high NPS, it’d be amazing to calculate hard numbers around second-order revenue. It can be hard to trace the exact source of a customer — often it’s not a single thing, but a combo. We’ve found single individuals that highly value our product can drive enormous amounts of benefit by getting this exchange right.

As Jason Lemkin says in the SaaStr post linked above: “don’t shortchange second-order revenue.”

Any business that makes money from the same customer more than once can be said to have “recurring revenue.” But the term in the SaaS universe has a more specific flavor to it, thanks to the unique nature of the business model, value delivery, and the commitments between vendor and consumer. You may think “so what” when you hear that SaaS revenue is special or somehow better than other ways of making money; after all, the money’s still green, right? But there are a number of benefits that come with the “as-a-service” relationship between vendor and customer. Software companies fit uniquely well with a subscription-based model because of the fixed, up-front heavy nature of the investments required to build software platforms. In a traditional business performing services or building physical products, new customers come with higher marginal costs — the cost incurred to add each new dollar of revenue. With hosted software there are certainly marginal costs (scaling servers with growth, providing support, etc.), but the gross margins are typically much higher. And if done efficiently, that margin can stay very high even at scale.

Let’s review some advantages of SaaS, each of them a mutual advantage to both the vendor and customer¹:

Simpler adoption

Because the customer is buying a product that already exists (not a bespoke one), there’s no need to wait for complex customizations right out of the gate to realize initial value. In order to maximize customer growth and expansion velocity, developers are motivated to create smoother implementation experiences harnessing tools like Intercom, with in-app walkthroughs, on-boarding, guides, and help content to get the customer off the ground. A traditional “old world” software company is less motivated to make on-boarding such a smooth experience, since often they’re already required to do on-premise implementations and trainings for users. There are certainly enterprise SaaS products that start to move into this arena (i.e. non-self-service), but typically that’s due to the specifics of certain business workflows being reliant on custom integrations or customer data imports (think ERP systems). Also, because a customer can start small with “pilot” sized engagements at no additional cost to the vendor, they can ramp up more comfortably.

Low initial costs

Related to adoption, the customer can control their costs transparently as they scale, to see impact before they expand team-wide. Once initial ROI is visible, subsequent expansion is less painful and much easier to justify — after all, you have results to prove that the product is useful before going all-in. The ability to hedge risk in scaling up by monitoring value returned is one that was hard to achieve in the days before service-based products.

Reduced time to benefit

Since the customer can lower the requirements for an initial rollout, they can see benefit quickly. Rather than having to take a salesperson’s word for it that you’ll see an ROI in 6 months, a 30-day pilot can deliver answers much more quickly. Don’t take the vendor at their word; use it for yourself and prove the value. Imagine what it would take to realize any benefit from a completely custom-built piece of software? (Hint: A long time, or maybe never if you don’t ship it. This should cross a customer’s mind when they want to build instead of buy.)

Economies of scale

The SaaS vendor is responsible for hosting, improving, and developing the core systems to the benefit of many at once. The revenue benefit of individual improvements or features are realized across the entire customer base. With good execution, the economy of scale can make the new feature or capability cheaper for each customer, while generating more aggregate revenue for the vendor — everyone wins. Compare this with scaling boxed software or even self-hosted, on-site software where human hours are required for each customer to deliberately receive new things of value. With product maturity, not all new developments provide equal value to every customer, which is where product packaging and positioning becomes critical to align costs and outcomes.

Continuous (versus staggered) upgrade

Any engineer knows that small, frequent updates beat out large, infrequent ones when it comes to efficiency. The overhead involved with testing and shipping each release is minimized, then spread over hundreds of small deployments. With tools like continuous integration, automated testing, and rolling deployment, developers can seamlessly (and with low risk) roll out tiny incremental changes all the time, silently. Every SaaS product of note works this way today, and often only the largest customer-facing features are even announced at all to customers. With many small releases over few large ones, the surface area for potential problems is reduced enormously, making a catastrophic problem far less likely. Also, customers don’t have to arbitrarily wait for the ArcMap 10.1 update or the annual release to receive a minor enhancement or bug fix.

Alignment of incentives

This, to me, is one of the most important factors. Two parties that share incentives make for the most advantageous economic relationships. Both vendor and customer have incentives that benefit both sides baked into the business model, and importantly, these incentives are realized early and often:

• Customer Incentive: Since the customer has a defined problem for which they seek a solution (in the form of software), they’re incentivized to pay proportionally for received value, security, attention, support, and utility. With a subscription pricing model, customers are happy to pay for a subscription that continues to deliver value to them month after month.
• Vendor Incentive: For a vendor, the real money is made not from the first deal with the customer, but from a continued relationship over a (hopefully) long period of time. Known as lifetime value (LTV), the goal is to maximize that number with all customers — a good product-market fit and customer success strategy leads to long LTV and therefore very large revenue numbers. To realize that LTV, however, it’s incumbent upon the vendor to stay focused on delivering the above — value, security, support, et al.

With these incentives in lock-step, everyone wins. After achieving product-market fit and a repeatable solution for customers, you turn attention toward continued engagement in customer success, incremental value-add through enhancements and new features, and a long-term customer relationship based on mutual exchange of value. The best customers not only drive high revenues to the top line, but also become better companies as a result of using your software. We’ve had this happen with Fulcrum customers, and for a product developer, it’s the thing that gets your out of bed in the morning; it’s why we do what we do, not just to make money, but to transform something from good to great.

Alignment in vendor-customer goals used to be harder to achieve in the pre-SaaS era. A vendor needed only to be “good enough” to secure the single-point initial purchase, and could largely shirk their end of the bargain in successive months².

Subscription models for physical products

Subscription business are no longer limited to software. We now see companies operating in the physical realm moving into subscription models — Lyft Pass for transit, Blue Apron for food delivery, or even Apple’s movement in this direction with its Upgrade Program for iPhones³. Once the economics make this possible (more expensive in up-front capital for physical versus software), the subscription model turns into, often, a better deal for both sides.

The market is moving toward services for everything, which is a good thing for the industry all around. Okta’s Businesses at Work report for 2019 reports that their customers are using commonly over 100 apps with Okta in the first year of use. In fact, all of the trends they report on show strong motions up and to the right. Given what I said previously about incentive alignment, I’m a believer that these trends are great for the software economy as a whole, with all parties benefiting from a healthier marketplace.

This talk from a16z’s Martin Casado covers how the market for B2B SaaS go-to-market is changing from sales-driven to a marketing-driven. We’ve been thinking a lot about this lately in the context of Fulcrum — how the “consumerization of IT” plays into how business users today are finding, evaluating, purchasing, and expanding their usage of software.

As he describes in the talk, consumer business tend toward a marketing-led GTM, and enterprise ones toward a sales-led GTM. A combined sales-plus-marketing approach to customer enablement and growth is super hard to execute on, and under the hood requires an excellent “adoptable” product at the center. You’ve got to enable the customer to try and implement your technical solution through a self-service and self-adoption model.

We’ve had this kind of land-and-expand phenomenon with Fulcrum since 2011 — wherein we attract early adopter types from within a company, get traction with smaller use cases, then watch as the company spreads the usage of Fulcrum horizontally to different teams and use cases. In the beginning we structured our GTM this way by necessity (a tiny team couldn’t do full stack marketing and enterprise sales), but have come to enjoy the fruits of this decision as we’ve scaled. I can sympathize with the challenges described here, though; building the right interplays and feedback loops between sales, marketing, and customer success is unnatural for a lot of people, and hard to execute on. The silver lining is that while you might have growing pains with process, at least you’ve got interest, usage, and revenue happening regardless. The magic is in the optimization of the cycle.

Earlier this year at SaaStr Annual, we spent 3 days with 20,000 people in the SaaS market, hearing about best practices from the best in the business, from all over the world.

If I had to take away a single overarching theme this year (not by any means “new” this time around, but louder and present in more of the sessions), it’s the value of customer success and retention of core, high-value customers. It’s always been one of SaaStr founder Jason Lemkin’s core focus areas in his literature about how to “get to $10M, $50M, $100M” in revenue, and interwoven in many sessions were topics and questions relevant to things in this area — onboarding, “aha moments,” retention, growth, community development, and continued incremental product value increases through enhancement and new features.

Mark Roberge (former CRO of Hubspot) had an interesting talk that covered this topic. In it he focused on the power of retention and how to think about it tactically at different stages in the revenue growth cycle.

If you look at growth (adding new revenue) and retention (keeping and/or growing existing revenue) as two axes on a chart of overall growth, a couple of broad options present themselves to get the curve arrow up and to the right:

If you have awesome retention, you have to figure out adding new business. If you’re adding new customers like crazy but have trouble with customer churn, you have to figure out how to keep them. Roberge summed up his position after years of working with companies:

It’s easier to accelerate growth with world class retention than fix retention while maintaining rapid growth.

The literature across industries is also in agreement on this. There’s an adage in business that it’s “cheaper to keep a customer than to acquire a new one.” But to me there’s more to this notion than the avoidance of the acquisition cost for a new customer, though that’s certainly beneficial. Rather it’s the maximization of the magic SaaS metric: LTV (lifetime value). If a subscription customer never leaves, their revenue keeps growing ad infinitum. This is the sort of efficiency ever SaaS company is striving for — to maximize fixed investments over the long term. It’s why investors are valuing SaaS businesses at 10x revenue these days. But you can’t get there without unlocking the right product-market fit to switch on this kind of retention and growth.

So Roberge recommends keying in on this factor. One of the key first steps in establishing a strong position with any customer is to have a clear definition of when they cross a product fit threshold — when they reach the “aha” moment and see the value for themselves. He calls this the “customer success leading indicator”, and explains that all companies should develop a metric or set of metrics that indicates when customers cross this mark. Some examples from around the SaaS universe of how companies are measuring this:

• Slack — 2000 team messages sent
• Dropbox — 1 file added to 1 folder on 1 device
• Hubspot — Using 5 of 20 features within 60 days

Each of these companies has correlated these figures with strong customer fits. When these targets are hit, there’s a high likelihood that a customer will convert, stick around, and even expand. It’s important that the selected indicator be clear and consistent between customers and meet some core criteria:

• Observable in weeks or months, not quarters or years — need to see rapid feedback on performance.
• Measurement can be automated — again, need to see this performance on a rolling basis.
• Ideally correlated to the product core value proposition — don’t pick things that are “measurable” but don’t line up with our expectations of “proper use.” For example, in Fulcrum, whether the customer creates an offline map layer wouldn’t correlate strongly with the core value proposition (in isolation).
• Repeat purchase, referral, setup, usage, ROI are all common (revenue usually a mistake — it’s a lagging rather than a leading indicator)
• Okay to combine multiple metrics — derived “aggregate” numbers would work, as long as they aren’t overcomplicated.

The next step is to understand what portion of new customers reach this target (ideally all customers reach it) and when, then measure by cohort group. Putting together cohort analyses allows you to chart the data over time, and make iterative changes to early onboarding, product features, training, and overall customer success strategy to turn the cohorts from “red” to “green”.

We do cohort tracking already, but it’d be hugely beneficial to analyze and articulate this through a filter of a key customer success metric is and track it as closely as MRR. I think a hybrid reporting mechanism that tracks MRR, customer success metric achievement, and NPS by cohort would show strong correlation between each. The customer success metric can serve as an early signal of customer “activation” and, therefore, future growth potential.

I also sat in on a session with Tom Tunguz, VC from RedPoint Ventures, who presented on a survey they had conducted with almost 600 different business SaaS companies across a diverse base of categories. The data demonstrated a number of interesting points, particularly on the topic of retention. Two of the categories touched on were logo retention and net dollar retention (NDR). More than a third of the companies surveyed retain 90+% of their logos year over year. My favorite piece of data showed that larger customers churn less — the higher products go up market, the better the retention gets. This might sound counterintuitive on the surface, but as Tunguz pointed out in his talk, it makes sense when you think about the buying process in large vs. small organizations. Larger customers are more likely to have more rigid, careful buying processes (as anyone doing enterprise sales is well aware) than small ones, which are more likely to buy things “on the fly” and also invest less time and energy in their vendors’ products. The investment poured in by an enterprise customer makes them averse to switching products once on board¹:

On the subject of NDR, Tunguz reports that the tendency toward expansion scales with company size, as well. In the body of customers surveyed, those that focus on the mid-market and enterprise tiers report higher average NDR than SMB. This aligns with the logic above on logo retention, but there’s also the added factor that enterprises have more room to go higher than those on the SMB end of the continuum. The higher overall headcount in an enterprise leaves a higher ceiling for a vendor to capture:

Overall, there are two big takeaways to worth bringing home and incorporating:

1. Create (and subsequently monitor) a universal “customer success indicator” that gives a barometer for measuring the “time to value” for new customers, and segment accordingly by size, industry, and other variables.
2. Focus on large Enterprise organizations — particularly their use cases, friction points to expansion, and customer success attention.

We’ve made good headway a lot of these findings with our Enterprise product tier for Fulcrum, along with the sales and marketing processes to get it out there. What’s encouraging about these presentations is that we already see numbers leaning in this direction, aligning with the “best practices” each of these guys presented — strong logo retention and north of 100% NDR. We’ve got some other tactics in the pipeline, as well as product capabilities, that we’re hoping bring even greater efficiency, along with the requisite additional value to our customers.

📺 5 Learnings from Zoom

Zoom is one of those admirable SaaS companies built on solid product and amazing execution. I love this — not relying on anything sexy or super inventive, just solving a known problem better than everyone else. My favorite bit is their retention; it proves what can be done even in SMB with lock-tight product market fit:

Zoom has 140% net revenue retention. This is similar to RingCentral from our last analysis and other leaders. Zoom also shows that yes, this can be done with smaller customers too, not just enterprises.

☀️ Visualizing the Summer Solstice

This is a great quick animation showing the sun’s path across the globe during the summer solstice. It shows very clearly why, as you move toward northern latitudes in the summer you get such long days, with perpetual sunlight above the Arctic Circle.

🧭 Training the Next Generation of Mappers

The TeachOSM crew has been doing grest work training teachers how to use OpenStreetMap in their classrooms. Geographic education is critical, especially in primary education, to form a baseline understanding of the world. I got to help out at one of these workshops last year and the outcomes were truly impressive.

Since 2016, TeachOSM has trained ~350 teachers and vocational educators in open mapping techniques. So giving open mapping workshops for teachers has become a staple of our programming over the last few years. In this post, I briefly outline what we do in our workshops, why it is vital work, and how you can help us to make OSM available in geography classes everywhere.

💻 Open Sourcing Windows Calculator

Seems silly, but this kind of thing is great for the open source movement. There’s still an enormous amount of tech out there built at big companies that creates little competitive or legal risk by being open. Non-core tools and libraries (meaning not core to the business differentiation) are perfect candidates to be open to the community. Check it on GitHub.

📊 The Metrics Every SaaS Company Should Be Tracking

An Inside Intercom interview with investor David Skok, the king of SaaS metric measurement. His blog has some of the best reference material for measuring your SaaS performance on the things that matter. This deck goes through many of the most important figures and techniques like CAC:LTV, negative churn, and cohort analysis.

🎮 Shockolate — System Shock Open Source

A cross-platform port of one of the all-time great PC games, System Shock¹. I don’t play many games anymore, but when I get the itch, I only seem to be attracted to the classics.

A good overview from YC’s Kevin Hale on how to break down startup ideas:

The “solution looking for a problem” trap is all too easy to fall into, and to justify your way out of even if you fall prey to it. I love the approach here of starting with the end goal ($100M ARR) and backing into what the market size and price point would need to be to hit that target. So simple, but most of us don’t approach the thought process from that end.

I saw this tweet a couple of days back that I thought was interesting:

What’s the most interesting or useful “how I did X” blog post you’ve read in the past year? 🤔

Examples:

- How I made my first dollar

- How we acquired our first 1,000 users

- How I built my startup without writing code

— Ryan Hoover (@rrhoover) February 18, 2019

The topic of “how we got to 1000 users” is an interesting one I thought I could take a stab at…

Fulcrum’s first lines of code were written in the summer of 2011. Initially we put together a basic drag-and-drop form builder interface, the simplest possible authentication system, and a simple iPhone app that let you collect records. There was no concept of multiuser membership within accounts, and we only had a free version. The idea (with little to no planning at all) was to cut loose a free app for basic data collection and see what the traction looked like. We did have in our heads the idea that when we had “Group” account capability, that would be the time to monetize. “Fulcrum Pro”, as we called it then. That launched in around March of 2012.

I don’t recall exactly when we hit the 1,000 user mark, but from some brief investigation of data, early 2013 seems like where we crossed that milestone. About a year and a half from 0 to 1,000.

So what techniques did we use to get there?

At the beginning, the team working on Fulcrum was tiny — maybe 2 doing all the dev work, and 3 (including me) doing part-time effort on all other fronts like customer support, product planning, design, marketing, etc. There wasn’t much there in terms of resources to go around, so we had to do the bare minimum to make something customers could self-serve on their own, that was of some minimum utility.

The only driver for all of our users in those early days, probably the first entire year and a half, was inbound marketing, and really only of two types. Since each of us had a decent sized footprint in the geo Twitterverse back then, we had at least a captive audience of like-minded folks that would kick the tires, help promote, and give us feedback. I’d count that user-base in the dozens, though, so not a huge solo contributor to the first 1,000.

I would attribute reaching the first 1,000 to a hybrid of content marketing through a blog, word of mouth, and (often forgotten) an actual useful product that was filling a void left by the other more mature “competitors” in the space. With a high volume of blog posts, some passable SEO-friendly web content, and a consistent feed of useful material, we attracted early adopters in engineering firms, GIS shops, humanitarian organizations, and some electric utilities.

Fast forward to 2019 and things have changed quite a bit! Not only have we eclipsed well over 100,000 individual users, more importantly we’re approaching the 2,000 paid customer mark. Spanning anywhere from 1 to over 1,000 individual users per customer, it’s safe to call it a repeatable, successful thing at this point. Back where we crossed 1,000 users, we were only hitting the very beginning of true product-market fit.

Building something that catches on and keeping after it are hard. A key learning of mine over the course of this process is to never think you’ve got it all figured out, that you’ve cracked the code. There’s always more to be done to break past inflection points and reach the next level on the step function of successful SaaS business.

👨🏽‍💻 Okta Businesses @ Work 2019

Interesting data here in Okta’s annual report. It’s clear that the way customer’s buy SaaS is very different than the “single-vendor” purchasing preferences from years past. SaaS allows businesses to buy and integrate the best-fit tools for any jobs:

We also looked at whether companies who invest in the Office 365 suite — the top app in our network — end up committing to a Microsoft-only environment, and the answer was clearly “no.” We found that 76% of Okta’s Office 365 customers have one or more apps that are duplicative of apps offered by Microsoft. Over 28% are chatting on Slack. Nearly 24% are connecting with their colleagues on Zoom. And over 28% of Okta’s Office 365 customers are “double bundling” themselves, subscribing to G Suite as well.

28% of customers have both Office 365 and G Suite. That’s a high number for an area that many consider zero-sum competition.

⚾️ The Most Unhittable Arm in the Minors

The Rays picked up Colin Poche in the Steven Souza, Jr. trade with the Diamondbacks last season. Sounds like he’s making some waves in the farm system:

The most unhittable arm in the minors is Colin Poche. Last year, he led the minor leagues in strikeout rate. This year, he again leads the minor leagues in strikeout rate, having increased his own strikeout rate by a dozen points despite going up against much stiffer competition. When Poche pitched in High-A last year, he struck out 37% of the hitters. In Double-A this year, he struck out 60% of the hitters. In Triple-A this year, he’s struck out 50% of the hitters. All year long, over 41.1 innings, he’s allowed just three runs. He’s allowed an OBP of .185, and he’s allowed a slugging percentage of .184. Colin Poche is turning in one of the most unbelievable performances you might ever see.

🌊 Florida State Parks After Hurricane Michael

The St. Joseph’s Peninsula is special to our family, having gone camping, sailing, and fishing their growing up. The hurricane storm surge cut right through the island north of the boat launch area. I remember walking from the campground down to the marina to go fishing. Now you’d have to swim to get between them.

🛒 What is Customer Acquisition Cost?

This is a great overview of the importance of CAC in a SaaS business.

One of the enjoyable things about SaaS is how much you can modify and optimize what you’re doing by measuring various parts of your process, especially in SMB-focused SaaS. Marketing, early-stage sales, late-stage sales, customer success — it’s like a machine with separate stages you can tweak separately to make incremental improvements.

📜 The Legacy of Alexander Hamilton

On the similarities between Hamilton and Edmund Burke:

“There are several significant points of contact between the two thinkers. Both Burke and Hamilton used historical experience as the standard for judging the validity of ideas and policies. They rejected appeals to ahistorical abstraction, disparaging metaphysical and theoretical speculation. Historical circumstances were paramount in their prudential judgment. Consequently, they avoided ideological rigidity in their thinking because they understood that a priori rationalism could not account for the particular circumstances in which statesmen had to navigate the ship of state.”

🚰 Microsoft Flow

I didn’t realize Microsoft had an automation service akin to Zapier or IFTTT. Will have to check this one out and see what it can do with Fulcrum.

Fulcrum, our SaaS product for field data collection, is coming up on its 7th birthday this year. We’ve come a long way: from a bootstrapped, barely-functional system at launch in 2011 to a platform with over 1,800 customers, healthy revenue, and a growing team expanding it to ever larger clients around the world. I thought I’d step back and recall its origins from a product management perspective.

We created Fulcrum to address a need we had in our business, and quickly realized its application to dozens of other markets with a slightly different color of the same issue: getting accurate field reporting from a deskless, mobile workforce back to a centralized hub for reporting and analysis. While we knew it wasn’t a brand new invention to create a data collection platform, we knew we could bring a novel solution combining our strengths, and that other existing tools on the market had fundamental holes we saw as essential to our own business. We had a few core ideas, all of which combined would give us a unique and powerful foundation we didn’t see elsewhere:

1. Use a mobile-first design approach — Too many products at the time still considered their mobile offerings afterthoughts (if they existed at all).
2. Make disconnected, offline use seamless to a mobile user — They shouldn’t have to fiddle. Way too many products in 2011 (and many still today) took the simpler engineering approach of building for always-connected environments. (requires #1)
3. Put location data at the core — Everything geolocated. (requires #1)
4. Enable business analysis with spatial relationships — Even though we’re geographers, most people don’t see the world through a geo lens, but should. (requires #3)
5. Make it cloud-centric — In 2011 desktop software was well on the way out, so we wanted an platform we could cloud host with APIs for everything. Creating from building block primitives let us horizontally scale on the infrastructure.

Regardless of the addressable market for this potential solution, we planned to invest and build it anyway. At the beginning, it was critical enough to our own business workflow to spend the money to improve our data products, delivery timelines, and team efficiency. But when looking outward to others, we had a simple hypothesis: if we feel these gaps are worth closing for ourselves, the fusion of these ideas will create a new way of connecting the field to the office seamlessly, while enhancing the strengths of each working context. Markets like utilities, construction, environmental services, oil and gas, and mining all suffer from a similar body of logistical and information management challenges we did.

Fulcrum wasn’t our first foray into software development, or even our first attempt to create our own toolset for mobile mapping. Previously we’d built a couple of applications: one never went to market, was completely internal-only, and one we did bring to market for a targeted industry (building and home inspections). Both petered out, but we took away revelations about how to do it better and apply what we’d done to a wider market. In early 2011 we went back to the whiteboard and conceptualized how to take what we’d learned the previous years and build something new, with the foundational approach above as our guidebook.

We started building in early spring, and launched in September 2011. It was free accounts only, didn’t have multi-user support, there was only a simple iOS client and no web UI for data management — suffice it to say it was early. But in my view this was essential to getting where we are today. We took our infant product to FOSS4G 2011 to show what we were working on to the early adopter crowd. Even with such an immature system we got great feedback. This was the beginning of learning a core competency you need to make good products, what I’d call “idea fusion”: the ability to aggregate feedback from users (external) and combine with your own ideas (internal) to create something unified and coherent. A product can’t become great without doing these things in concert.

I think it’s natural for creators to favor one path over the other — either falling into the trap of only building specifically what customers ask for, or creating based solely on their own vision in a vacuum with little guidance from customers on what pains actually look like. The key I’ve learned is to find a pleasant balance between the two. Unless you have razor sharp predictive capabilities and total knowledge of customer problems, you end up chasing ghosts without course correction based on iterative user feedback. Mapping your vision to reality is challenging to do, and it assumes your vision is perfectly clear.

On the other hand, waiting at the beck and call of your user to dictate exactly what to build works well in the early days when you’re looking for traction, but without an opinion about how the world should be, you likely won’t do anything revolutionary. Most customers view a problem with a narrow array of options to fix it, not because they’re uninventive, but because designing tools isn’t their mission or expertise. They’re on a path to solve a very specific problem, and the imagination space of how to make their life better is viewed through the lens of how they currently do it. Like the quote (maybe apocryphally) attributed to Henry Ford: “If I’d asked customers what they wanted, they would’ve asked for a faster horse.” In order to invent the car, you have to envision a new product completely unlike the one your customer is even asking for, sometimes even requiring other industry to build up around you at the same time. When automobiles first hit the road, an entire network of supporting infrastructure existed around draft animals, not machines.

We’ve tried to hold true to this philosophy of balance over the years as Fulcrum has matured. As our team grows, the challenge of reconciling requests from paying customers and our own vision for the future of work gets much harder. What constitutes a “big idea” gets even bigger, and the compulsion to treat near term customer pains becomes ever more attractive (because, if you’re doing things right, you have more of them, holding larger checks).

When I look back to the early ‘10s at the genesis of Fulcrum, it’s amazing to think about how far we’ve carried it, and how evolved the product is today. But while Fulcrum has advanced leaps and bounds, it also aligns remarkably closely with our original concept and hypotheses. Our mantra about the problem we’re solving has matured over 7 years, but hasn’t fundamentally changed in its roots.

We’re about to head to SaaStr Annual again this year, an annual gathering of companies all focused on the same challenges of how to build and grow SaaS businesses. I’ve had some thoughts on SaaS business models that I wanted write down as they’ve matured over the years of building a SaaS product.

I wrote a post a while back on subscription models, but in the context of consumer applications. My favorite thing about the subscription structure is how well it aligns incentives for both buyers and sellers. While this alignment applies to app developers and buyers in consumer software, I think the incentives are even more substantial with business applications, and they’re more important long term. The issue of ongoing support and maintenance with a high-investment business application is more pronounced — if Salesforce is down, my sales team’s time is wasted and I’m losing money. Whereas if I can’t get support for my personal text editor application that’s $5/mo, the same criticality isn’t there. Support and updates are just a small (and obvious) reason why the ongoing subscription model is better for product makers, and in turn, buyers. But let’s dig in some more. What’s better about the SaaS model?

First: subscription pricing significantly reduces the “getting started” barrier for buyers and sellers. If I go from charging you $1,000 up front for a powerful CAD application to a monthly subscription model for $79/mo, you and I both win. You like it because you’re comfortable paying that first $79 with no touch to get started, just subscribing online; no friction there. I like it because I don’t have to front-load investment in convincing you of the value. This potentially expands my customer count and gets past the initial transaction quickly.

Second: there’s predictability on the spending and earning side. If you’re a buyer of fixed cost products, you have to predict ahead of time what next year’s cost might be for the 2019 version, decide whether or not you need to include it in your budget, and have to forecast possible expansion use far in advance. With SaaS you can limit all three of those problems¹. As the seller, I get to enjoy the magic of recurring revenue (or in the lingo, MRR – monthly recurring revenue).

Third: pricing is easier². In an older “box software” model, I would have to figure out the appropriate “lifetime value” my product has on the day I sell it, and balance this with what price the market will bear. Once it’s sold, there’s no space for experimentation to map price to value, the deal’s done. SaaS can be fluid here, giving me space to fit the ongoing delivery of value to the price. Of course I don’t want to be changing pricing every month, but it’s within my control to keep the pricing at an effective and sustainable level. When setting pricing, I can break it down to a smaller unit of time, as in “what value does this have to my customer over a month or quarter?”, without trying to predict how long they’ll be my customer. That’s called CLTV (customer lifetime value) and it’s a key metric to track after signing on customers. After a year or so, I have CLTV data I can use to inform pricing. Managing CLTV versus CAC (customer acquisition cost) relationship is part of the SaaS pathfinding to a repeatable business³.

So what are the downsides? I don’t think there are any true negatives for anyone. For the seller, the major downside is that you have to keep earning the money for your product month over month, year over year. And I’d say buyers would actually call that a major upside! There’s no opportunity to sell a lemon to the customer and take home the reward — if your product doesn’t live up to the promise, you might only collect 1/12th of what you spent to get the customer in the first place (see CAC v LTV!). That’s no good. In SaaS you have to keep delivering and growing value if you want to keep that middle R in “MRR” alive. I call this a “downside” for sellers insofar as it creates a new business challenge to overcome. Selling your product this way actually has huge long-term benefits to your product and company health. It prevents you from taking shortcuts for easy money.

This is the greatest thing about the SaaS model: keeping everyone honest. It allows the best products to float to the top of the market. To compete and grow as a SaaS product, you have to keep up with the competition, track ever-growing customer expectations, release new capabilities, maintain stability, and continually harden your security. Buyers are kept honest by their spend; they have to keep buying if they want the backup of ongoing support, updates, new features, solid security, and more.

One thing I’ve seen with a SaaS business is the perception from buyers that the recurring costs will incur a higher total lifetime cost for a solution. So in the case above, if my CAD software is a subscription seat for $79/mo per license, customers will immediately compare it to the old model — “it was $1,000 one time fee, now it’s $79 each month. After a year I’ll be paying more than the one-time cost. The product is core to my business, so I’ll definitely be using it longer than a year.”

While this is true when strictly comparing costs, it doesn’t tell the whole story. In the early days testing a new product, it’s hard to see where the invisible costs will be. How much support will I need? Are there going to be bugs that need patching? What if I need to call someone to troubleshoot major issues? What’ll my internal IT costs be to roll out updates? The SaaS advantage is that (in general) there are good answers to these questions; ongoing support and improvements are part of the monthly tab. Another thing you run into, though less and less these days, is the compulsion to build the capability internally. The perception of high lifetime cost compels technical buyers to spend that money on their internal IT department rolling their own software to solve the problem. Not that this solution never makes sense, but most buyers are not software companies at the core. They’ll never build a great solution to their problem and be willing to commit to the maintenance investment to keep pace with what SaaS providers are doing. Over time as the SaaS model spreads, buyers will get more comfortable with the process and better understand where their SaaS spend is going.

These two posts from Ben Thompson give a great rundown of companies switching to SaaS, and why subscription business models are better for incentives.

Since Apple changed their subscription pricing options for App Store developers back in 2016, several high-profile apps that have made the switch from fixed pricing to the subscription model. TextExpander, Day One, and Ulysses are just three that I know of and use.

I may be biased as I’ve been building and selling subscription software for years, but I love that the Apple ecosystem is supporting this now. Ulysses provides a great example: their fixed model had the price at $45 for the Mac app and $25 for the iOS app. Their new subscription is for universal access on both platforms for either $5 per month or $40 per year, plus a 14-day free trial for new users. I’d long heard that Ulysses was a great editor for writing, but held out forever on really using it because, for one, there are a ton of great text editors, but also I didn’t know how much I’d really use it once I dropped the coin. At a $5/month subscription, I don’t have to feel bad, I can just cancel if I’m not using it enough and be out a $10 or $15.

There’s been some backlash from the community about this shift from fixed to subscription models. The AppStories podcast did an episode recently on the topic with some interesting discussion. To me the reasons for backlash are threefold:

1. Users don’t like change — We’ve experienced this time and again with our product. Even when we release new features that seem universally fantastic, we’ll still get naysayers wanting a checkbox to “make it work like it used to.” Change that makes the price higher, even if it’s only perceived to be higher, or even when the alternative is the developer is no longer able to support the app, there are those that still can’t accept it.
2. Users don’t get continued (or enough) value from the product — Even if the recurring price is super low, like $1.99 per month, some users will feel like they don’t use the app enough to warrant that price forever. A flat $10 might be okay. A fair enough reason. It comes down to who the developer wants as a customer. Are they building something for the few, higher-value niche customers, or a mass market?
3. Most people are cheap — There are a shocking number of people who are willing to have subpar experiences to save some money. The frustrating part for developers is when users want the savings part, but don’t want to make that sacrifice in quality. The glut of free replacements out there makes it challenging for developers to charge anything at all for many users.

Of course it’s possible for a developer to misprice their app, to overpredict the value delivered to a user. I’ve seen it happen with SaaS products: something I use a little changes their pricing model a bit, it becomes not worth it to me anymore so I cancel. But I’m a believer that developers will tend to get this right more often than not (at least eventually). With subscription pricing, small pricing adjustments are easier decisions for a developer to make. Going from $5 to $2.50 a month is less momentous a choice than going from $50 to $25 in fixed price model. It’s better for the user, too; there’s less feeling of being ripped off, and no need for promo codes and refunds.

But hands-down the best feature of subscription models is that the apps you love get to stick around for the long haul. At this point we’ve all been burned by services we rely on disappearing on us. I’m happy to pay to keep things around that I use regularly.

Jeff Lawson of Twilio gave this talk on SaaS pricing at the Business of Software conference last year:

Everyone in the SaaS product business should watch this. Great approach to thinking through putting prices on your SaaS service.

The key is to understand all the facets of your product and what things cost you as the creator, in addition to slicing and dicing options for your customers to buy what they need. Facets like:

• Quantities (How many gigabytes? What kind of bandwidth is allowed?)
• Features (Can I do push notifications and alerts? What about management dashboards?)
• Support (24 x 7 phone support?)

These things on their own are even sometimes difficult to figure out. What are all the variables you can tweak and change about your offerings? And those are thing that you can control, properties of your own product? I still maintain that the hardest part, bar none, of building pricing models (though it seems obvious) is understanding what your potential customers are willing to pay for your service, and then making sure you can serve them a product cheaper than that.