Menu

When your SaaS Scaleup can't scale, I can help

Tag: SaaS

Confusing The Feature With The Value

In iterative deliveryTags Publish Date248 ViewsLeave a comment jeffpsherman

I was called in to consult on a project recently where the developers, and the product managers, had confused the features they were building with the value they were delivering.

The developers had written an initial integration to a new marketing channel.  The goal was to deliver something minimal, but high quality, that they could get in front of customers in under 6 weeks.  The project hadn’t specified any UI for the customers, and the initial version offered users no feedback.  Customers could set up a campaign, but they couldn’t find out if it had completed, or how many people had clicked on a link.

With two weeks left of the original six week project, product managers stepped in with a 12 week project to add reporting.  The reporting may have been beautiful, intuitive, and powerful, but none of that mattered.  The project’s value was in the new marketing channel, not the report.  Having a polished report that would make the value easy to understand was a feature.

The project owners decided not to go with my advice and release the feature with a minimal data table report.  Instead a 6 week project became an 18 week project, and delivered no customer value for an additional 3 months.  When customers finally got their hands on the polished report, they didn’t like it and needed revisions.

Months were lost, and customers ultimately got less value, because the team had confused the features they were building with the value they were delivering.  An MVP today is worth infinitely more than a highly polished guess in 3 months.

In A Remote First World, Being Local Is The Only Leverage A Developer Has

In UncategorizedTags Publish Date248 ViewsLeave a comment jeffpsherman

I was speaking with a VP of Software Development last week and he gave me a brain bursting bon mot: In a remote first world, being local is the only leverage a developer has.  We were discussing the situation at a true remote-first SaaS; they have developers in the USA, Ireland, Poland, Costa Rica, Brazil, and Australia.  Becoming globally remote first is not cheap or easy, but once you’ve done it, the marginal cost of a developer in Poland is 60% of one in the USA.

He continued, “from a cost perspective, you can either hire more developers, or more senior (expensive) developers.  It’s no longer about where anyone inside the company is, or how hard it is for them to work together.  It’s about how well they understand the customer’s culture.”

Thirty years ago outsourcing turned out to be a mirage because the difficulty of working together outweighed the cost savings.  Today, being able to assemble people from everywhere is part of being a global SaaS.

Which begs the question, how well do you understand your customers?

Understanding Churn Rate For Subscription SaaS Developers

In SaaS MetricsTags Publish Date169 ViewsLeave a comment jeffpsherman

Churn Rate is one of the most important metrics for a Subscription based SaaS.  Churn is the term for a customer not renewing their subscription and ceasing to be a customer.  The Churn Rate is the percentage of customers you lose over a year.

Ie - if you had 100 customers paying for a subscription at the start of the year, and 95 of them renewed their subscription, your churn rate would be 5%.

Because the rate is based on existing subscribers, it can only be between 0% (everyone renewed) and 100% (no one renewed).  Churn is a key piece of Net Dollar Retention, another important metric for SaaS developers to understand.

Churn Rate is especially important and simple for developers at SaaS companies with subscription models. Anyone who doesn’t renew their subscription has churned.

What is a good churn rate?

Churn rates differ based on your market and customer type.  For example, small business churns at much higher rates than enterprise.  See this article for an depth discussion.

The 2 most important numbers:

  1. The average churn rate is 13% per year
  2. Sustainable Growth requires a churn rate below 8%/year

The higher your churn rate, the harder it is to grow, or even tread water.

How can developers reduce churn?

Customers churn for all kinds of reasons that developers can’t impact.  Smaller customers go out of business; enterprise customers have internal politics.

There are two places where developers have the greatest impact:

The First 90 Days

The first 90 days are your chance to provide value to your customers.  If customers don’t get value in the first 90 days they lose interest and try something else. 

This isn’t the time to push for long term value, it is critical that your UI guide customers to small, quick wins.

For developers, that means you need to work on two experiences:

  1. Importing data.  The process needs to be easy and fast.
  2. Reports.  Customers need to see the value.

Bugs and Performance Over Time

If you make it past the first 90 days, congratulations, your customer is likely to lock in to an annual subscription.  The 30 days before renewal, however, are not the time when a customer decides to churn.

Long term customers churn because they aren’t getting value anymore, the platform is slow, or they hit bugs.  Circumstances change, when customers are no longer getting value from your service, there’s nothing to do but wish them luck as you wave goodbye.

Is your platform fast and responsive?  Does it get slower over time? These are developer concerns!

Do your customers hit bugs?  That’s a developer concern!  Each bug increases the odds that a customer churns instead of renewing.

Conclusion

For subscription based SaaS, Churn is a simple top level metric.  Higher churn means slower growth or even negative growth.

The two key areas are the first 90 days, and long term performance and bugs.

Make it easy to get started and see value; keep the customer experience from degrading over time.

Last, remember that a lot of churn has nothing to do with your SaaS or your work as a developer!

Why SaaS Projects With “New” Or “Next” In The Name Are Likely To Fail

In iterative delivery, software designTags , Publish Date192 ViewsLeave a comment jeffpsherman

Replacing useful software is hard.  Naming things is hard.  Somehow naming projects to replace software seems easy.  

If your system is called [X], the replacement project is called New [X] or Next Generation [X].

These names aren’t “easy”, they are a sign that your project is poorly thought out and likely doomed.  This is especially true in SaaS where your customers are paying for this generation.

New [X] is a sign that your project is inward looking and hasn’t considered your customer’s needs.  Do they need “New” or do they need specific features?

New [X] invites scope creep: new idea + new [x] = features in new [x].  Does the new idea fit in with the purpose of New [X]?  Well, it’s new!

New [X] turns up the pressure on the release.  It’s new!  We couldn’t ship the features to customers incrementally, we have to do a grand reveal and make a splash!

A poorly considered project, with lots of scope creep, and the pressure of making a splash combine to doom New [X].

It is completely fine to replace useful software with a better design and new technology.  Even if you do it iteratively, the end goal is a new version of the same system.  And it turns out that there is a simple naming system you can use!

If your system is called [X], the next iteration of the system is called [X][int++].
Your customers don’t care if you replace MySaaSBackend with MySaaSBackend2.  They shouldn’t even notice.

Could you do a cold restart?

In dev teams, software designTags , Publish Date378 Views1 Comment jeffpsherman

Years ago I worked at a mortgage company that bought a bank’s mortgage division.  The deal was mostly for sales people, but it also included custom software and developers.  To ensure that the handover was clean, we were only given the source code.

We had DB Schemas, but no seed data.

This was at the very dawn of Infrastructure-as-code; we didn’t get any.

There were docs about deploying, and there were docs about building servers; they were wildly out of date.

18 months and millions of dollars in salary and opportunity cost later, the project was shut down.  We never got the system fully functional.  We never got close.

You probably won’t be sold to a competitor, but there’s a decent chance your production environment will get compromised by hackers.  

If you lost all running instances of your software and had to rebuild from whatever you had in source control, could you do it?

How long would it take?

Multiple Queues Vs Prioritized Queues at the Airport

In Algorithms In Real Life, crm, software designTags , , Publish Date505 ViewsLeave a comment jeffpsherman

Multiple Queues Vs Prioritized Queues For SaaS Background Workers was a dense discussion of queues, prioritization, trade offs, and outcomes.

This post is a much less dense discussion of the same topic with examples from airports.  Airports use a multiple queue system at Security, and a priority queue at Boarding.

Security Has Multiple Queues

Image from https://www.wanderingearl.com/the-benefits-of-tsa-precheck/

Most airports in the US have 2 or 3 different queues to get through the security checkpoint: Clear, TSA Pre, and regular.  Agents help filter passengers into the different lines.  Each line represents different priorities and has a different number of agents conducting security screenings.  Once in a line, it operates as a FIFO (First in, first out) Queue.  There’s no additional sorting.

This is a human driven Multiple Queue system, and it makes sense:

  1. The workload is highly variable.  There are peak times and slow times.  Times that favor high priority people, and times that favor regular people.  It is impractical to constantly shuffle the security checkpoint layout, so the system must accommodate all workloads.
  2. You need to prevent resource starvation.  Ie - you need to keep the regular line moving no matter how many people show up at TSA Pre 
  3. You want to minimize worker waste.  Ie - when the TSA Pre line is empty, the agent starts screening people from the regular security line.
Image from https://www.inquirer.com/things-to-do/travel/tsa-precheck-clear-plus-global-entry-phl.html

Security checkpoints are slow and frustrating.  They are also well balanced to provide a simple, understandable, system that supports multiple priorities and minimizes agent idle time.

Boarding Gates Are Priority Queues

Boarding gates, where passengers wait to get on the airplane, are Priority Queues.  

The gates operate under different constraints from the security checkpoint:

  1. Nearly all passengers are at the gate when boarding begins
  2. There are a set number of passengers
  3. All of the high priority passengers should board before any of the regular priority passengers board.  Unlike the security checkpoint, resource starvation is desirable.
  4. The resources cannot be scaled.  There’s one plane, one door, and one person through at a time.

The queues take multiple forms.  They can be simple, like United’s

Image From https://www.tripadvisor.com/LocationPhotoDirectLink-g1-d8729177-i375422300-United_Airlines-World.html

Or complex, like Southwest’s

From https://www.quora.com/On-Southwest-Airlines-have-you-been-asked-to-switch-seats-after-the-open-seat-boarding-process

The Priority Queues have a common structure.  They have self sorting guided by signs and instructions.  The ticket agent acts as a final filter, either accepting or rejecting people.  The ticket agent (the worker) always runs at full capacity, while the queue itself is extremely inefficient and keeps people waiting a long time.

Since the plane only has one entrance, a Priority Queue is the only way to ensure that the high priority passengers get on first.

Reminder - We’re Really Talking About Scaling

Airports are designed to scale.  They use Multiple Queues at the security checkpoint, because it fits the problem.  They use Prioritized Queues at the boarding gate because it fits the problem.

How should your Background Worker system be designed?

These are the considerations:

  1. Resource Starvation aka job latency
  2. Workload and priority variation
  3. Worker waste
  4. Scalability and configurability - aka how hard is it to add workers, or shift them around

If you get stuck, let me know and I’ll help you out in a future post!

The Grand Reveal Violates The SaaS Business Model

In crm, iterative deliveryTags , , Publish Date323 Views2 Comments jeffpsherman

Apple is legendary for the Grand Reveal.  Steve Jobs would say “Just one more thing” and then reveal an entirely new category of device or software.  It was amazing theatrics, shot Apple into the stratosphere, and cemented The Grand Reveal as a technology marketing tactic.

But for a SaaS The Grand Reveal violates a key principal: customers always have the latest software.  Holding back months of development and new features in order to create an exciting reveal breaks that promise.

Anytime you’re considering holding back a feature to create buzz ask yourself, does this delay help my existing customers?  You have customers that have already trusted you by buying subscriptions in exchange for the latest software.  Is it fair to hold back, to devalue the service, in order to market to new customers?

Of course not!

As a SaaS you’ve promised customers that they will always have the latest software.  Holding back breaks your promise.  Never hold back from your existing customers to market to new ones.  

Always be releasing!

Net Dollar Retention For SaaS Developers

In crm, SaaS Metrics, software designTags Publish Date415 Views1 Comment jeffpsherman

Net Dollar Retention (NDR) is one of the core financial metrics for SaaS companies, and one where software developers have an outsized impact.  This article explains NDR and how software influences can drive the number down.  Finally, it discusses three areas for developers to focus on in order to bring the number up.  

What is Net Dollar Retention?

Net Dollar Retention is the rate that your existing customers continue to spend money with your company.  Renewals are flat, churn makes it go down, and expansion makes it go up.

As a formula using AAR (Annual Recurring Revenue), it looks like this:

( [Renewed AAR] + [Expanded AAR] - [Churn] ) / [Previous AAR]

Besides being a core metric, NDR is a key metric for companies considering going public.  Typically, a company going public needs an NDR over 107%, and ideally over 120%.

Only existing customers affect this metric!  For Net Dollar Retention it doesn’t matter if you replace every customer that churns with ten new ones, your retention rate will be terrible.

How Developers Impact Net Dollar Retention

There are only two real levers with NDR: Increase spend and reduce churn; and there is little that developers can do that will directly increase customer spend.  

The top 3 developer levers to reduce churn:

  1. Fix any bugs that corrupt or lose data
  2. Make the system more reliable
  3. Make the system faster

Fix Any Bugs That Corrupt Or Lose Data

This is the big one!

Customers come to your service to get things done.  The more often they hit bugs, the faster they will churn.  Only developers can fix bugs and prevent data corruption.

Make The System More Reliable

Close second to data corruption is reliability.

95% success rates mean that you should expect a daily job will fail at least once a month.  If customers don’t trust your system to work, they will sit and watch the process.  Usually by continually hitting refresh on your site.  This is a massive waste for your customer and makes your SaaS much more expensive.

The less reliable your service is, the faster they will churn.  Reliability is more than just a developer problem, but developers will need to lead the architectural charge.

Make The System Faster

Speed is a distant third because it rarely impacts the value that customers get from your service.  Speed, especially UI speed, has a massive impact on the customer experience.

Slow websites won’t make customers leave, but they will kill your net promoter score and leave them open to a switch.

They don’t want to waste time staring at a blank screen waiting to render.  When the problem is inefficient code, it is something that only a developer can fix

NDR is a Core Metric for SaaS Health

NDR is a core metric for health, and a critical one for companies seriously looking at going public.  Developers can heavily influence the number by reducing churn.

Fix bugs, improve stability and increase performance.

Developers can push these levers and improve NDR; no one else in the company has that power!  Become a hero to your business, pay attention to NDR and how you can reduce churn!

Reduce Long Term Customer Churn From Data Growth

In crm, software designTags , Publish Date207 Views1 Comment jeffpsherman

Customer Relations are ever growing, a CRM must provide Management as well.  Punishing customers for loyalty is the inevitable consequence of not acknowledging and preparing for a long term relationship with your customers.  Destroying your customer's long term experience increases churn and kills your net-dollar retention.

Saving long term customers requires work and planning from the frontend to the persistence layer.

Here is one strategy for each layer to help get you started:

  1. Frontend: Dashboards over pagination.
  2. Backend: Historical limits by default.  
  3. Persistence: Data partitioning.  

Dashboards Over Pagination

New customers can see all of their contacts on one page.  Same for their marketing campaigns, tags, and deals.  That changes very quickly for customers who are using your system.  When customers can’t see all of their data on a single page, the solution isn’t pagination, you need dashboards.

When your customers go to their contacts, you could show them “Page 1 of 10”, or you could show them a dashboard with contact activity.  New contact counts, engagement rates, contacts who need a follow up.

A pagination is about databases, it is a terrible interface for getting things done.  Make your CRM about management and workflows with dashboards.

Historic Limits By Default

Add sensible defaults to everything to limit the amount of data searched.  Default to showing the last 6 months or 1 year of a customer’s interactions.  Keep the older data accessible, but don’t waste the user’s time loading history.

Put another way, how many extra seconds should you make customers wait to find out if a contact opened an email 3 years ago?  The correct answer is 0 seconds, and also 0 milliseconds; update your APIs accordingly.

Data partitioning

Event logs keep track of every email open, click, and website visit.  Because events rarely get deleted, these tables grow and grow with your customers.  Over time, the amount of data in the tables will cause queries to become slow.  The more successful your customers get, the worse your database problems become!

Partitioning directs the database to create different logical tables based on a key while presenting a view of the combined table.  Events are date based making them great candidates for partitioning by month or year.  The previous tip, Historic Limits By Default, places an upper bound on the data in a table scan.

Conclusion

Customer data accumulates over time, especially in CRMs.  Keeping customers for years requires preventing your system from punishing them for accumulating data.  Failing to address the problems will destroy the customer’s experience, increase churn, and reduce your net-dollar retention.

These three strategies will help you start thinking about data accumulation and how customer needs change over time.  Don’t throw away your loyal customers because your systems only consider the new user experience!

Fight Settings Cruft With A Lightweight Garbage Collector

In iterative delivery, software designTags , Publish Date178 Views1 Comment jeffpsherman

In service oriented architectures adding new application settings like environment variables, constants, and feature flags costs almost nothing.  Cleaning them up, however, is expensive.  

Ideally developers would keep track of settings and remove them when they are no longer needed.  More often feature flags get set to 100%, everyone moves on, and the old code path lingers for months.  I have personally spent hours updating code, only to realize that it is effectively unreachable and needs to be deleted instead.

Talk about wasting time and money!

The High Cost of Doing Nothing

Doing nothing seems like a cheap solution.  The code gets a little bloated, the services use a little more memory, and API calls send a few extra kilobytes.  No single unused feature flag or environment variable has any impact.

Eventually you end up with hundreds of unused settings, on thousands of servers, distributed to hundreds of thousands of customers.  

The cost of those crufty settings add up in terms of performance, development time, and outages.

Cutting Cruft Is Expensive Too

A key disadvantage of Service Oriented Architecture is that settings get passed from one service to the next.  It’s rarely safe to remove unused settings because they may be gathered into a collection and passed along to a service that does use them.

Figuring out what is used where across multiple services is a slow process.  When you’ve got hundreds of settings to investigate, it’s daunting and demoralizing.

A Very Basic Garbage Collector

A Garbage Collector keeps track of references to objects, and when there are no more references, cleans them up.

You can make a very basic collector by scripting out a few API calls to your git repository.

The three basic steps are:

  1. Download and parse the constants file(s) from the parent app and extract a list of settings names
  2. Make API requests against your git vendor searching for the strings
  3. For each setting name make a file which lists which repo the string appears in

That’s it!  You now have a rudimentary system that tracks references to settings across your repos.  Any setting file with only one entry isn’t used anywhere else and can be deleted once the parent app is done with it.

Conclusion

A garbage collector is overkill if you’re curious about a handful of settings, just use regular search.  But when you’re facing hundreds of settings and you need to figure out which can be targeted for cleanup, a garbage collector might be just what you need.

Older Posts
Newer Posts

Site Footer