Pricing >>> maximizing revenue đ°
Why there are multiple reasons and deliberations that (must) inform pricing, bringing in a COO early on in the journey, and tackling "unknown unknowns" with Safe-Fail Probes.
Welcome to the thirtieth (Yes! đ Canât thank you enough for your readership, attention, and support! đ) edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay and the interwebz. So, stay tuned!Â
In this edition, youâll find instructive and inspiring pickings from the brains of Airplaneâs (formerly Heapâs) Ravi Parikh, Tactiqâs Ksenia Svechnikova, and Latticeâs Jack Altman.
#1: âIt might seem obvious that the point of pricing is to maximize revenue, but this isnât necessarily true.â â Airplaneâs (formerly Heapâs) co-founder, Ravi Parikh, surveys, with some befitting and revealing examples, the various pricing axes founders can deploy. (Source: Airplane blog)
It might seem obvious that the point of pricing is to maximize revenue, but this isnât necessarily true. Or ratherâmaximizing the long-term revenue potential of your business might mean adopting different short-term goals.
There are several axes that a SaaS pricing model can optimize for. These are neither exhaustive nor mutually exclusive, just things we considered at Airplane or Iâve considered in the past at Heap:
Maximize adoption: Most obviously, a company can use low or free prices as a way to maximize adoption. The cheaper a product is, the more people will try it out and buy. Pipedrive has significantly cheaper pricing than most other popular CRMs.
Competitive advantage: Lower price is an obvious way to gain a competitive advantage over others. Another technique is to use asymmetric pricing strategies against competitors. For example, if your competitor charges $10 per widget, but you charge $100/month for unlimited widgets, then your customers may buy your product for the peace of mind of consistent pricing, even if some months that results in a higher price. Splice uses a strategy similar to this to sell music samples via subscription vs competitors that sell samples in one-off packs or a-la-carte.
Customer legibility: A company can present prices in a way that are easy or hard for customers to grapple with. This isnât purely about complexity. For example, if a SaaS product charges based on the number of emails sent, but the customer doesnât know how many emails theyâre going to end up sending through this product, then they donât know how to estimate how much the product will cost for them. Legibility is about how easy it is for a customer to understand what theyâll be charged. Infrastructure products can suffer from this (how many Heroku Dynos do I need?)
Implementation cost: A complex pricing model can create a large operational burden for the company. If you have a model with tons of product lines, mixtures of a la carte/per-license/per-usage pricing, complex overage schemesâthis can be a huge amount of engineering effort to implement. Itâs also a lot of work to train your sales and customer success team on how to communicate this pricing model effectively to your customers. Even if this kind of pricing scheme is revenue-maximizing, it will have a large organizational cost.
Lead qualification: Many SaaS companies have a specific ideal customer profile and want to spend as little time as possible with customers too far outside that profile. For example, a company that only serves large enterprises with high willingness to pay likely will have a pricing page that reveals no information and has a âContact Usâ button that requires you to fill out a lead form. Even for companies with public pricing, having a high published price floor and no freemium plan might help keep out undesired customers.
Price discrimination: A well-designed pricing model can extract close to the maximum willingness to pay from each customer while not keeping anyone out. This is tough to do in consumer products (everyone in a certain country pays the same price for Netflix) but much easier to do in complex SaaS products with a high degree of customizability and features that correlate strongly to willingness to pay (e.g. audit logs). An example of a company taking this to the extreme is Salesforce, with 15 different product lines and each one having a massively complex feature-and-function grid
#2: Scaling past early-stage complexities (and 180K users) with Safe-Fail Probes â Tactiqâs co-founder and CEO, Ksenia Svechnikova, profiles a framework that has aided their growth across multiple âunknown unknowns.â (Source: Relay)
For us, new acquisition strategies (like TikTok), changing onboarding email flows for thousands of new users, and setting a Zoom integration live are all complex-domain decisions. All of them have unforeseeable reactions that pose risks if not tested for.Â
For these decisions, we rely on safe-fail probes. They are very small-scale experiments that test our approach from different angles in small and safe-to-fail ways. We might send 100 emails before 10,000. Or roll out a feature to 100 users and observe what happens. These probes surface any unforeseeable issues with an approach (eg. a new onboarding email causing using churn) in contained, low-risk ways.Â
Sticking to this approach for all of our feature rollouts, integrations, and growth strategies has allowed Tactiq to scale rapidly whilst mostly avoiding costly mistakes.
âŠ
It began with deciding that safe-fail probes would be a mandate for us moving forwards. My co-founder Nick became the sort of safe-fail probe administrator. I think this was crucial - having a co-founder take ownership ensured we had accountability for applying the framework.Â
We implemented a blanket rule - at every planning meeting, for every decision, we go through a simple risk-checking process based on the framework. We ask our team - for this action, are there any possible risks we donât know about? Are there any unknown variables? Is there anything weâre unsure about? This process has been great for us because it allows us to crowdsource what domain the decision falls in.
If a decision/action is in the complex domain, our team then spitballs a list of risks and unknowns. "Changing the share-button position might cause a few users to churn", âwe donât know how users will react to an increase in intercom messagesâ or "promoting Tactiq on this channel might cause community backlash due to the anti-advertising sentiment".
We then agree on a tolerable level of risk. Are we ok if we lose a few users (1-2%)? How many angry community members would it take to damage our brand? What's tolerable?
These qualitative (possible risks/unknowns) and quantitative (what can we tolerate) form our hypothesis: "Changing the share-button should not cause more than 2% of users to churn". Armed with this statement we set about testing.
All of this happens on the spot in planning meetings as weâre reviewing/prioritizing tasks for an upcoming period. So we embed the framework as a final review before committing to anything. A final safety check before launching anything new.
The scale and volume for tests are proposed by the person responsible for testing (with domain expertise) and agreed on by our founders. We use the smallest possible sample size that is still statistically relevant. That could be 100 emails for email marketing, 10,000 users for a new language roll-out, or $100 dollars for paid ads. Our rule of thumb is: how many people need to interact with this to cover all our bases?Â
Sometimes that means testing 3 iterations of an update to our email notifications with lists of 100 users. Or finding the smallest possible investment, say $50 at a time, for a new channel and trying it out 3-4 times. We even beta-test most features with groups of 10-50 before pushing them live - even whilst rolling out 3 new features a week.
After the tests, ideas are either accepted as safe to proceed (no unforeseen negative outcomes happened) or unsafe and needing a review (eg. users were unexpectedly frustrated by the changes). The safe-fail probes give us a binary evaluation on whether we can proceed with a possibly risky action or not.
They also surface unexpected positive outcomes. For example, we ran a safe-fail test for an email marketing campaign, tested with 200 users in North America from one company. A few weeks later their Head of Accessibility reached out to us about a tender for a company-wide plan of our product. It was completely unexpected, but a great result.Â
#3: The case for a COO as the first senior exec hire â Latticeâs co-founder and CEO, Jack Altman, recounts why they brought in a COO incredibly early (âat just over 20 peopleâ) in their journey and the formative org-wide impact that followed. (Source: Jackâs blog)
âŠIâve come to believe that more startups should hire a COO than probably do. Of course they will not be right for every company â maybe not even most companies â but my current view is that every startup that reaches product-market fit should at least consider whether itâs right for them.
âŠ
I want to share my very positive experience with hiring a COO so others can consider whether a similar role would make sense in their situation.
We hired J Zac Stein, former VP of Operations at Zenefits, as our COO in November 2017 [two years in] when we were just over 20 people.
The idea was that he would be a general purpose business athlete who could run a function for a while, build up a strong foundation, leave it with great leadership, and then move on to the next thingâŠ.
In the 6 months since heâs joined, hereâs what heâs done:
Heâs overseen the sales team through a leadership transition, allowing me to run a multi-month process to hire a new head of sales. Not only did the sales team grow our revenue by over 100% in the past 6 months, but theyâve also added early versions of sales development and sales operations.
Heâs built up and led our customer experience team, as well as made the decision to bifurcate the team into customer success and customer support. This was a core area of expertise for him coming into the job and itâs given me the freedom to work on other areas knowing itâs in better hands than it was with me.
Heâs been a one-stop-shop for legal, finance, analytics, and HR (aided by contractors), allowing us to not only hold off on hiring those roles, but also to have a much more experienced set of eyes on them than we would have with more junior hires.
Now that our new sales leader is joining, heâs overseeing marketing where he can apply operational rigor and managerial guidance. This allows us to continue betting on our less experienced but extremely talented head of marketing, which is very important to me.
So heâs served as multiple VP functions, both at once and over time. Arguably, a dedicated VP in each area would do slightly better because they wouldnât be spread so thinly and would be a functional expert.
There is some truth in that, but it comes at the cost of countless hours of hiring, integrating into the team, managing multiple personalities, and other related trade-offs.
And potentially more importantly, the âexecutive gap-fillerâ role allows for much faster adjustment of organizational structure, strategy and tactics, and all sort of other organizational frictions you get with VPs who were hired on for a more specific purpose. When youâre still early in your companyâs life, this flexibility is extremely valuable.
Until next time,