A product is meant to help someone solve a problem.
Understanding when your problem occurs lays the foundation for how often people are expected to use your product.
If people deal with your problem once a month, sending them emails every day is going to feel like spam. On the other hand, a monthly reminder is will probably be appreciated.
The natural frequency of the problem your product solves is the bar you use to gauge what’s too little and what’s too much.
Establishing this frequency isn’t an exact science, you’re going to have to ballpark it.
You could always look at how often people use your product and extrapolate from there. The problem with this approach is that people might be using it less than they should.
“Most of my users log in twice a month”. Twice a month, that’s the bar. If your product is designed for a problem people have two or three times a week then you’ve got loads of work to do.
It’s easier to benchmark usage with your best guess of how often your problem naturally occurs.
You can refine this measurement by thinking about other ways people solve the problem. How do people who don’t use your product solve the same problem? How often do they have to deal with the issue?
I’ll close this up by saying that you might have lots of different use cases. Some people use your product to set things up once a month, other people use it to sort stuff two or three times a week.
Pick your primary use case and focus on that for now. Then repeat the process for all your other use cases later.
More links on improving retention…
- Does your product make a clear promise?
- If you have questions or feedback please pop them on the LinkedIn post here and I’ll do my best to respond to comments as soon as I can.