Today I am speaking with Anton Zagrebelny, Co-Founder & CTO of Stigg, and he will tell us about the challenges related to pricing for B2B SaaS businesses and why it is important.
Hey! My name is Anton, and I'm the co-founder and CTO of Stigg.
I am responsible for ensuring our engineering team builds the right thing, the right way, with the right tools, and preferably - at the right time.
My typical day starts with catching up with everyone and what they're working on, then moving on to code reviews to ensure nothing is blocked or awaiting approval for too long. I then participate in design kick-offs with my colleagues, helping out new customers with integrations and talking about their use cases. Finally, whenever there are no fires to put out, I do my best to improve the quality of our codebase or prototype new tools and frameworks.
Stigg is all about creating a great experience for developers when they want to add self-service functionality and monetize parts of their product. We, as developers, are consistently thinking about how we'd like to use this new feature or SDK functionality we're planning to release. Eventually, my job is to keep the bar high around the stability and overall technical quality of what we're building.
I got into programming somewhere around the age of 10. I grabbed my first programming book (Visual Basic!) from my 4th-grade classmate whose father was a software engineer, and since then, I got addicted to coding.
One of the things that I love most about software is the absolute freedom to build almost anything you want. In my opinion, imagination is the most important skill you can have when it comes to solving problems in software, besides being vigorously patient when it comes to debugging what you've written.
I grew up as a PC kid. In my spare time, I enjoyed creating mods for computer games, and when I wasn't doing that, I built websites for local businesses as a side hustle with a couple of friends from school. After serving three years in a military tech unit, I landed my first job as a software developer for a mid-sized fintech company.
If you want to learn how to write robust and scalable software, fintech companies are a great place to learn it. You are dealing with real money, so mistakes are not an option. Technical challenges are often unique and nontrivial, like writing low-latency and performant code for high-volume stock trading systems.
This heavily depends on the company's Go-To-Market strategy, individual goals, and the company steps in the business lifecycle.
However, some of the most common changes in SaaS pricing strategies are:
With the rise of product-led growth, consumers expect to enter and explore SaaS products without having to talk to anybody from the company and upgrade when they are ready, which drastically changes the infrastructure of the company. Therefore, companies need to support free trial or freemium experiences, build mechanisms to gate higher tier features, include self-serve customer portals in their product, and add user notifications and in-app upgrade/downgrade flows.
With pricing's direct effect on revenue, companies need to expand their offerings as they want to grow. Common practices include offering a new pricing strategy, such as usage-based pricing, adding another plan to your existing model, or repackaging your pricing plans to test the effects of, let's say, adding another feature to the free plan.
There are always new trends in how SaaS builders think about their pricing, and companies eventually reach a point where rigid structures slow down their growth. So the sooner you build an infrastructure that supports flexibility in your pricing strategy, the better your position will be going forward.
At the very foundational level, pricing is the top of the funnel. It is the variable with the biggest impact on monetization and growth because it determines the size of every current and future deal. It directly impacts the three most important metrics in SaaS - acquisition, retention, and expansion.
Pricing is the most effective growth lever of any SaaS business. Two-in-five companies that altered pricing reported a 25% or higher increase in ARR.
Stats aside, "pricing" is not just the money a company charges. Pricing in SaaS is a company's entire offering to potential buyers: Which plans include what features? In which quantities? Is there a free plan, too? What's the metric a user is being charged by?… We call this the buyer experience, which is an essential part of a user's entire experience when consuming your product.
A good buyer experience needs to leave your customer with the feeling they got what they want at a price they're happy to pay. The customers' willingness to pay, however, is affected by your product (and that keeps evolving), the market (and that keeps changing), and your competition (and they never rest). Therefore, if you want to continuously deliver outstanding buyer experiences, you must start treating your pricing as you treat your product.
Me and Dor, CEO and co-founder of Stigg, used to work together at New Relic. At that time, New Relic decided to change its pricing strategy from top-down sales to bottom-up product-led growth. This decision became a several months long project and a huge demanding effort for every department in the company, as we had to re-architect our entire infrastructure.
It was back then when we realized what then became Stigg - the way SaaS B2B roll out pricing changes is broken, and we must fix it. Time to market is crucial in SaaS, and engineering teams need to focus their time on building product value. This is why we've decided to build the infrastructure that allows companies to safely ship pricing models in minutes instead of months.
The biggest challenge was building a product that served two different personas, developers and the actual decision maker behind the company's pricing strategy. Developers are often the first to take on the pricing challenge because they are assigned to incorporate it. However, it's the last thing on their minds, and they care less about the strategy details.
Meanwhile, the decision maker is often of less technical background and expects Stigg to be a no-brainer and intuitive solution that helps in comprehending the "bigger picture," seeing the impact of each pricing & packaging change, and the ability to tweak and experiment.
We've put a lot of effort into planning ahead on the way we build Stigg so we can get green checks on all of the requirements and pass the developers' evaluation committee. Building an infrastructure piece that sits as a layer between the core application and the billing provider requires an antifragile design in mind, where embracing system availability and partitioning over consistency is fundamental.
Naturally, you'd want to reduce the blast radius of failures within or outside the system, so eventual consistency is something we considered from the get-go. For example: even if the billing solution (or the CRM) is down - we can still provide service, and our customers won't be affected by that outage. The same rule applies to our internal micro-services.
It's also important to always look at Stigg from the eyes of the developer, who are our core users too. They care about how your SDKs and API work, so you can't simply cut corners in the tools offered to them. A savvy developer will easily spot those blindspots; from there, it's not far to start questioning other aspects of your product.
Stigg is a platform by design. For a platform, it's a fundamental principle that the data you send or keep in Stigg is accessible and exportable. Almost every company has its own automation and workflows, and we don't want our customers to stop using them. Such things as native integrations with external apps (Stripe, Hubspot, Segment, Zapier, etc.) and webhooks were among the first things we started building.
Basically, you can build custom experiences on top of Stigg and incorporate some of our "secret sauce" enrichments, like feature adoption metrics, median usage over periods of time, upgrade/downgrade rates, trial conversion rates, and more.
Our vision for Stigg is to become the first thing that comes to your mind when you think of starting to monetize your product.
Besides rolling out changes, we also want to empower our users in their decision-making process. For example, let's say you want to roll out a change, but you have no way to know how it will affect the overall upsell rate or if it will increase churn. With Stigg, you'll be able to create an experiment with a few clicks and test your hypothesis before committing and rolling it out to all of your customers. Stigg will also be able to predict the impact in advance by leveraging historical usage data.
Our users will have access to all these capabilities, thanks to our core product - packaging flexibility based on entitlements as granular control over core product features, which allows you to safely release new versions of your pricing plans without worrying if you break anything in the application code, billing software integration or even the public pricing page.