How Loom Knew Which Part of Its Product to Keep
Short answer: Keep the feature that users choose independently, repeat for a valuable job and would miss if removed, even when they ignore the surrounding product. Test it as a standalone offer with at least 20 suitable users, then compare activation, repeated use, support burden and paid commitment against the full product. Do not preserve a feature merely because it is technically impressive or heavily used as a compulsory step.
A struggling product can contain one behaviour that works. The hard part is separating genuine pull from usage created by navigation, novelty or the founder personally guiding every session.
Loom began as Opentest, a user-testing product whose workflow included a screen-and-camera recording extension. Co-founder Shahed Khan says the team noticed a customer using that recording capability to summarise research for colleagues, rather than for its intended testing job. The founders separated the recorder, launched it on Product Hunt in June 2016 and saw much stronger adoption than the original product. Khan describes the decision in this founder interview. A later company account says the first Atlassian employee began recording with the product on day five after that launch. Loom's acquisition announcement recounts the early adoption.
The public record does not supply comparable retention, revenue or runway for every earlier version. Treat the story as a decision pattern, not a complete quantitative case.
Use the Feature Survival Test
The Feature Survival Test gives each candidate feature five trials.
| Trial | Evidence | Misleading substitute | |---|---|---| | Discovery | Users seek or mention it unprompted | Founder directs them to it | | Independence | It solves a complete job alone | It is merely a required step | | Repetition | The same user returns for the job | One-off curiosity | | Transfer | Different suitable users understand it | One customer has a bespoke need | | Commitment | Users pay, switch or invest effort | Positive survey answers |
My position is that a pivot should usually cut more than the team feels comfortable cutting. Keeping several weak features to protect sunk effort makes the new proposition harder to understand and the evidence harder to read. Preserve one complete customer outcome, not the largest quantity of code.
Start with behaviour before interviews
List the actions users take without prompting. For each feature, measure the proportion of activated users who use it, repeat within the natural cycle and reach an observable outcome. Segment voluntary actions from compulsory setup.
Then interview users about a recent use. Ask what triggered it, what they did before, what happened afterwards and what would replace it. Avoid asking which feature they like best. Preference language often rewards visible design while hiding weak necessity.
The fact that video appeared in many use cases helped Loom see a broader communication job. Breadth alone can also be a warning if every group uses a feature for a different reason that needs different development. Look for a common job beneath the contexts.
Use [evidence of demand](/market-research/is-there-demand-for-your-idea/) to distinguish repeated problem-solving from engagement.
Remove the surrounding product in a test
Create a standalone path to the feature with one message and one outcome. Do not rebuild the entire application. A landing page, simplified workflow or manual onboarding can isolate it.
Recruit existing users who relied on the feature and new users who have the same job but no attachment to the old product. Existing users show continuity; new users reveal whether the feature is understandable without history.
Hold the test long enough for repetition. Daily communication may need two weeks. Monthly reporting may need three months. Define the cycle before launch so a burst of first use does not become false retention.
Price the complete job
A feature can be loved and still be difficult to monetise. Ask for an appropriate paid commitment once users can experience the outcome. Charge for the job, not the quantity of buttons removed.
Track support and infrastructure closely. A video feature may create storage, processing and bandwidth cost that an earlier testing product did not. A reporting feature may require expensive data connections. Calculate contribution under realistic use, including heavy users.
If the feature works only as a free acquisition route into another paid product, state that model and test the conversion. Do not call attention revenue.
Worked example: ScreenNote Video
ScreenNote has a broad customer-feedback platform with five features. Usage data shows that 60 of 100 activated users make a screen recording, but only 18 send a formal feedback survey. The team tests recording as a standalone product with 40 suitable users for four weeks.
Thirty-two create a first recording, 24 record again in week two and 16 agree to pay £12 a month. Each paid user incurs £1.80 of processing and storage plus £2.20 of payment and support cost.
| Measure | Calculation | Result | |---|---:|---:| | Activation | 32 ÷ 40 | 80% | | Week-two repeat among activated | 24 ÷ 32 | 75% | | Paid conversion from test group | 16 ÷ 40 | 40% | | Contribution per paid user | £12 - £1.80 - £2.20 | £8 | | Monthly cohort contribution | 16 x £8 | £128 |
The standalone onboarding cost £720 of design and engineering time. At £128 monthly cohort contribution, recovery takes £720 ÷ £128 = 5.6 months, assuming no churn. ScreenNote should keep testing the recording product, but it must measure paid retention before claiming the pivot works. These figures are illustrative, not video-software benchmarks.
Decide what to delete, archive and retain
Classify the old product into three groups:
- Core: essential to the surviving outcome.
- Bridge: temporarily needed for existing customers or migration.
- Archive: no longer developed or sold.
Set dates and customer communication for bridge features. Deletion can affect contracts, data retention, exports and accessibility. Give users a lawful way to retrieve information and honour paid commitments. Requirements vary by country and data type, so obtain qualified legal and security advice before removing functionality or changing material terms.
Do not keep features indefinitely because one account might object. Compare the revenue and exit cost of that account with the development and clarity cost imposed on every future customer.
Use surveys as explanation, not verdict
Loom's published account mentions surveys that asked how people used quick video and how it made them feel. Surveys can reveal jobs and language after behaviour appears. They are weak when used to vote on a hypothetical roadmap.
Weight answers by observed use. A repeated user explaining a workflow deserves more attention than a dormant account choosing features from a list. Combine what people did, what they say the outcome was and what commitment they make next.
Make the survival decision in 30 days
In week one, rank features by voluntary use and repeat behaviour. Interview ten recent users about actual episodes. In week two, create the smallest standalone path for the strongest complete job. Run it with at least 20 suitable users for one natural cycle and request a paid commitment. In week four, compare activation, repetition, contribution and support with the old product. Name one core, time-limit bridge features and archive the rest. Extend the test only when a defined missing observation requires it.
Related guides
Frequently asked questions
Does the most-used feature always survive?
No. A feature may be used because every user must pass through it, because it is free, or because the founder demonstrated it. Examine voluntary discovery, repeated use and the outcome achieved. Remove compulsory steps from the comparison where possible. A less-used feature can be stronger if a specific segment repeatedly pays for a valuable job. The survivor should carry a complete proposition and workable economics, not win a usage popularity contest. Compare behaviour among suitable users rather than the entire mixed customer base.
How many users do I need for a feature test?
Twenty suitable users can expose obvious activation and usability patterns, but more may be needed for retention, pricing or varied segments. Choose enough users to generate at least ten repeated-use observations within the natural cycle. Avoid mixing audiences merely to increase the count. A business tool with deep weekly use may produce useful evidence from fewer accounts than a consumer feature with casual activity. State the limits and continue measuring after the decision. The test should reduce uncertainty, not pretend to provide universal statistical proof.
Should I tell existing customers that we may remove features?
Yes, once the proposal is concrete enough to affect their planning. Explain what may change, why, the timing, migration or export options and how paid commitments will be handled. Invite evidence about operational dependence, not a simple vote. Some customers will prefer the old product, and their exit cost belongs in the decision. Give account owners a named contact for material concerns. Contract, consumer, accessibility and data duties vary, so review current terms and obtain qualified legal advice before materially reducing a paid service.
What if different customer segments prefer different features?
Calculate whether each segment can support a coherent product and go-to-market route. Two strong jobs may justify separate editions or products, but an early team can rarely build both well. Compare contribution, reachability, retention and development cost, then choose one primary segment. Preserve data or code for the other only if doing so has little ongoing cost. Do not maintain a confusing bundle to avoid choosing. Document which segment controls the roadmap. Use [how narrow a customer segment should be](/market-research/how-narrow-should-your-customer-segment-be/) to make the boundary explicit.
Can a feature become a separate product without a full rebrand?
Yes. Test it under a descriptive name or distinct page before funding a new identity. The important question is whether new users understand and buy the standalone outcome. A rebrand introduces another variable and can discard useful trust. Keep acquisition records separate so you can compare the test fairly. Change the name when the old one materially misrepresents the job, restricts the audience or creates confusion. Check trade mark, company-name and domain implications with qualified local advisers before making a permanent change.
How long should I support the old version?
Support it long enough to honour contracts, protect customers and provide a reasonable migration, but not indefinitely by default. Segment customers by usage, revenue, dependency and data needs. Publish an end date, export route and support scope. Price the staff and infrastructure needed during the bridge. If a customer needs extended support, consider a separately priced agreement only when it does not delay the new product. Legal duties and reasonable notice vary by contract and jurisdiction, requiring qualified advice for material changes.
Comments (0)