Beeminder Forum

The case for making "Automatically trim safety buffer" a free feature

Bugabee
#1

Insufficient monetization is typically the reason why digital products die.

Since Beeminder can monetize in two forms (derailments and premium subscriptions) it needs to balance these two monetization levers taking into account its mission, ethics etc etc

But one thing is certain: if Beeminder can make more revenue by doing more social good, it should be a no-brainer kind of decision to make.
(more revenue = more devs = more cool features = more users = more productive world = cure for cancer)

By looking at the premium features I can clearly spot two features that, when adopted by users, directly increase derailment opportunities and thus monetization (without being evil!):
image

Unlimited goals: although it’s a premium feature, it can also be accessed by free users

Automatically trim safety buffer: The less buffer one has, the more prone to derailment this person is.

The case for NOT making “Automatically trim safety buffer” a free feature

The main reason for not making this feature free is if it’s the key feature that makes people upgrade from Infinibee to Bee Plus AND the number of people that take this path is too significant.

The other reason I can see is that this feature might generate a lot of support tickets from free users if it’s complex to set up.

Have you ever considered this from this angle?

p.s.: I’m dying to know the percentage of the company’s revenue that comes from derailments vs from premium subscriptions. And also the breakdown between the multiple premium plans.
p.p.s.: Sorry if I’m sticking my nose where it doesn’t belong. I love the product and have the best of the intentions.

7 Likes
Renaming "Retroratchet" to "Ratchet"
Renaming "Retroratchet" to "Ratchet"
#2

You’re in the absolute right place - you can be sure not only is your suggestion going to be appreciated but also at the very least taken into consideration :slight_smile:

5 Likes
#3

Yeah, this is quality business advice! Thank you! In some ways we’re way ahead of you and have been talking about The Great Auto-Ratchet Flippening for a while. We want to make it so that goals on the free plan can’t accumulate more than a week or a month of safety buffer. If you have huge amounts of safety buffer, that’s a bit like a pledgeless goal, is not beemindery, and should be in Beemium with the rest of the unbeemindery or revenue-eating features. The “I just want a nice graph without ever risking paying anything” use case should, philosophically, be the expensive premium thing. Not the “I want to edge-skate this puppy” use case, as you say!

We’ve been putting it off though, for a bunch of reasons, some of which you’ve anticipated. I think the biggest is that auto-ratchet kind of blows up the road matrix and we really want to implement it better before unleashing it on the majority of goals. Also we have to really nail the interface and the messaging to not seem like jerks, or surprising people by stealing away their hard-earned buffer. (This may also tie in with auto-dialing.) You may be right that we could just not worry about that half of it and at least make auto-ratchet opt-in for free for everyone.

:thinking:

PS: Revenue graphs for inquiring minds

image
image959Ă—576 86.7 KB

image
image975Ă—520 145 KB

3 Likes
#4

FWIW, autoratchet is definitely one of the major reasons (along with weekends off, although there are workarounds for that one with ifttt) I would never go non-premium.

3 Likes
#5

I agree with you about the feature, but the phrasing “is not beemindery” rubs me the wrong way. to me, beeminder is a tool to help me accomplish my goals. sometimes inputting the data alone is motivation, and sometimes I need the extra kick. but I don’t think pledgeless goals fall into the same un-beemindery camp as “it’s a game where I never pay any money.” its not a game, its a tool, and its great for me that i can use the tool in different ways depending on whay works for my different goals (both beeminder Goals and the underlying life goals they’re helping resolve). if many users have huge safety buffers on most/all of their goals, maybe im overgeneralizing my experience.

5 Likes
#6

The problem with having huge safety buffers is not only that users get comfy and derail less, IMO the biggest problem is that this allows them not to stick with a daily habit and thus give up on their goal and quit beeminder altogether a couple days/weeks later.

@dreev
Thx for the detailed answer!! I love your transparency and the “build in public” ethos

1 Like
#7

This is important feedback for us and we do love what a powerful and flexible tool Beeminder is. Also it’s pretty amazing and gratifying seeing all the ways people use it that we never imagined. Since this thread is from a Beeminder-as-a-business perspective, let me both acknowledge that and the general importance of not rubbing users the wrong way as well as say that we have to hold ourselves back a bit from our natural desire to be everything to everyone. I think Basecamp’s admonition to make Opinionated Software is important advice for us. We’re not going to start breaking people’s workflows willy-nilly but we need to … well, I guess I said this in our own blog post about the startup egg-basket principle (which, having just reread it, is making very much the point @gustavohsouza led with in this thread!).

Exactly. Well said. I also think – slightly at odds with what I just wrote above – that we can generally get the best of both worlds with the right design where newbees who don’t know what they’re doing never end up with stupid amounts of safety buffer but power users who know exactly what they’re doing can have exactly that when they’re sure that that’s what makes sense.

4 Likes
#8

Will you drop the “goal” element from the road matrix 3-tuple (leaving just time and rate)?

Definitely agree trimming safety buffer fits with “precommit to recommit” etc. Can’t think of a goal that I wouldn’t want this to be the default on.

2 Likes
#9

No, by blowing up the road matrix I mean proliferating the number of pieces in the piecewise-linear function that is the yellow brick road. How those pieces are defined isn’t the issue so much as how many of them there are.

I’m thinking that one solution could be retro-ratcheting – steepening the current segment of road, including in the past. I haven’t thought it through yet though!

2 Likes
#10

This sort of thing always seems very counterintuitive to me, but I may not be representative (and maybe more important I know next to nothing about your constraints, other than the ones intrinsic to the problem).

1 Like
#11

Yeah, I don’t like the idea of ratcheting modifying the road in the past. Feels super weird and dangerous. I want to be able to see where I was in relation to the road in the past. Allowing ratcheting to modify the road in the past kind of re-writes history in my mind.

Also, on buffer, I have some goals that are “do x every six months,” which can be super useful for following through on things that I need to do, but only very infrequently. I’m probably ok if that’s only a feature for paying users, but thought I’d mention it. Some of my goals would be unusable without the ability to have six months of buffer.

9 Likes