Question on Lumpy Goal Achievement Metrics

I have a personal goal that involves increasing my real estate cashflow monthly income. It is a goal that is achieved by acquiring property, so each new property adds a lump sum of, for example, $200 per month cashflow. It is not a goal that grows gradually; the goal line will not slope up, it will step up.

I want to use Beeminder to drive the acquisition of N properties to achieve the ultimate goal of $X per month total cashflow, but the lumpiness is causing conceptual problems. If for example it takes 2 months to do all the tasks it takes to find and close on a house, only at the end of that 2 months would I see the $200 cashflow. So the goal would derail in the mean-time because there is no partial growth of the $200.

I already have a Beeminder goal set up to ensure I am spending the daily time doing real estate work, but I’d like one that is also focused on the ultimate goal of N properties owned or $X total cashflow.

Any ideas?

1 Like

One idea I have that I’m not sure I like yet, is to beemind each acquisition with it’s own beeminder goal ( 0 to 100%), and then the datapoints in between start and goal would be based off the percentage complete on the action plan.

My first idea is to think in terms of having plenty of safety buffer to absorb the lumpiness (or chunkiness, as we call it). See our Chunky Time blog post.

And then there’s our general warning to be really careful about beeminding things you don’t have direct control over. I know it may be worth it because the graph of that metric is what’s most valuable, so maybe just beemind it super conservatively. More on this in our What To Mind post.

1 Like

Thanks, Daniel. I like the Chunky Time concept. I’ll play around with time buffers on this goal and see what I come up with. I may turn on reminders just for this goal to keep up the heat.

I also hear you on beeminding outcomes vs. actions, and I think for now I’ll stick with this goal, even though it is an outcome that may be out of direct control.

1 Like

Ok, I set this goal up per the above discussion:

Tried to retroratchet to 60 days before derailing, but the retroratchet failed. What am I missing?

1 Like

Your idea about beeminding each acquisition from 0% to 100% reminds me of this idea, which I think you can do without beeminding each acquisition separately:

(that would be nice to turn that into a blog post, come to think of it. #blogideas)

And as for your question about retroratchet: that’s what you use to get rid of extra safety buffer. To add more safety buffer you can use the “take a break” feature to add an additional 50some days of safety buffer. (Sorry that’s confusing – we’re working on that. And thanks for asking about it. That helps us!)

Thanks for the correction on retroratchet vs. taking a break. I’ve now got the goal looking like I think it should, giving me 60 days to make the next acquisition happen. As long as the goal works on this outcome path, I’ll cancel any attempts at Fractional Beeminding, but what you are saying there definitely also makes sense.


I probably should update that post with my updated thinking.

Preview: I really like fractional goals, and they are good for things that you don’t know how long they will take. The fraction you enter for any particular day isn’t important, but it’s good to have some kind of estimate listed in the fine print. eg: 5min = 1% you can update this estimate as you go. (which is probably the same as beeminding time and changing the road slope, but it feels different to me.)