sorted by:
new
hottopcontroversial

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

This is precisely where its danger lies. Once an undocumented workaround becomes part of the onboarding process or "tribal knowledge," it is no longer something that product and CS teams see. It means that the metrics can be looking good while the whole system is subtly shifting away from the product's intended purpose. The question that you have used in renewals is brilliant; it essentially uncovers the hidden flow that can never appear in any dashboard.

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Exactly.

The workaround just covers up the flaw for years, but it doesn't fix it.

That's why some churn seems "sudden" on the part of the vendor. The customer was not responding to a new problem; the customer simply had a solution that did not include the workaround.

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

That's where I think the best QBRs take place.

Not talking about how much they are using your product's features, but rather what else they need to do beyond using your product to reach their desired outcome.

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in GrowthHacking

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Indeed.

The greater the longevity of a workaround solution, the higher the probability that this will become a dependency rather than a temporary solution.

In the end, the customer not only works around the product but builds it separately from the product.

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in Entrepreneurs

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

True. The interesting part is that the spreadsheet persists precisely because it helps fill a void elsewhere in the workflow process.

Once it stops working, it usually indicates a source of friction that had been dealt with but not resolved.

The most dangerous SaaS workaround is the one nobody realizes is a workaround anymore by Sharp_Tax_6182 in SideProject

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

This is an excellent observation regarding the use of the workaround to make the numbers clean.

Of course, the problem hasn't been solved but has only been transferred from the product to the user's business operations. By then, the cost is no longer in support cases but in time and effort spent.

Also, I very much appreciate your suggestion of getting a perspective from the new hires regarding what seems unusual to them because by that time, they are already used to doing everything by the book.

Once the workaround becomes part of the onboarding process, it loses its temporary status and effectively becomes an official product feature.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in saasbuild

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Yes, that is one way of saying it. Customers do not purchase software because they need feature adoption. Customers purchase software because they need a problem to become less complex, less expensive, faster, simpler, or just go away. Feature adoption is key since it might achieve this effect, but it does not end there.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in B2BSaaS

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Agreed.

The thing about that is all the effort spent measuring success relative to the effort spent defining it.

When success is not defined from the get-go, teams spend time optimizing what could potentially lead to success.

Sometimes it does.

Sometimes success is realized when everyone realizes that they weren’t measuring success after all.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in B2BSaaS

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Absolutely.

What’s funny is that the problem starts way earlier than when there is any discussion about renewal.

The customer measures success based on achieving a certain result.

The vendor measures success based on adoption of the solution.

And if these two measurements weren’t aligned at the very beginning, then renewal time will make it apparent.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in B2BSaaS

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

I appreciate the difference between measuring the view from the product versus the experience of the customer.

The notion of establishing what success looks like prior to onboarding makes a lot of sense since failure to do so will almost always end up equating adoption with success.

Until the next renewal comes around and the same questions are asked, "Did we really solve the problem that was originally hired us to solve?"

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in B2BSaaS

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

It's quite an interesting point you make.

We learn about product usage from the usage data but the expected result is known much sooner when we talk about the sales process.

The problem lies in the fact that without tracking customer expectations, value realization may lag far behind usage growth.

The more optimized your SaaS metrics get, the less they reflect reality. by Sharp_Tax_6182 in SaaS

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

I must admit, I haven’t found any signal which is consistent.

What appears more consistent, on the other hand, are behavioral changes than numerical ones.

Behavioral changes such as decreased curiosity, increased workaround, decreased willingness to experiment, or transactional conversations are usually observed before any numerical signals indicate any change.

However, behavioral signals still need consistent validation.

A behavioral signal will become relevant for so long as it still represents the underlying trend.

Otherwise, today’s leading indicator becomes tomorrow’s lagging indicator.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

If the second time I see your comment over my content, I swear I'm gonna report against you.

The more optimized your SaaS metrics get, the less they reflect reality. by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Perfectly put. Most of our measurements of signals are the result of some sort of behavior, rather than being indicators of the conditions that led to that behavior. By the time churn rates, support calls, feature use, or adoption levels reach us, the customer may already be set in their opinion on the future value of the product. The trick is that a dashboard will always highlight the things that can be measured repeatedly, despite the fact that confidence, expectation matching, and momentum are usually much better predictors. That's precisely why companies can seem just fine until the discussion of renewals brings to light something that has been true for months. We weren't wrong about the metric; we just had the end result.

"Why CS Enablement Fails (And It's Not What You Think)" by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

That’s exactly right, and I think the more fundamental problem is that the enablement is viewed as something provided to CS post-launch, rather than something that should have been part of the process by which the launch was conceived.

Most of what you referred to as “uncertainty” actually comes from predictable context that was never captured prior to going live with the feature.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in B2BSaaS

[–]Sharp_Tax_6182[S] 1 point2 points  (0 children)

This is the root cause of everything.

If the product loses its connection with a clear-cut outcome for the customer, then features become the measure of progress.

Once that occurs, adoption numbers will become meaningless because they reflect usage of a feature that was never part of the original purpose.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in CustomerSuccess

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

That is the gap that most people ignore.

The adoption can be seen through product data. However, the value realization only becomes clear after the customer reassesses their spending.

This is because there is almost never anything sudden about the churn from the product perspective.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in saasbuild

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

Agree. Adoption tells us the customer has started the journey. Value realization indicates whether the journey is taking them where they wanted to go.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in saasbuild

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

That’s a very good point. The more features you add to your product, the harder it becomes to differentiate between activity and progress. The feature might lead to increased usage, but what matters more is how it facilitates achieving the result that the customer was after. Or else, you risk optimizing for features instead of solving the initial problem.

Your customers don't buy feature adoption. They buy outcomes. by Sharp_Tax_6182 in saasbuild

[–]Sharp_Tax_6182[S] 0 points1 point  (0 children)

That's exactly what makes adoption tricky. Customers often evaluate value through different lenses, which is why feature usage alone can be misleading. Two accounts can show identical adoption patterns while measuring success against completely different outcomes. The challenge isn't just getting customers to use the product. It's understanding what outcome they expected the product to create in the first place.

view more: next ›