🔥 May 30, 2024 / Fibery 2.0 with Highlights and Fibery AI

[Chr1sG]

@Oshyan

I will say that some of the newer Fibery pricing - and the overall industry trend - seems to be partly oriented around simplicity and upselling for the SaaS company

To be fair, I think developing a pricing model whereby features are charged according to the number of users who actually utilise them is actually incredibly difficult to implement, and explain in a coherent manner.

@Oshyan

The wins may be worth the losses for Fibery and other Saas Proivders though, e.g. a company with 25 people paying for 25 AI subs when only 10 people need it, but also a company with 5 people not paying for AI at all because only 2 need it, vs. the gains they might make if they had more bespoke/per-user pricing, e.g. same 25 person company only paying for 10 AI licenses but 5 person company also paying for 2 licenses because they can now justify it. Hopefully those examples make sense.

It’s not so much that the SaaS provider (Fibery) has decided that getting 25/25 + 0/5 users to pay for AI is a better result than getting 10/25 + 2/5 users to pay, but rather that gating feature usage per person makes for a really crappy UX.

For example, if the 5 person company only has 2 people who ‘use AI’, what does that mean in practice?
If one of the 2 ‘AI users’ designs a button automation that generates a summary using AI, who is allowed to press that button?
Designing and implementing per-user limits actually requires some serious developer effort, and as mentioned elsewhere, we’d rather put developer effort into value-adding features, than into feature restrictions.
And given how complex the Fibery permissions model already is, limiting capabilities based on which licence tier a specific user is on, would make it even worse.
How can one user explain to another user why he/she is not seeing/able to do the same things?

Also, these kind of limits stifle exploration/innovation. As a workspace owner, I might think I know which of my colleagues need which features. But what should I do when one of them asks to do something with AI? Different licences per user adds work for the admin and adds friction to experimentation/discovery.

Overall, if it costs the 5 person company $50 to add AI (by paying for all users) but only 2 of them ‘use’ AI, then it’s up to them to decide if the 2 users get $50 worth of value.
Personally, I like to compare the overall per-person cost of a tool with the salary that a worker is getting paid. How many more minutes of productive work do you need from your employees before the tool has paid for itself?

And for every other feature in the product, there will always be some workspace owners who can say “Well, only 1 of our users actually uses this feature X, so we want a cheaper licence tier that does not include this feature, to be applied to all the other workspace users.”
There would need to be a multi-dimensional pricing policy to accommodate every possible combination

I don’t know any company that has managed to get this strategy to work, and just like pay-as-you-go mobile phone plans have largely been usurped by pay-monthly fixed plans, I think consumers have come to realise that they can’t expect SaaS pricing to be hypersegmented so that they only pay exactly for what they ‘use’ and no more.

[Oshyan]

@Chr1sG

Do you mean converting Link-to-Entitys to Mentions?

Sorry, yes, that’s what I meant.

@Chr1sG

If you start using Highlights, any existing Link-to-Entities can be left as is

Great, that’s the reassurance I needed! Thanks.

@Chr1sG

To be fair, I think developing a pricing model whereby features are charged according to the number of users who actually utilise them is actually incredibly difficult to implement, and explain in a coherent manner.

It is! But so is implementing super sophisticated permissions, and you guys tackled that.

@Chr1sG

gating feature usage per person makes for a really crappy UX.

The naive implementation surely does. But I am pretty confident it does not have to be so, any more so than some Fibery UI/UX of the past was unintuitive and has improved greatly over time. What you’re saying is the same thing as above: it’s harder to design good UX for more granular per-user feature subscription, but certainly not impossible or fundamentally intractable.

@Chr1sG

If one of the 2 ‘AI users’ designs a button automation that generates a summary using AI, who is allowed to press that button?

I don’t think you’re actually asking me to answer this, but I have answers for this and your other example questions that feel quite satisfying, intuitive, and easy to explain to my mind. If it was valuable to you/Fibery to provide this, as it was for deep permissions, then you would figure out how to do it. As you say, it is understandably not worth the time/effort for you vs. “just do what everyone else is doing” (don’t get me wrong, there are differences, but really your pricing is not much of a difference at this point vs. most others, as far as how it works and is structured). That’s a fine choice to make, but it’s certainly a trade-off.

@Chr1sG

And for every other feature in the product, there will always be some workspace owners who can say “Well, only 1 of our users actually uses this feature X, so we want a cheaper licence tier that does not include this feature, to be applied to all the other workspace users.”
There would need to be a multi-dimensional pricing policy to accommodate every possible combination

This seems like a bit of a strawman to me. I can’t speak for anyone else, but I certainly wasn’t implying this nor do I think this is necessary. You’re right that there is some subset of users that might want any given feature to be on or off per-user. The same is true for any subset of features being implemented or not (i.e. everyone has different priorities). But that doesn’t mean that there isn’t some subset of features - hmm, maybe AI for example? - that a large number of people might want, but yet also not want (or be able to pay for) everyone on their entire team to use. In other words: you absolutely could determine some subset of features for which it could be worthwhile to allow per-user subscription, without having to provide every feature on a per-user subscription basis. This could be based both on total need in the userbase, as well as ease of implementation, for example.

@Chr1sG

I don’t know any company that has managed to get this strategy to work, and just like pay-as-you-go mobile phone plans have largely been usurped by pay-monthly fixed plans, I think consumers have come to realise that they can’t expect SaaS pricing to be hypersegmented so that they only pay exactly for what they ‘use’ and no more.

Fixed pricing in mobile plans emerged because the true cost of data came down so far that competitors were able to offer fixed data as an incentive and forced everyone to do so. It was ultimately a consumer-friendly thing due to competition, which is exactly how the market is supposed to work. And data is the almost singular feature, aside from the network reach and quality itself, that is being sold. With the cell phone data options we have now, everyone basically pays less for more data than they used to, and it’s all fine for the most part. There are plans that cost $5/mo for those that need little, there are plans that cost $75/mo for those that need a lot. So it is not IMO analogous to the customizable pricing we’re talking about here. But that doesn’t take away from your point.

It’s about incentives in the market. SaaS companies don’t gain enough from granular pricing to offset the downsides and complexity of implementation, and the market doesn’t demand it strongly enough that it would allow any competitor to thrive largely on the basis of granular subscription model, so the incentive is not there to provide it. Which is more or less what I was getting at. I think we’re more or less on the same page at this point.

[B_Sp]

@Oshyan

While I understand you having stuff that takes years to complete… why do you actively need the history of that to reference? Are you perhaps using History as a sort of easy, ad-hoc stand-in for more formal documentation of changes or something? Obviously it’s a feature of some value to some customers since it is now in a higher pricing tier, but I figured it was for compliance or some other enterprise-level features. Just curious why and how you use it, specifically.

It’s always great to hear from you and I have to say I was eager to see if I might get even a smidgen of support from you on this @Oshyan!

We use this for multiple needs around just seeing what’s going on in an entity. Some users forget to document why they changes a state - so using the activity log I can see who did it and when. We represent a ton of non work stuff in Fibery, like equipment, company themes, historical events (I have a way to do that), etc. and a huge benefit of Fibery is having the ability to design that stuff so they have their own attributes. I don’t really understand why comments and references all show back through an entity’s entire history, but this activity log is now limited. So I can see an entity was referenced 6 months ago, but I can’t see any detail around that that the Activity Log would show me.

The fact is I did find it galling to suddenly click the “clock” on something that was from earlier this year, and try to figure out how it came into existence and what was done with it, only to see “sorry you have to pay more to go past 90 days.” Like I say this is almost a deal-breaker for us because we use Fibery to document the entire enterprise, it’s like a record book of our operation. I can’t afford however to pay all that extra to keep this functionality. Since the Fibery team decided that this is a pro feature and I need to pay $20/user/month to have it, Fibery isn’t really competitive anymore with other options I could use in the no-code realm to meet my needs. This is tarnishing the degree of my advocacy of Fibery as well. Again being unfiltered here, I feel like the official responses to me so far are more like “sorry deal with it” and not “we sympathize, how could we help you long-time user?” - a sentiment I am only really getting from you. Disappointing.