What a (calcifying) focus on standard pricing models omits is the fascinating, crisscrossing spectrum of influences that actually shape a startup’s pricing strategy.
User/buyer behaviors that a particular model elicits both inside and outside the product. Alternating expectations across segments and categories. Progressing feature propositions. Sales motions. Not to mention, the inclinations, ambitions, and the survival of the startup itself.
In the following exchange, Tability’s co-founder and CEO, Sten Pittet (@spittet), chronicles how they’ve juggled, interpreted, and worked through these ever-unfolding factors to arrive at a pricing that works for them. “For now.”
— Pricing at the intersection of software categories and picking the per-user model
— How per-user pricing failed Tability and the change that brought 4X growth
— How even that packaged approach wasn’t perfect and the many iterations that followed
— Having a system to make sense of pricing decisions and other notes
Arriving at Tability’s first pricing model
With pricing, at first, we went as classic as possible.
Tability is a focus and alignment platform for teams, used by many for OKRs. When we started there weren’t as many direct alternatives to serve as points of reference. And pure play OKR tools showed up on the HR stack, but we had always felt much closer to collaboration products.
Being a product manager, I had experienced the challenge of not being able to map outputs with outcomes across all the thinking, planning, and execution that went into sprints and long-run activities. There were a great many tools to track projects, but nothing in place to trace goals with the same rigor, that’s why we decided to build Tability.
Thus we looked at productivity/collaboration software for pricing cues. We went with the per-user model because it was the standard in these categories.
Then to determine, exactly, how much we’d charge per user we dug into the stack that our potential customers were already paying for and would likely place us in, and also on how often they’d use us in comparison.
You have tools such as Jira and Trello that are used every day. Whereas for Tability, we knew the usage would be closer to once or a couple of times a week. That distinction was reflected by pricing Tability lower than most of those project management tools.
Aside from introducing an enterprise plan with some enterprise-ready features, we made no major changes to that per-user pricing structure for the first year and a half. Until a particular usage pattern (or the lack of it) caught our attention.
“This wasn’t even the worst consequence”
What we were learning was that a key SaaS operating benefit — expansion — wasn’t taking place as often as we had expected. Either teams weren’t adding new members to the product at all or they were doing so at a much slower pace.
This wasn’t even the worst consequence.
For companies to find value in Tability, for collaborative goals to work, for OKRs to work, the entire org (not just the leadership team or senior management) needs complete transparency.
Everyone should be able to access what different teams are focussed on, where they are successful, where they are struggling, and where someone can step in and help.
As we started talking to customers who were hesitant to onboard more people, we found out that they felt that not every user was getting the same value out of Tability.
To them, it made sense to pay for the leadership team, but they questioned adding the rest of the org at the same cost per user. Thus Tability was increasingly restricted to a select few users.
Resulting in a sort of top-down adoption. Opposite of what we had intended. Opposite of what we had learned made teams successful.
Because with some products (for ex: Slack), it’s clear that you are not going to leave people out. For a product like ours, it’s less obvious. Some of our customers were like, “well, who needs to know the goals? Maybe just managers?”
Our first response was to educate.
To explain, across different comms touchpoints, how they’d get more value out of the product if they were to commit to more people, and in turn, the price wouldn’t then seem as expensive.
That, we quickly figured, was exactly backwards.
We had to revisit how we priced Tability. Fundamentally. So we decided to move the focus away from the per-user metric to a more packaged model based on feature differentiation.
A free plan fetched you 5 users, the first paid plan at $99/m came with 100 users, followed by plans at $299 (300 users) and $599 (unlimited users).
It worked!
Quadrupled our revenue growth rate in no time. As it removed the cost friction that forced companies to debate and question who should have access. Directly impacting expansion and retention as they could clearly see where the product’s value resided.
But given pricing’s multifaceted nature, a shortcoming surfaced even with this remarkably more effective packaged structure.
Pricing’s necessary, inevitable, multifaceted evolution
We want to build a solution that both a lean, 10-member, just-out-of-beta team and a 1000+ member company can draw value from.
As, at the end of the day, a 1000-people org is often broken down into much smaller teams. We’re in the age of 100 teams of 10s, rather than 10 teams with 100 people each.
The current structure lends itself to conundrums on both ends.
For smaller teams, adding a 6th user, once they upgrade from our free plan, means signing up for paying $99/m or $1200 for a year. Instead of $36/m they would have paid with the per-user plans.
On top of that, each progressing plan contains exceedingly more valuable features. And each progression doesn’t always match perfectly with team sizes.
So if someone wants API access which comes with the $299 plan for their 6-member team, they’re now unfairly penalized, receiving far lesser value while paying us a lot more.
With larger teams, on the other hand, there’s a different story.
I recently visited a customer to spend time with their team and understand how we could serve them better. While we were out to get coffee, the leader who had brought us in raised something we’ve been hearing a lot.
He said, “Sten, we should be paying three times as much. You’re saving the team thousands of hours and I did my math. It’s ridiculous. A new vendor can come in and quote 10x with that kind of promise. You can charge us more. We won’t deny it.”
In other words, we’re leaving money on the table with our bigger customers. It’s not about being greedy, but about not capping ourselves in terms of how much value we can capture.
Because that ultimately weakens the product. To reach the same amount of revenue, we’ll have to grow X times as fast, which would require a lot more energy and effort.
So, how do we avoid punishing ourselves by pricing too low on the enterprise end and then also ensure we’re offering a much fairer proposition to smaller teams?
We’ve tried many things.
Introducing a $39/m bridge plan of sorts that allows for 25 users.
Experimenting with different value metrics.
With one model, we gave away unlimited users but had tiers (5, 20, 60) around a feature called Pages (in Tability, each team’s goals are contained and mapped on corresponding pages) per plan. Somewhat like usage-based pricing.
The reasoning was close to what we had been thinking about. “Don’t worry about users at all. Get everyone onboard.” And the actual usage of the product could be monetized directly.
We were wrong.
Because another concern with pricing and packaging is familiarity. With ‘Pages’ as a metric, people just went, “what does it even mean?”
If you’re having to explain your pricing whenever you make a sale, that clearly doesn’t work.
Another one we’ve chewed over but eventually decided against was similar to Front’s model. Which is charging a much higher, say, 50 bucks a month, per-seat price and a very small amount ($1/m) for guest contributors.
Tability’s use case, of course, is quite different from Front. Plus, I feel that such models can make your billing super opaque and if people need to contribute it’s not easy to figure out exactly what to do.
Now that Tability is way more sophisticated than when we started, we also tested going back to a per-user plan at $6/m. But, again, we quickly figured that it brought back similar adoption issues as people were reluctant to bring their entire teams onboard.
The model that’s working incredibly well (for now :)) and addresses most of the challenges I’ve highlighted so far, is a bulk-seats approach.
Where instead of having tiered, increasingly premium features, all features are available on each plan. But customers have to commit to a set number of users (10, 50, 200, or 500 seats).
This latest pricing decision was based on several factors:
— Pursuing rapid user growth: by giving out a lot of seats, customers are encouraged to add users from the start rather than deliberate over who should get access to Tability.
— Providing great value for small teams: small teams no longer have to pay a huge premium to have access to advanced features.
— Not penalizing ourselves: we removed the unlimited plan, and can scale our pricing with enterprise customers in a sustainable way.
As ever, this is still a bet to see where we’re placed on the value exchange spectrum, today.
“It’s never about whether the pricing is right or wrong”
I think, “charge more,” is good advice. Most founders should start with that. But then you should learn about other levers from the market, observe your customers, and know that you’d have to come up with multiple iterations.
Still, it’s never about whether the pricing is right or wrong, but about whether we have a system in place that helps us understand the impact of our pricing decisions.
From what I’ve gathered, the following three criteria matter most:
- Is the model enabling customer behavior that’ll make them successful?
- Does it fit a sales motion that fits your company’s narrative?
- Will it financially work for us? Will it be sustainable?
So your pricing should mirror the sales process you can afford. If you’re going to charge a lot, be prepared for longer sales cycles, procurement processes, compliance forms, and tedious spreadsheets with a bunch of questions.
Because that’s going to be your life.
Likewise, if you charge less, you have to know whether there are enough people in the market who’d make up the volume necessary for a low-ticket-price product.
Or maybe you sit in the middle.
We subscribe to the self-serve school at Tability. People find the product themselves. They can onboard themselves. They can put their credit card on their own and then run with it.
When we’re thinking about who we talk to, what language we want to use, all of that goes together with this choice. Because you have to create an identity that fits both the experience and the price that you want.
Another nuance we’ve noted is how some users adopt us much faster based on how long they’ve been at the company. If they’ve just come in as the CPO or the COO, they’re keener (and it’s easier for them too) to replace an existing way of operating with a new one.
This is not to say that legacy teams are doing it wrong. It’s just simpler for those teams to stick with whatever has made them successful and processes around goals can be deeply entrenched.
Another messaging insight we had was to not talk to most of our end users.
Earlier we’d say, “hey, you’re the person that has to do these updates, manage up, track goals, and that can be annoying. Let us help.”
But we’ve discovered that individual contributors don’t really look forward to making those updates. Managers, on the other hand, do care about their ability to understand what’s really happening in the company in a given week/month/quarter.
So we’ve tweaked the website vocabulary to talk to these people.
Then there’s this curious, organizational trend we’ve been bumping up against, mostly with larger teams, is that when they grow to a certain size, they start looking at consolidating their stack and replacing focussed products like ours with all-in-one performance management solutions.
But then, interestingly, as they grow large enough to have multiple small teams, these teams get their autonomy back and start demanding for Tability again.
All in all, pricing remains endlessly fascinating. 
Related reading from the Relay archives:
— Help Scout’s co-founder, Nick Francis, on why the per-user model works for them
— Wethos’ co-founder, Rachel Renock, on upending subscriptions-based pricing
— Trello’s co-founder, Michael Pryor, on Trello’s short-lived adoption of Slack’s active-user pricing
