Product Activity Coefficient: A single metric to drive customer success teams | Hacker News Reader

Product Activity Coefficient: A single metric to drive customer success teams

blog.getcensus.com

49 pointsborisjabes11 comments

Arguably, the activity does not always correlate with user happiness.

I don't want to be because of actively using the software. I want to be happy because the software solves some kind of problem, efficiently. There is fine difference.

Games: make me happy through the act of using them.

Accounting software: I don't want to be forced to use it constantly. My idea of happiness would be to get it done with as little effort on my part, as infrequently as possible.

Extreme example: LinkedIn requiring users to log in every month or be prioritized down in searches. That would increase how frequently users log in but I doubt anybody would agree that this would improve user happiness.

Per the article, the team would define activity, so presumably it should include some core functions and not just clicking in frustration. Second, low scores in this metric is designed to predict churn, which is a strong indicator of value to that customer. The article doesn’t spell this out, but if the activity is not predicting cancellations then it should be adjusted.

Happiness isn’t the cornerstone of customer success. A customer can feel unhappy with a product due to many factors but can still use the product to meet and achieve goals. Thus becoming successful. Unhappiness does not necessarily effect churn rates. A customer can be unhappy with their usage but still see value in the product and not churn.

Usage is a hard metric to measure because it can be very subjective. Some users subscribe to a product for a once a year event while others can be hyper users with thousands of sessions. Both can feel the same level of success. The cornerstone of Customer Success is the manager, they are there to help the product meet the goals of the subscriber. The true metric should be: did the manager assess the customers needs, and meet their objectives while achieving a short time to value? That would be a better metric...though hard to measure.

What are Customer Success teams? Phone support? Cold sales?

That’s a great question. I think of them as teams that a) help proactively onboard customers (ie ensure they get what they paid for) and b) monitor accounts to determine how to help them get the most from your product + upsell new features.

So it’s not quite customer support and it’s not quite cold sales. There’s healthy debate about the scope of the team though!

The team that aims to make sure that people who are currently giving you money, keep giving you money.

Depending on the company you'll see it defined a few ways. These may include activities like user training, a level 2ish enterprise support where they'll do some investigation/triage of bugs and can enable some feature flags for you or escalate to an engineer. Sometimes you will see phone support or account manager called customer success

The other responses are also good but it can also take the form of a client advocate: taking the client's needs and making sure they get visibility to the developers and product teams.

You have software. You sell it to HyperGloboMegaCo.

Someone at HGMC needs to install it. Someone needs to connect it to the fascinating LDAP proxy that a previous Enterprise Architect banged out one Sunday evening. Someone needs to add it to the SSO. Someone needs to get to the point where a first user does a first thing.

Now you have a user. Often they struggle too. Now you need someone to show the user how to get best value from your tool. Not unreasonable for complex tools which are, after all, complex.

I have mixed feelings about it as a practice. To me it seems like an organisational smell, a trailing indicator of product flaws.

Compare old cars with newer cars. You used to need a lot of car servicing and that was seen as normal and acceptable. Then one day Toyota showed up and made it obvious that it needn't be normal and it wasn't acceptable at all.

Maximizing time the users spent in your software must not trump general design sense—just remember the (sometimes devastating) effects of YouTube’s switch to maximizing the time users spend watching videos.

While for an ad-supported product like Google’s video sharing platform it might be an unavoidable tough trade-off in order to not be a loss leader, but a paid product should aim to solve user’s problem most efficiently and give them time, not take away from it.

Obligatory HN-level nitpick: "coefficient" seems misplaced. It usually means "some number that gets multiplied with a named variable".

So I'd expect something like "synergy * hypergrowth * mrr_arr_all_the_rrs_me_hearties * activity * activity_coefficient".

Reply on news.ycombinator.com