Ancient thread on premium features and inbox-minding (2012-2014)

1

Hi everybody,

I’m going to answer the questions to the best of my ability! Beware,
there is some brainstorming ahead.

Hi Akratics,
We’re hoping to get your feedback on how many of the following
premium features it would take for you to feel like it was worth
paying $12/month for Beeminder:

For the record, the only thing I pay for that has any set monthly fee
is my apartment. I’m a total cheapskate. $12 seems like an awful lot
to pay to risk having to pay more.

  1. No need to remember to cancel your subscription – if you don’t use
    Beeminder all month, you’re not charged for that month. [1]

Maybe this would help. Not sure if it would motivate me to sign up,
but it seems kind and would gain trust.

  1. You get god-like powers over your yellow brick road: you can add
    arbitrary flat spots, change the steepness retroactively, etc. Soon
    we’ll add the ability to relinquish that control selectively, if that
    tempts you to cheat on your contracts.

God powers would just make akrasia easier, no? Maybe I misunderstand,
and maybe one of the god powers is to make it impossible to change!

  1. You can jump the pledge schedule – go straight to an amount that
    motivates you to stay on track instead of suffering through a few
    initial derailments (which always entails the risk of getting
    demoralized and not resetting at all!).

I don’t think I’d pay to reduce the risk of not resetting. But, if I
were paying, I’d probably reset more quickly, knowing that I’d get
more for my money.

  1. Serious VIP treatment for the brave souls who first guinea pig this
    stuff for us!

Hmmmmmmm. What kind of VIP treatment are you talking about? Like
getting to be on the mailing list? Or emailing the developers
directly?

  1. Specify who your forfeited pledges go to. (This one isn’t
    implemented yet, just seeing what people think.)

I wouldn’t pay for that.

[1] It infuriates me when companies profit off my akrasia. I want
Beeminder to only profit off of fixing akrasia! [2]

That would be great. I’d pay for a system where if I were paying, it
would keep me on my goals. And I’d probably pay more if it helped me
set better goals. For instance, if I could stay under a certain weight
by paying $20/month, I’d pay.

What I don’t want to pay for is the option of tracking how
(in)effective my weight loss program is. Notice that there are two
uncertainties already: it’s just an option to track (I could stop
using BeeMinder) and what I’m doing might not work.

So I’m thinking of something like a positive health plan where you pay
as long as you’re healthy, and when you get sick, your doctors pick up
the bill because they’re not doing their job. To go back to the weight
loss example: if I start to gain weight, my $12 might pay for someone
to pound on my door and get me to work out a little. Of course, while
I’m above the weight goal, I don’t pay . . .

Because, ultimately, I want to pay for results. To translate the
“pound on my door” example, maybe if I slip and fall off the road, I
get lots of help and encouragement to reset and get going again. Like
a phone call. I might pay for that, if it worked!

On the other hand (and I’m not suggesting this at all, just thinking
out loud) it would be interesting to set up an antagonistic dynamic
between me and bee minder. That is, we both have something at stake.
You lose as long as I stay above the road–or at least I gain
something from you.

[2] A funny thing to say, given our business model so far (collecting
pledges on failed goals), but I’m serious: paying those pledges is
just part of climbing the fee schedule till you hit your Motivation
Point. Beeminder injects massive motivation along the way and you’re
paying in proportion to the motivation Beeminder provides and in
proportion to how badly you need Beeminder!

The current business model is slightly flawed in that way. If you move
people quickly to their “sweet spot”, they cease paying, no? You have
unlimited downside (hosting/support costs potentially forever) for
each of the non-paying users. I can see why you want to get paid for
the successful users.

Anyway, I’m a cheapskate and these things might not work for me. The
biggest motivator that kept me on one of the roads for several months
was that I was keeping that goal free. Now that I have to pledge
money, I don’t want to reset! I suppose I’ll try it though,
eventually.

Eric

2

I side with Beeminder too. This should not be considered a default.

3

Interesting thoughts about not mixing backlog processing with inbox
processing

As regards hitting zero in box every day. I find that hard. My current
system is to have 2 flags, one todo\important and one waiting. The todo
flags do build up and I go through them once a week to cut them down. Maybe
the solution here to keep the todo\important tags to zero every day is to
move anything not done to the backlog list (For work I use
http://tomorrow.do, for me personal list I use http://any.do) at the end of
the day? But what if you need to reference stuff in the email?

The wait tags I am unsure about. Would this tag list count for email zero?
I’m sure this is a common use case. It’s stuff you are waiting on from
others that sometimes might take weeks and you need a reminder to follow up
on in case they forget.

Cheers,

Tom.

Daniel Reeves dreeves@beeminder.com Nov 15 11:15AM -0800

Here’s the super short version of Mark Forster’s advice on backlogs:
Isolate the backlog and [bee]mind it separately.

Rationale: If you mix backlog processing with inbox processing then
(1) it’s just kinda demoralizing to feel like the red queen –
Red Queen's race - Wikipedia – and (2) you’re
driving blind, with no feedback loop on whether your inbox processing
is sustainable. You need to hit inbox zero every day, even if you do
it by letting things fall on the floor, because you need to be in
control of what falls on the floor.

The Inbox River Method

Some people can get away with the river approach (thanks to John
Langford for the metaphor), where they can trust themselves to pull
out anything sufficiently important as the emails flow past. I cannot
be trusted with that approach, since I persist in watching important
emails flow past into the vast sea that is my inbox and delusionally
insisting that I’ll totally get to that later.

Conclusion

If you’re like me – super akratic about your inbox – then you have
to somehow be an inbox zeroer. If you’ve slipped and have a backlog
then you’re suddenly the red queen on a slippery slope. Hence: isolate
the backlog, keep inbox zeroing, beemind the backlog separately.

PS: As Mark sagely points out, this applies to any kind of backlog
(personal debt, for example):
Backlog Method - Blog - Get Everything Done

4

Essentiae’s mail reminded me: There’s a small period when we haven’t officially derailed but new data points are considered to go to the new day.

  • If I enter data at 2:30am on Jan 2nd, the app assumes I intend to enter it for Jan 1st, and I don’t derail. Cool.
  • If I enter the data at 3:30am on Jan 2nd, I still have the option to tick the date back to Jan 1st and stop myself from derailing, but entering the point without thinking would add it for Jan 2nd and cause me to derail. Not so cool!

It ought to be: either you’ve derailed, or entering data will add it to the previous day (for after-midnight derailments). I know we have an option to set what time we derail, but there’s still another variable that’s hidden (what time it’s too late to enter points for the previous day).

(You might have fixed this, the last time I derailed like this was a while ago. I just remembered from having to catch myself after entering data really late on NY).

Please, please, pretty please fix it so that the graphs update before they reset.

Having them derail when we update data while we’re frozen can be frustrating and it happens to me a lot. I’m not sure why reseting the grap doesn’t force an automatic refresh before redrawing the new graph and reseting the goals, but please consider changing that if you have a chance.

Today’s example is that over the holiday party period I have derailed a specific graph a few times and decided to leave it derailed and pick it up again after the holidays. (And there was no point in creating one with a huge slope when the holidays were just about over and then I’d be stuck with a steep seven-day slope.) So I just left it derailed until NYE would be over. But, I still kept track and texted in data for QS purposes and out of habit. Unfreezing the graph today then derailed it right away.

And maybe you’d prefer we not track or change data if we’re frozen, but what about situations where we do enough on one day to push a “do less” goal into the red, enough that we have a max of, say, 3 for the next day or we will derail for sure. Then, the next day comes and we hit that 3 and the graph derails but we keep texting in more because the day doesn’t end when we derail (say 10 more units). Now the graph is fully frozen but new data is being entered on the same day as it was derailed, but after it derailed (so it’s not the same as tracking data on days you might not want us tracking if we’re not on a paying slope). Then, when we reset when we get home or on the next day, we have less right off the bat (or might even be derailed again). It would be so much more convenient if the graph reflected the data when unfreezing, not when derailed, before it resets, I think. (Though, there may be abuse cases I’m not thinking of, so this is just my opinion, as always.)