“How Moving Away from Per-User Pricing Helped us 4X our Growth, Why We Were Moving Back, and Why We Won’t (For Now)” with Tability’s Co-Founder, Sten Pittet


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:

  1. Is the model enabling customer behavior that’ll make them successful?
  2. Does it fit a sales motion that fits your company’s narrative?
  3. 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. :slight_smile:


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


Sten, Fascinating read! In documenting Tability’s pricing iterations, you’ve offered a great lens for any founder who is beginning to think of that first of many, many pricing tweaks. The number of permutations you’ve been able to try out in a short span of time is brilliant.

Which made me wonder how you approach the experimentation process itself. Is this a quarterly practice of reviewing some pricing signals? Do you make it a point to bring up pricing in customer research conversations? Would be great to hear about any of those practices as well for the benefit of fellow founders. Thank you once again.


Is this a quarterly practice of reviewing some pricing signals? Do you make it a point to bring up pricing in customer research conversations?

We don’t have a set time for iterating on pricing at the moment. I’d say it’s something that we revisit every 6 months, but it’s only when we feel that enough has changed about the product or market that we consider real changes.

We’re also trying to get better at experimenting and iterating rather than going all in on every idea.


Thanks for sharing, really interesting!
How do you deal with the 1 more user problem.
Like when the extra user moves you to another tier… Do you do extra individual users, or make them go up another tier?! I love this model, but this is sometimes messy


Pricing per user amongst competition has shaken us out in research. Rate limiting based on the number of active users seemed also very unreliable for teams that will use our platform.

Pay per feature made us feel that it becomes operationally intensive at scale, also it wouldn’t be of justice to customers.

Currently, we rested on one model which seemed more value giving to the customer but would love your feedback. (1. product in beta dev but we are co-building with early customers, 2. The pricing page is not live yet).

A freemium model with unlimited users, instances, everything & anything.
A growth model with unlimited users, large upgrade of features (20+ extra features compared to freemium) & an additional charge on top i.e., Managed Cloud Service (SRE) = $X/hr + One Time Migration Service = $500

How do we price this?
Mission: Highest Value to Customer while saving time and money.

Any feedback is appreciated.


Hey Angus, we don’t allow people to customize the tiers.

This has just happened this week by the way. In some cases we may do a discount, but once a team gets into the larger tiers than we just need to do some math to justify our pricing plans.

Our current tiers:

  • 10 seats for $39/month
  • 50 seats for $99/month
  • 200 seats for $399/month
  • 500 seats for $999/month

It looks like $2/seat, but we’d price ourselves much higher if we were doing per user pricing. On average we’re closer to $4/user.

So, say that someone comes and says I have 60 people. Could we do $99 + 10 x $4/user? My answer in this case is to look at $399/60 = $6.65/user.

(1) That’s super competitive in our market
(2) That cost/user will go down as the company grows
(3) You get no surprises. Your invoice will remain the same every month.

The other issue if we do custom packages is that we’ll have to keep customizing it as they grow (oh we need an extra 10 people, etc…). The larger a team, the faster they grow. Which is why we have heaps of seat space between tiers.

Hope this helps!


Hey @iwpraveen! We also did unlimited users for a while, and I can say that customers love it, but your business might not.

It’s really important to think about whether or not your business can afford your pricing model. You’ll need some way to scale with the size of your customers in some way or another.

Re: your pricing plans :point_down:

It’s hard to give some feedback at this stage because I’m missing a few data points:

I’ve found this online
"It is difficult and expensive to build a full-featured, scalable application that can be deployed to the cloud?

It’s costly and time-consuming to find backend components and come up with a cloud architecture that is compatible with each other (especially if you have complex needs).

clAppIt provides all the backend components that are necessary for building an app in one place. Saving you time, energy, and money. Building your app has never been easier- develop it faster and more affordably!"

My first thoughts:

  • If you’re a PaaS you should do resource-based pricing (pay per app/hosting/cpu/etc)
  • If you’re a collaboration platform you should do per-user
  • You could do hybrid, and make some backend components more expensive (you could make people pay per component too)

In any case, the pricing needs to map to the valuable aspect of your platform, but in such a way that it still understandable by anyone (ex: when we priced per page, people had a hard time understanding what a page was).


Thanks Sten, interesting stuff.
We’ve tried this in the past, albeit at a higher price point, and I love the simplicity. But we often got kickback from the purchaser saying:
right, I’m paying you $99 for 50 users, we want to add 2 new users, and now my bill is going up to 4X to $400 - not fair.
I guess if they’re in super growth it works, but most teams don’t grow quick enough to make this fit - maybe thats just in our market.


But I like it so much I think we’ll test it again :slight_smile:


Thank you for the interesting perspective Sten.

→ The hybrid component seems like an option we can build onto our initial pricing
model and test it out.


we want to add 2 new users, and now my bill is going up to 4X to $400 - not fair.

Yes, that’s definitely the challenge of that approach :sweat_smile:

I guess that it’s all about providing the right framing during the discussion. It should be about “making room for the next 50 people” rather than “adding 2 extra users”.

Also I want to point out that this model works for us and might not be suitable for other tools.

There’s another approach where you do per user pricing, but then set the minimum transaction at a certain number. Ex:

  • $99 + $5/user month

where $99 gives you 20 users. Note that $99 wouldn’t give you 50 users in this scenario because the per-user cost should be higher in this case.


We are default Alive! Even after an Year of Battle Scars!

@Krish 's New Post on LinkedIn about pricing from the AWS Reinvent Talk rekindled the pricing discussions we had earlier.

We currently landed to a pricing model which has pivoted multiple times.

We understood the important advice of @spittet and moved into a resource based cost now.

Our current pricing model as configured on Chargebee looks like this: (still the website part is pending)

  1. Tier 1, Starter - $1000 Flat = For Customers whose cloud bill is below $10K
  2. Tier 2, Growth - 10% of Customer Cloud Bill = For Customer Cloud between $10K to $100K
  3. Tier 3, Scale - Custom

Pricing directly relates to the benefits we are giving.

Still has to go a long way as we are still in our foundational product of the platform (We broke down our platform into multiple micro products and offering them one by one)

Thanks for all the support this community has given we could land at some pricing but long way to go. :pray:t4:


Praveen, Thank you so much for the kind note and the acknowledgement here to the community. Really appreciate it. This pricing and packaging will continue to evolve with the customer base, new segments that your product will be ready for, competition and your value proposition. The experimental mindset towards pricing and packaging, and using it as a lever for growth is great to see.