Imagine Sofia runs marketing at a 120-person software company. On Monday, a rep needs a customer the prospect can call. Meanwhile, CS keeps hearing that new users get stuck importing their data.
A case study might help the prospect. It won't fix the import step.
Customer-led growth means using those customer experiences to decide what your team changes. Sometimes the answer is a better onboarding flow. Sometimes it's clearer pricing, a product fix or an approved customer story.
Start with the customer problem and the decision it should inform. Then give someone responsibility for acting and reporting back.
What is customer-led growth?
Customer-led growth uses customer insight to guide how you attract, onboard, retain and grow accounts. You learn what customers need, change the relevant experience and check whether it helped. Product, marketing, sales and customer success all have work to do.
Forget the Funnel's Customer-Led Growth framework starts with understanding customer value across the full relationship. Collecting endorsements covers only part of that work.
Customer advocacy helps customers share their experience with other buyers. Broader customer-led work also includes the customer who cannot finish setup, the account considering cancellation and the person whose request you decide against building.
Customer-led growth vs. PLG vs. sales-led growth
| Approach | What guides the work | A practical decision | Who acts |
|---|---|---|---|
| Customer-led growth | Customer needs and evidence of value | Customers struggle with imports; investigate and change onboarding | The team responsible for that experience, with CS bringing context |
| Product-led growth (PLG) | Product use drives acquisition and expansion | Help a trial user reach a useful result | Product and growth |
| Sales-led growth | Reps guide evaluation and purchase | Address a buyer's implementation concern | Sales, with product and CS |
You can use customer insight in either growth motion. A trial may reveal an onboarding problem; a sales call may reveal unclear positioning. Our product-led marketing guide covers the self-serve path. Neither a trial nor a demo removes the need to learn from customers after purchase.
Buyers often see what customers say before they talk to a rep. G2's 14 May 2025 research release covers a survey of 1,169 B2B decision-makers run in April 2025. Its buyer behavior summary ranks software review sites second among the things that shape vendor shortlists, at 15.1%. It says 38% of SMB buyers used review sites for research.
TrustRadius's 16 July 2025 buyer research release found buyers shortlist 2.6 products on average. Confidence from customer reviews came up in 24% of purchases in its research. These surveys show why reviews belong early in the buying path. They don't promise that any one review campaign will lift sales.
What we found in three customer-feedback paths
Before building a bigger review program, check how an unresolved customer concern reaches the person who can act on it.
On 4 November 2026, we inspected three selected public sources: Linear's Customer Requests documentation, Buffer Suggestions and its published setup explanation, and PostHog's roadmap. We followed four fields: where input enters, what context stays attached, who owns or shows progress, and how someone can hear back. We read public pages only, without creating requests or testing notification delivery.
These are different surfaces: documentation for an internal workflow, a public suggestions board and a roadmap. We chose them to inspect those differences, not to rank the products or estimate how SaaS companies work overall.
| Surface inspected | Input and context | Owner or progress | Return path we could establish |
|---|---|---|---|
| Linear Customer Requests | Linked customer message, source URL, requester and timestamp; request attached to an issue or project | Account fields and an important-request flag; default receiving team can be configured | Documented notifications for workspace subscribers; automatic notice to the end customer was not established |
| Buffer Suggestions | Public suggestion entry point and Buffer sign-in | Current entries included Exploring, New, Planned, Beta and Blocked by API limitation | Its dated setup article describes subscriptions and comment/status emails; we did not send a test request |
| PostHog roadmap | An idea prompt and feature entries with team names | Concept, alpha and beta stages | Coming-soon email waitlist and ready-to-try betas; a link to the changelog |
Linear retains the reason behind a request
The Linear page described more than a feature title. An integration-created request keeps the original message, its source, the requester and the time. It can appear against both the customer and the issue or project. That connection lets an internal team return to what someone asked rather than rely on a colleague's shortened label.
We also found an important-request flag and account attributes, including owner, status and tier. These are available context, not proof that a particular team prioritizes correctly. The notifications section described subscribers inside the workspace. We could not establish an automatic customer-facing completion notice from this page.
Buffer separates submitting from hearing back
The current board exposed a Suggest a Feature button, Buffer sign-in, Roadmap and What's New. Entries displayed different states: an idea about Reddit was Exploring; a recurring-posts request was Beta; a WhatsApp Channels request was Blocked by API limitation. Those labels made the difference between considering, testing and being unable to proceed visible.
Buffer's 9 August 2023 explanation described a follow-up: submitters receive emails for comments or status changes, and people can subscribe to other suggestions. We kept that behavior attributed to the dated explanation. We did not test an account or email delivery.
PostHog shows the team and the delivery stage
PostHog's page separated ideas being explored from alpha testing and betas ready to try. Feature entries named teams. It also offered a waitlist for upcoming work and a route to the changelog.
Our inspection found a public distinction between exploring an idea and letting users try it. We did not see the private customer conversations or decisions behind that work. A roadmap entry cannot establish that a request caused a release, that a beta fixed the original problem or that retention improved.
Across these three sources, we could trace context most clearly in Linear's documentation, a subscriber follow-up in Buffer's dated explanation, and public stages with team ownership on PostHog's roadmap. None gave us an end-to-end customer outcome to measure. None established permission to reuse someone's feedback as a testimonial.
Turn one customer concern into a decision
For Sofia's import problem, the next action is to read the support conversations and watch the failing step. Ask customers what they were trying to do, including those who gave up. Check usage records where available. A request count alone can't explain the obstacle.
Product or onboarding should own the decision. They may fix the flow, change instructions, investigate further or explain why they won't make the change. Record the reason and tell the affected customers what happened.
Use this proposed decision record. It is a planning tool, not a tested result:
Customer concern: [their words and source link]
Context: [task, account, product stage and date]
Evidence still needed: [conversation, observation or usage check]
Decision and reason: [change, investigate, defer or decline]
Owner and next check: [person and date]
Customer follow-up: [who replies and what they can promise]
Result to check: [task completion, adoption, retention or another relevant measure]
Public reuse: [separate approval for exact words and placement, if requested]
For an onboarding change, watch whether affected users finish that step and reach their intended task. For retention work, examine renewals and cancellation reasons over an appropriate period. Keep the customer accounts and dates visible. A change followed by better retention is an association until you've ruled out other explanations.
Our CSAT and NPS comparison can help choose a survey question. A score can start an investigation; it doesn't explain the customer's problem by itself.
What 25 SaaS homepages show
Public customer stories help with a different job: letting a buyer judge your product through someone else's experience. We checked how companies presented that evidence in September. This homepage study does not measure their product, onboarding or retention work.
How we did this
We wanted to know how sales-led SaaS companies show their customers to a first-time visitor.
On 25 September 2026, we opened 25 English-language homepages. We picked companies that sell sales, demo, customer success, data and marketing tools, and that offer a demo or a mix of demo and self-serve. On each homepage, including the menu and footer, we looked for nine things:
- Logos: customer logos. Integration logos don't count.
- Stories: a link to a customer story or case study page. A plain "Customers" link doesn't count.
- Review badge: a G2 or other review badge or callout.
- Rating: a star rating or a number of reviews.
- Wall: a named testimonial wall or quote collection.
- Referral: a named referral or advocate program.
- Community: a named customer community.
- Partner: a named partner program.
- Talk: an invite to talk to a customer.
We didn't check each company's size. We only looked at the homepage, so we can't say what drives sales. "N" means we didn't see it there. It doesn't mean the company has no such program.
Each company name links to the homepage we opened. Y = we saw it. N = we didn't.
| Company | Logos | Stories | Review badge | Rating | Wall | Referral | Community | Partner | Talk |
|---|---|---|---|---|---|---|---|---|---|
| Dock | Y | Y | Y | N | Y | N | N | N | N |
| Storylane | Y | Y | Y | Y | Y | N | N | Y | N |
| Navattic | Y | Y | Y | Y | N | N | N | N | N |
| Warmly | Y | Y | N | Y | N | Y | N | Y | N |
| UserGems | Y | Y | N | N | Y | Y | N | N | N |
| Unify | Y | Y | Y | N | N | N | N | Y | N |
| Pocus | Y | Y | N | N | N | N | Y | N | N |
| trumpet | Y | Y | Y | Y | N | N | N | N | N |
| Aligned | Y | Y | Y | N | N | N | N | N | N |
| RevenueHero | Y | Y | N | N | Y | N | N | N | N |
| Goldcast | Y | Y | N | N | N | N | N | N | N |
| HockeyStack | Y | Y | Y | N | N | N | N | N | N |
| Factors.ai | Y | Y | N | N | N | Y | N | Y | N |
| Vitally | Y | Y | Y | Y | N | Y | N | Y | N |
| Planhat | Y | Y | Y | Y | N | N | N | Y | N |
| Demostack | Y | Y | Y | N | N | N | N | N | N |
| Mutiny | N | N | N | N | N | N | N | N | N |
| Default | Y | Y | N | N | N | N | N | N | N |
| Walnut | Y | Y | N | N | N | N | N | N | N |
| TestBox | Y | Y | N | N | N | N | N | N | N |
| Common Room | Y | Y | N | N | N | N | Y | N | N |
| RB2B | Y | N | Y | Y | N | N | N | Y | N |
| Supademo | Y | Y | Y | N | N | N | N | N | N |
| Zuddl | Y | Y | Y | N | N | N | N | N | N |
| Folloze | Y | Y | Y | N | N | N | N | Y | N |
| Homepages showing it (of 25) | 24 | 23 | 14 | 7 | 4 | 4 | 2 | 8 | 0 |
Logos appeared on 24 of the 25 homepages; stories appeared on 23. The four pages with a named referral or advocate program were Warmly, UserGems, Factors.ai and Vitally. Pocus and Common Room showed communities. None of the 25 invited visitors to talk to a customer on the inspected homepage.
Those observations don't tell us how a rep finds a reference inside a deal. We didn't inspect private reference processes, customer interviews or product decisions.
Dock linked customer stories and had a Wall of Love. Storylane showed stories, a review collection, a review count and a partner page. Navattic showed a review badge and rating alongside its stories. Those combinations offered different paths from a vendor claim to customer evidence.
The badge and rating columns also differed. Fourteen of the 25 pages displayed a review badge, while seven displayed a rating or review count. Six had both fields. Eight had a badge without a visible rating or count; Warmly had a rating without a badge under our rules. A named review badge and a numerical rating were different observations, so we didn't combine them into one review-presence total.
RB2B showed both review fields without a customer-story link under our rule. Mutiny showed none of the nine fields during this visit; that says nothing about its other pages or later changes.
We kept partner programs separate from customer referrals. Of the eight homepages with a partner link, three also had a named referral or advocate program: Warmly, Factors.ai and Vitally. Storylane, Unify, Planhat, RB2B and Folloze had the partner field without the referral field. UserGems had the referral field without the partner field.
That overlap came from the September matrix, not a new visit. Counting every partner link as a customer referral would change the question we checked. A public partner program may have different participants and terms; its homepage link alone doesn't tell us that existing customers introduce buyers.
The study counted public placement. It cannot show whether a buyer used a story, whether a reference call happened or whether a company grew because of customer input.
Our older guide to getting more G2 reviews has collection ideas, but don't use its positive-score targeting advice. G2's current in-app guidance says not to solicit only positive reviews. Apply a consistent experience-based eligibility rule regardless of likely rating, and check the destination's current incentive rules.
The customer advocacy vs. paid ads comparison offers background on the budget choice. Its cost assumptions aren't a forecast for your team; compare your own spending, staff time and attributable outcomes.
Give each customer channel an owner and a useful measure
These six channels cover sharing experience, supporting buyers and growing accounts. Product fixes and onboarding decisions still need their own owners.
In Sofia's imagined company, the rep expects CS to find a reference. CS thinks marketing owns reviews. A referral sits in an inbox. Customer marketing can coordinate the asks, while each team owns its part.
| Channel | What the customer does | Who owns it | Number to watch |
|---|---|---|---|
| Reviews | Writes an honest review after enough product experience | Customer marketing, with neutral eligibility rules | Recent reviews; deals where reviews helped |
| References | Takes a call with a matched prospect who has a specific doubt | Sales enablement; the rep asks, the CSM checks fit | Reference coverage by segment; win rate of deals with a reference |
| Referrals | Introduces a peer with the same problem | Customer marketing or growth | Qualified intros; pipeline they created |
| Case studies | Approves a detailed story: the old way, the change, the result | Product marketing | How often sales uses it; pipeline and win rate it helped |
| Community | Answers peer questions or shares how they work, by choice | Community or brand lead | Active customer contributors; members who become meetings |
| Expansion | Works with the account team to find a new use or team | Account manager, with CSM | Expansion pipeline; net revenue retention |
Our B2B referral program guide covers the intro workflow. The customer marketing playbook for growing teams helps organize the wider role. Check current destination rules before adapting review or reward suggestions from a broader program guide.
Don't count every mention as pipeline. Ask RevOps for three things. A source field for referrals. A rule for when a customer story "helped" an open deal. A separate view for adoption and expansion.
A case study downloaded after a deal closed didn't help that deal. A reference call a rep asked for can still matter, even if the buyer first came from paid search. Keep "this created the deal" apart from "this helped the deal." These associations don't prove the asset caused a win.
Collect and organize the stories sales needs
HighAdvocacy handles the collection and reuse part of this work. You can set written or video testimonial questions in a campaign and send customers a hosted campaign link.
For supported review-site asks, customers open the destination, post there and return with submission evidence. The review site keeps authority over moderation. Optional Smart Draft helps with review and social-post asks; testimonial questions use their own written or video response flow.
Your team can review submissions in the Inbox and search approved material in the Library. Keep permission for the intended quote and placement alongside the asset. See current plans, or open HighAdvocacy to set up a campaign.
Keep product prioritization, referral follow-up and live-reference matching with their responsible teams. HighAdvocacy's collection workflow doesn't replace those decisions.
A 90-day plan to get started
Start with one unresolved customer problem and one buyer-evidence gap. This is a proposed order of work, not a revenue promise.
| When | What you do | Who | You're done when |
|---|---|---|---|
| Days 1–15: find the gaps | Read onboarding/support conversations and lost or stalled deal notes. List customer obstacles, buyer doubts and existing approved stories. | Product or onboarding owner, CS, product marketing and enablement | Each priority has a source, an affected task and a decision owner |
| Days 16–30: decide and ask | Choose one experience change to investigate. Invite story interviews or references separately by willingness and fit. For public reviews, use neutral experience-based eligibility. | Experience owner acts; customer marketing works with CS | The change has a check date; optional customer asks have permissions and contact limits |
| Days 31–60: act and share | Test the chosen change and report back to affected customers. Publish approved stories for specific buyer doubts. Give reps one reference-request path. | Product/onboarding delivers; product marketing publishes; enablement shares | Customers hear the decision; reps can find a relevant approved story; requests are logged |
| Days 61–90: check and adjust | Review task completion or adoption, renewals where observable, story use, declines and repeated asks. Read the underlying notes before deciding what to repeat. | Experience owner and RevOps, with sales and CS | You can separate the customer change, its observed result and the assets used in deals |
Your reps can copy this prompt to request a relevant story:
Deal: [opportunity and current stage]
Buyer question: [the exact objection or decision they need to make]
Match needed: [industry, company size, region, use case, or prior tool]
Best format: [review, approved quote, case study, or reference call]
Deadline: [date the buyer will decide]
Permission status: [approved asset or customer contact to confirm]
If the answer needs a live call, check the customer is willing. Send them the prospect's real question ahead of time. If a published story already answers it, send the buyer that first.
For your first review, open the last 10 stalled or lost deals alongside recent onboarding and support notes. Choose a repeated question that needs a customer story and a repeated obstacle that needs a team decision. Give each a named owner and a next check date.
FAQ
Is customer-led growth the same as product-led growth?
Product-led growth uses the product to drive acquisition and expansion. Customer-led growth guides decisions using customer insight and value, including decisions inside that product experience. It can also guide a sales-led business.
How do you measure customer-led growth?
Choose the measure that matches the decision: completion of an onboarding task, adoption, retention or expansion. For customer stories and referrals, keep sourced pipeline separate from influenced pipeline. Record dates and who was affected before attributing a change to the work.
Which channel should a 50–200 person sales-led SaaS company start with?
Start with the obstacle you can document. If users cannot reach value, address that experience. If reps need a peer in one industry, build reference coverage and a relevant story. A thin review profile calls for consistent, honest review invitations.
