A free product can attract thousands of contributions while leaving its maker unsure who will pay. That was the uncomfortable gap behind Product Pains, the public feedback community that became Canny. Users were willing to submit ideas. The companies expected to act on those ideas were much harder to engage.
The useful question for a founder in this position is not whether the free product is popular. It is whether the activity reveals an expensive job for a specific buyer. In Canny's case, the job was helping a product team collect, organize, and respond to feedback from its own customers. The team discovered it through conversations with companies, built a widget for that workflow, and sold it before treating the business model as proven. Andrew Rasmussen's early company account and Sarah Hum's later account describe that sequence from different points in the company's history.
The short answer: when a free product gets used but its original customer will not pay, trace the work it creates for another participant. Ask that participant to commit to a small, specific paid solution. Do not mistake traffic, votes, or praise for a purchase decision.
What the early activity actually showed
Product Pains let people leave public feedback about products. Sarah Hum recalls that thousands of people posted feedback, yet the businesses receiving it largely ignored the site. An optimistic reading would have called that traction. A more careful reading separates three facts: contributors had something to say, companies already had feedback coming from many channels, and the proposed public destination did not fit the way companies worked. Source: Hum's account.
Rasmussen described the operating problem from the company's side. Product managers had messages spread across chats, email, and support tickets; reading them all and remembering which customer wanted what was difficult. The team built a widget to help businesses collect and track requests. He recalls their first $19 monthly customer, then $100 in monthly recurring revenue by December 2016. Those figures are historical self-reports. Their role here is to date the paid experiment, not to predict what a similar tool will earn. Source: Canny's founder timeline.
| Signal in the case | What it established | What it did not establish |
|---|---|---|
| People submitted feedback | An end user wanted to be heard | A company would pay for a public comment site |
| Companies asked for a widget | Feedback collection belonged in their workflow | Every company wanted the same feature set |
| A stranger paid $19/month | At least one buyer valued the solution enough to pay | Repeatable demand or profitable acquisition |
| Existing users tried the pivot | Migration could seed early usage | Retention or willingness to pay across a market |
This table is the distinction I would keep on the wall while evaluating a free community product: each signal validates a narrower claim than the headline suggests. The first payment matters, but it is a beginning. It tells the team which conversation to have next and which customer behavior to watch.
The pivot changed the customer, the setting, and the promise
It is easy to describe Canny as a feature pivot: add an embeddable widget and charge for it. That misses the deeper change. Product Pains was a destination where consumers left feedback about any company. Canny became a tool owned by a product team and placed inside that team's feedback process.
The product's original promise was roughly, "your feedback can be visible." The paid promise became, "your team can see what users want, discuss it, decide what to build, and keep the right users informed." Canny's 2017 launch post described boards where customers could propose and vote on ideas, while the team could comment, update status, and notify participants. Its present portal still connects a public feedback board with discussions, status updates, and a roadmap. That continuity supports the interpretation that the paid job was an ongoing workflow, rather than a single widget. Sources: Canny's launch post and current portal description.
The first version need not have delivered every part of that promise. The important move was to attach feedback to the buyer's existing work: deciding priorities and communicating decisions. A founder assessing a similar pivot should ask who owns the budget for that work, where it happens today, and whether the new product shortens or improves the process enough to justify a recurring cost.
There is another practical reason this matters. A free community can have one-sided enthusiasm. Contributors value being heard, but the people expected to read and act on every contribution face a time cost. If the product makes that cost worse, high user participation may make the buyer less interested. Canny's new workflow organized incoming demand and limited notifications to relevant participants. It gave the product team a reason to invite its customers into the system.
The validation sequence, without the hindsight
Rasmussen's timeline is useful because it separates discovery from launch. The founders first spoke with teams about how they gathered feedback, kept track of it, and decided what to build. They built a widget for the specific job they heard about. A paying customer appeared before the public Product Hunt launch. The team then let existing users try the pivot, fixed problems for a week or two, and launched more broadly. Canny's early account says it had a few paying customers before that launch and approximately $1,000 MRR in May 2017. Source: founder timeline.
This is a better sequence to study than a single launch-day graph:
| Stage | Evidence Canny sought | Decision enabled |
|---|---|---|
| Interviews with product teams | Existing feedback was scattered and hard to use | Choose a buyer and a job |
| Small widget | A team would put the solution in its own workflow | Test adoption in context |
| First payment | A stranger would exchange money for the job done | Keep improving the paid path |
| Migration and soft launch | Existing participants could use the new product | Find friction before broad promotion |
| Public launch | More qualified teams could discover it | Expand the acquisition test |
The stages are not a universal calendar. A founder can spend longer at any one of them. What matters is that the next commitment is stronger than the last: from stated pain, to installation, to payment, to continued use. In the later Baremetrics account, Hum says the founders had initially positioned Canny as "feedback for anything" and then narrowed their customer focus after observing which teams benefited. That is a second kind of validation: learning which buyers can succeed with the product, not merely which buyers will try it. Source: Hum's account.
Oddig's buyer-switch test
When a free tool has use but no obvious revenue, try a buyer-switch test before adding a paywall. Record five answers. A blank answer is a research task, not a cue to guess.
- Who performs the visible action? Name the person submitting, sharing, browsing, or creating. In this case, an end user submitted feedback.
- Who inherits the work created by that action? Follow the request into someone's inbox, spreadsheet, support queue, or planning meeting. Product teams inherited the need to understand and act on feedback.
- What costly job is repeated? Describe it without mentioning your proposed feature. "Keep track of what customers request and inform them of the decision" is a job; "use a feedback widget" is a feature.
- What would the buyer replace? Ask for the current process, owner, weekly effort, errors, and lost opportunities. Without a real alternative, there may be no budget.
- What commitment proves value? Choose one paid or operational commitment that can happen now: payment, a pilot with named users and a deadline, or replacing an existing process. A complimentary call is weak evidence.
The fifth answer should be specific. "They said they would pay" is not equivalent to "they paid $19 for this workflow". Nor is a sign-up equivalent to making the product part of a team's weekly decision process. Where payment is impossible for structural reasons, such as procurement, use a documented pilot with agreed success criteria and a next decision date. Keep those cases separate in the evidence log.
A small experiment a founder can run
Suppose a free directory lets developers recommend tools to each other. Contributors enjoy adding listings, but paid featured placements do not sell. Before redesigning the site, ask five teams that repeatedly review tool requests how they record choices. If three show you a messy, recurring process, offer to deliver a weekly vetted shortlist or an internal decision board. Put a price on the bounded service or prototype. The experiment is not whether people like your directory; it is whether a buyer will change a workflow to get a better decision.
Write down the predicted outcome before the calls: for example, at least two teams agree to a paid pilot, each supplies a real backlog, and one continues after the first cycle. Those thresholds are choices for the experiment, not market benchmarks. If teams only want a public listing, the buyer-switch hypothesis has failed. If they want the service but reject software, a service-first product may be the next test. This way the experiment has a stopping condition instead of turning every polite conversation into "traction".
Why the new product could spread through its own use
There was a second mechanism in Canny's early growth. Rasmussen says the team's strongest organic channel was a "Powered by Canny" link on customer-facing feedback boards. Some visitors to a customer's board were themselves founders or product managers; they saw the tool in use and could adopt it for their own product. He also described work on the landing page, pricing, registration, and trial onboarding after that inbound traffic began arriving. Source: founder timeline.
That distribution channel exists only because the product is exposed to a relevant third party. It would not automatically appear in an internal-only analytics dashboard. The lesson is to inspect the path from use to discovery: who sees the product while a customer gets value, and are those viewers plausible buyers? A badge or referral link cannot rescue a workflow that customers are unwilling to show. Canny's board was meant to be seen by a customer's users, so the exposure followed the job itself.
Before borrowing this tactic, map its permissions and trade-offs. An enterprise customer may need private boards or branding controls. A visible vendor link may be unacceptable in a sensitive workflow. If visibility is a paid-plan feature rather than an inherent part of the product, the channel can disappear as customers upgrade. A founder should test those conditions with actual customers rather than putting "product-led growth" in a forecast.
What the case cannot prove
Hum's 2020 account reported $800,000 in annual recurring revenue, a team of seven, and a profitable bootstrapped company. That is useful historical context, but it is a company account published years after the initial pivot. It does not independently establish the contribution of any single decision, the acquisition cost of later customers, or current performance. Source: Hum's historical account.
The market also mattered. Software teams already collected feedback through support tools, email, and meetings. The new product fit a recurring job with a recognizable owner. A consumer community with no team-side workflow might not have the same buyer hiding in plain sight. Equally, asking for payment too early can produce a false negative if the proposed offer does not yet perform the job.
The responsible takeaway is narrower than "turn your free product into B2B SaaS." Follow the cost created by use, identify a buyer who owns that cost, and ask them to commit to a bounded improvement. If the buyer cannot describe the problem, will not change the workflow, or will not pay, the free product has not yet exposed a business.
Decision worksheet: is the free signal worth a paid test?
Use this worksheet before building the paid version. Fill it with direct observations from at least five conversations. Do not substitute a traffic chart for interview notes.
| Question | Stronger evidence | Weak evidence | If weak, do this next |
|---|---|---|---|
| Is there a named buyer? | One role owns the recurring job and budget | "Companies" might pay | Interview one role in a narrower segment |
| Is the job already being done? | You can inspect its spreadsheet, queue, or meeting | The buyer says it sounds useful | Ask for a live walkthrough of the current process |
| Is the pain recurring? | It appears every week or at a costly event | It happened once | Wait for the next cycle and observe |
| Does the offer fit the workflow? | The buyer installs, shares, or replaces a step | They praise a mockup | Run a limited operational pilot |
| Is value strong enough to charge? | A buyer pays or starts procurement | An email address or verbal interest | Price a specific outcome and ask for a decision |
| Will the result repeat? | More than one similar buyer completes the job | One enthusiastic design partner | Test a second and third buyer without custom work |
An evidence log that looks like Canny's early transition would move from user contributions to company conversations, then to an installed solution and a first payment. The exact product and price can vary. The standard of proof should not.
Related Oddig reading
- A demand-validation test before building helps distinguish a conversation from a commitment.
- What to build after a short launch spike continues the question once the first qualified customers arrive.
Sources and method
- Andrew Rasmussen, Canny's early operating timeline: interviews, widget, first payment, migration, launch, and organic distribution.
- Sarah Hum, Canny's retrospective at Baremetrics: free-community limits, buyer discovery, focus, and historical revenue.
- Canny's 2017 launch explanation and current portal description: product behavior then and now.
Oddig did not interview Canny's founders or inspect private revenue records. The buyer-switch test and worksheet are editorial tools derived from the attributed evidence. They have not been tested with Oddig customers.