search

beeminder / blog

3 stars 2 forks source link

Parceling Out Goals Stingily #226

Open dreeves opened 1 year ago

dreeves commented 1 year ago 
### Desiderata
- [x] Preview link
- [x] Keywords/tags
- [x] Image
- [x] Published at https://blog.beeminder.com/stingily on 2023-04-13
- [x] Blog blurbs
- [x] Tweet at https://twitter.com/bmndr/status/1845934619386171540 on 2024-10-14 (and probably also earlier)
- [ ] Tip of the day
debate with clive I conjecture that we're shooting ourselves in the foot by paywalling goals. Goals are lucrative for us and throttling goal creation costs us more than premium pays us (so I predict; it's possible to bucket-test this). [Pledge focus](http://blog.bmndr.co/focus "Beeminder Strategy Memo") is very correct and we want to keep moving in that direction. I like Philip's perspective in the public [parceling out goals sting-ily](https://forum.beeminder.com/t/proposal-to-parcel-out-goals-stingily/10545/13?u=dreev ) post. I.e., non-monetary sting dilution is fine, that's the point of derailing-is-not-failing. We want to (gently) encourage derailing and it's possible for that to come off in a gross way but let's not user-squeam about it, let's take the risk and just do our best to be non-gross. Adam's correct about drip campaigns aka lifecycle emails, just that that's a thing to do in addition, not instead. Basically I'm kinda :-1: on all the clever ideas for parceling out goals based on tenure and engagement and stuff and still pretty :+1: on the original idea of bribing people to derail, to put crassly. See also Nicky's new blog post draft, [Derailing It Is Nailing It](https://github.com/beeminder/blog/issues/216 "Gissue in the blog repo"). CLIVE: In general I agree that more goals = better revenue, that goes without saying, so paywalling extra goals is a bit counterproductive. 1. Point: In practice, we're pretty generous about giving out more goals, and anyone who actually even half wants them can have them just at the cost of typing a few words. 2. Counterpoint: I think there's definitely a risk of new users getting in over their heads if you let them have unlimited goals day 1, so some kind of earning-by-doing doesn't seem counterproductive. I agree that non-monetary sting dilution is to be avoided, though, so I would stick with just tenure-based or (better) data-entry-based free goals, at least to start with. 3. Point: derailing isn't failing, for you and at least some decent fraction of others, so (gently) rewarding derails seems ok. 4. Counterpoint: For me (and I suspect a bunch of others) the ick-factor of directly rewarding derailing is too large to get over. I hear your views about how of course in practice you get revenue from encouraging derailing it, but directly rewarding it by giving more free goals looks dangerously close to a dentist handing out sugar sweeties when they give you a filling. Think of the worst possible headline about Beeminder doing this on some widely-subscribed site -- that's what you're risking getting, regardless of how clever our economic theory motivations are. 5. Data might help here: how many users never get past their first 1 or 2 goals, versus how many bump into the initial limit and stick there? That might give you an indication of the impact of raising the limit to (say) 5 goals straight off the bat, or raising it to that after a month, or something. DREEV: to pick on point 4, that's the user-squeaming i want to fight against. i do see the risk, but it's so reminiscent of how, for example, commitwall felt. "so shady to expect a credit card before you've even seen what a freaking graph will look like" etc. (similar for thinking we needed an option to not automatically rerail.) this could be different and it could be bad and one can vividly imagine the badness, but we should be ok with risks like this. and we really believe in [blog.bmndr.co/defail](http://blog.bmndr.co/defail) and should double down on it. i think we can frame it in a non-icky way! because it fundamentally is non-icky. the truth will prevail! i think the way to test this is [blog.bmndr.co/docdriven](http://blog.bmndr.co/docdriven) -- ie, write the whole blog post announcing this and see how it sounds and feels. (also looking at more data, good point) more pitching: the potential upside is that it works to convince people that derailing is not in fact failing. they don't currently see that argument (unless they scour the blog or hang out in the forum or discord long enough) but if it's in the UI that that's how you get your next goal, then everyone sees it. there are too many people who view derailing as anathema and i think some of them can be convinced not to think of it that way. if we pitch it right. or maybe the black box idea can work? "you get more goals when our algorithm says you're ready". then we have free rein to try anything and everything. and explaining that that's why it's a black box might be pretty reasonable. throttling goal creation is pretty clearly user-beneficent -- opposite of user-hostile. we're saying "wait, don't risk paying us more money yet, make sure this is working for you." we can emphasize that and counteract a lot of ick. CLIVE: OK, a couple of things: first, I agree you need to be brave! You also need to be able to define success very clearly, and have the tools in place in advance to measure it. Of course it should show up in revenue, but that's too crude a measure, and it'll trail by some months. What are the leading indicators of success here? What will you see first, and do you have tools in place to show you that -- and, just as important, to show if you were wrong and it is backfiring? Second, you need to be able to back it out if it doesn't quite do what you think it would do. So maybe a black box approach is the way to go -- "we award additional free goals based on a number of criteria, such as how often you have successfully challenged yourself by getting to a derail, how many datapoints you have created, and how long you've been using the system"? That also takes away Philip's sting dilution thing (which personally I thought was too much of an intellectual argument to in practice be an influence on many users). Just thought of another advantage of the black box: makes A/B testing a lot easier -- usernames A-M get bb1, N-Z get bb2, or whatever. DREEV: You're convincing me!

Cognata

Verbata: sting-ily, blog-post-driven development,

dreeves commented 1 year ago

NUMBER OF FREE GOALS ON NON-PREMIUM

You may recall we had a little January promotion: 4 free goals instead of 3. I added a note on the changelog entry for that -- http://beeminder.com/changelog#4351 (see the hovertext) -- saying that we're not going to actually drop the limit back down to 3 until we've made some other related improvement. Probably one of the ideas in this thread:

https://forum.beeminder.com/t/proposal-to-parcel-out-goals-stingily/10545

To review, here are the current candidates for a new way to get more free goals (besides the existing ones of getting a premium plan or in exchange for feedback sent to support):

  1. Each time you derail, to promote the derailing-is-not-failing philosophy
  2. After you've been beeminding long enough or have added enough datapoints
  3. Based on a black-box algorithm that gives us the freedom to experiment to our heart's delight on what seems to work best

I'm still leaning towards the first one. I think with an "achievement unlocked" framing and otherwise careful articulation of the "derailing is not failing" mindset (we even have a new blog post draft -- thanks to shanaqui and Clive -- to take it to the next level: "derailing it is nailing it") that we can avoid any feelings of ickiness some users may have, and that by always having an option to jump to unlimited goals that we can avoid the sting dilution concern.