Build in Public
How to Learn Why SaaS Customers Churn by Building in Public
Use building in public to surface SaaS churn clues, verify them with customer behavior, ship focused fixes, and close the feedback loop without…
By Uriel Bitton · 4 min read
The short answer
Building in public can help SaaS founders understand churn when public reactions are treated as qualitative clues, not retention data. Ask about a specific point of friction, verify the pattern with customer conversations and product behavior, ship one focused change, and close the loop publicly and privately. Keep customer identities, tiny-cohort metrics, contracts, and sensitive commercial data out of the public update.
Building in public will not fix SaaS churn by itself, but it can make churn research more useful. Treat public replies as clues about where value breaks down, verify those clues with actual customer conversations and product behavior, ship one focused change, then close the feedback loop. The public layer helps you surface and explain the problem; private retention data should still decide whether the change worked.
Public feedback is a churn clue, not a churn metric
Stripe’s guide to reducing SaaS churn recommends improving onboarding, using customer feedback, providing regular product updates, and tracking churn-related behavior. Building in public can strengthen the qualitative side of that work because customer-safe product posts give people another place to point out confusion or missing context.
The boundary matters: a reply saying “I never understood this workflow” is a signal to investigate. It is not proof that the workflow caused churn across your customer base. Buildside’s B2B build-in-public guide makes the same audience distinction: feedback becomes more useful when it comes from people close to the buyer problem.
Use the Signal–Verify–Change–Close loop
1. Ask about the moment value breaks
Do not post “Why are customers churning?” Ask about one concrete moment. For example: “Teams import their data successfully, but some still do not create their first report. What usually stops you at that point?” A narrow question produces feedback you can compare with real customer behavior instead of inviting generic SaaS advice.
2. Verify the pattern privately
Intercom defines a customer feedback loop as receiving feedback, acting on it, and telling the customer what happened. Before acting, compare the public signal with cancellation reasons, support conversations, activation steps, usage drop-offs, or direct interviews. If only one unrelated follower mentions the issue, keep investigating. If paying customers describe the same friction and their behavior supports it, the hypothesis is stronger.
3. Ship one retention hypothesis
Turn the evidence into one change you can evaluate. If customers reach setup but never see the core result, the test might be a clearer first-run path, a better default, or a timely prompt. Publish the reasoning in customer-safe language: the friction you observed, what you changed, and which behavior you expect to improve. Avoid presenting the fix as proven before the retention data arrives.
4. Close the loop publicly and privately
Productboard’s continuous feedback-loop example describes notifying customers when requested improvements ship and inviting them to keep contributing feedback. For a founder building in public, use both layers: publish the customer-safe lesson for the wider audience, then follow up directly with the customers who raised the issue when appropriate.
Separate public proof from retention proof
Public proof can show that the problem is recognizable: repeated replies, clearer customer language, or people asking for the same workflow. Retention proof is different. Track the metric tied to the hypothesis, such as activation, continued feature use, logo retention, revenue retention, or cancellation reasons.
Buildside’s measurement framework for building in public separates public engagement from decisions and business outcomes. Apply the same rule here: a churn-related post is useful when it improves the diagnosis or customer conversation, not because it receives a large number of likes.
Keep customer-level churn evidence private
Do not publish identifiable cancellation stories, private support messages, contract details, or tiny-cohort metrics just to make the update feel transparent. Buildside’s SAFE test for public SaaS metrics is a useful filter when retention data could expose a customer or sensitive commercial information. Share the lesson at the lowest level of precision needed to make it useful.
Run a 14-day churn-learning cycle
Choose one point where customers appear to lose value. Publish one bounded question about that moment. Compare the replies with private customer evidence, select one change, ship it, and publish what changed. Then watch the relevant behavior for two weeks rather than judging the experiment by the response to the post.
Building in public is most useful for retention when it shortens the distance between a weak signal and a better question. Let public conversation help you find the friction. Let customer behavior tell you whether you fixed it.
Sources
Frequently asked questions
Can building in public actually reduce SaaS churn?
It can support retention work by surfacing customer confusion, repeated objections, and product friction, but public posting does not reduce churn by itself. Verify public signals with customer conversations, product usage, cancellation reasons, and retention metrics before changing the product.
What should I ask publicly when investigating customer churn?
Ask about one concrete moment in the customer journey, such as onboarding, setup, a missing workflow, or a confusing feature. Avoid broad questions like 'Why are users leaving?' because they attract speculation from people who may never have used or bought the product.
Should I publish my SaaS churn rate while building in public?
Only when the number is safe and useful to disclose. Small cohorts can reveal customer information, and exact churn can create commercial or contractual risk. You can often share the pattern, experiment, or percentage change without publishing sensitive underlying numbers.
How do I close the feedback loop after fixing a churn problem?
Publish a customer-safe update explaining the problem, what changed, and what you are watching next. Then contact the customers who raised the issue directly when appropriate. The public post documents the lesson; the private follow-up gives affected customers the context they actually need.
A note from Uriel Bitton
Churn is one of the areas where building in public should create better questions, not louder conclusions. I would use public conversations to surface repeated friction, verify it against real customer behavior, and then share the fix and lesson without exposing who churned or why a specific customer left.
Keep building with us
Get practical founder lessons and product updates in your inbox.