[vasco]

> User courage was 0.95 initially and could be updated manually. We tried to regenerate it daily based on surveys, but without much success.

Based on this ending, the courage bit sounds clever but is misguided. It adds complexity in a whole other variable, yet you have no way of measuring it or even do a good assessment.

I thought you were going to describe how you calculated courage based on the statistical usage of new features vs old features when exposed to them to update courage, meaning people who still keep using the product when it changes have more courage so they see more changes more often. But surveying for courage (or how easy they deal with change) is probably the worse way to assess it.

But even that I don't know what purpose would have because now you destroyed your A/B test by selecting a very specific sub population, so your experiment / feature results won't be good. I'm assuming here a product experimentation approach being used, not just "does it work or not" flags.

[adontz]

Mostly functional changes. Like deploying a new parser, which may not support all the old files. There were users which will contact customer support in panic stating that their life is ruined by this change and there were users who's like that fixed by next quarter.

[j45]

What’s important is if it worked for you and your audience.

There’s no standard requiring something to work for everyone, and it being less value if it isn’t.