When Early Users Say Your Product Does Too Much: VWO's Feature Cut
Short answer: When several independent users say your product does too much, identify the one job they complete most often, value enough to pay for and can describe without prompting. Remove or hide everything that delays that job for one test cohort. Keep the cut only if activation, time to first value and paid conversion improve without damaging retention.
“Too much” is not actionable feedback. It can mean confusing navigation, an unclear promise, slow setup or several unrelated customer groups forced into one product.
The founder's task is not to obey every request for simplicity. It is to find which capability earns the right to remain.
How VWO found its core job
Paras Chopra's original Wingify product combined several marketing capabilities. He says 15 to 20 early users from Hacker News consistently reported that it tried to do too much. Chopra retained A/B testing and built a visual editor around that job.
Wingify's ten-year VWO history describes the evolution from the broad early product. In a founder account, Chopra says he set a first-month revenue goal of US$1,000 and the paid product made US$4,000. Within eight months, monthly revenue exceeded US$25,000. The company remained bootstrapped and hired its first employee in 2011.
Those results do not prove that removing features caused all subsequent growth. They do show that repeated confusion preceded a deliberate reduction and a clearer paid product.
My position is that an early product should usually do one complete job exceptionally clearly, even if the founder's vision is a suite. Suites are earned after customers understand and buy the core. Breadth before recognition taxes every acquisition and onboarding attempt.
Use the Product Reduction Signal Test
The Product Reduction Signal Test ranks each capability against five signals.
| Signal | Question | Evidence | |---|---|---| | Repeated use | Is it used in successful sessions? | Event or observation data | | Outcome | Does it complete the customer's main job? | Finished result, not clicks | | Willingness to pay | Does its absence block a purchase? | Paid test or lost-sale record | | Independence | Can it stand without the other features? | Reduced pilot | | Support burden | Does it create disproportionate confusion? | Tickets and session notes |
Score each capability from 0 to 2 on every signal. A feature with strong outcome and willingness-to-pay scores can survive low frequency if the job is occasional. Do not use total clicks as a proxy for value.
Translate “too much” into observed friction
Ask users to complete the core task while narrating what they expect. Do not demonstrate first. Record where they pause, choose the wrong route or ask what the product is for.
Then ask four factual questions: what brought you here today, what result were you trying to produce, which part did you expect to pay for, and what would you use instead? Interview users who succeeded and those who abandoned setup.
When five or more independent users fail at the same decision point, you have a candidate for reduction. The guide on [testing an idea before spending money](/business-ideas/test-your-idea-before-spending/) explains how to favour behaviour over compliments.
Choose the core by outcome, not build effort
Founders protect features that took months to build. Customers do not value sunk cost. Rank capabilities by the outcome they produce and the evidence behind payment.
Write the product in one sentence: “You use this to [complete job] when [trigger].” If two features need different triggers, buyers or success measures, they may belong in separate products or later modules.
Cutting can mean deleting, hiding, freezing or separating. Hiding a capability for a test cohort is often safer than immediate deletion. It preserves reversibility while exposing whether the core can carry the product.
Run a reduced-product cohort
Give comparable new users either the existing experience or the reduced version. Keep price, traffic source and customer segment stable. Measure:
- percentage reaching the first valuable outcome;
- median time to that outcome;
- support minutes per activated account;
- paid conversion and 60-day retention.
The reduction wins only if the improvement survives payment and retention. A minimal interface can lift sign-ups while disappointing advanced buyers later.
For products touching data, regulated decisions or accessibility, removing controls may create legal or operational risks. Requirements vary by sector and country. Obtain qualified local advice before removing consent, security, record-keeping or required disclosure functions.
Worked example: SplitTest Studio
SplitTest Studio offers landing-page experiments, surveys, heatmaps and email pop-ups. These figures are illustrative.
It observes 40 trial users. Twenty-three attempt an A/B test first, eight open heatmaps, five try surveys and four create pop-ups. Only 11 complete any outcome. Support takes 31 hours, costing 31 x £28 = £868.
The team scores the capabilities:
| Capability | Use | Outcome | Payment | Independence | Low support burden | Total | |---|---:|---:|---:|---:|---:|---:| | A/B testing | 2 | 2 | 2 | 2 | 1 | 9 | | Heatmaps | 1 | 1 | 1 | 1 | 1 | 5 | | Surveys | 1 | 1 | 0 | 2 | 1 | 5 | | Pop-ups | 1 | 0 | 0 | 1 | 0 | 2 |
SplitTest Studio hides everything except A/B testing for the next 40 comparable trials. Twenty-six launch a test, 21 reach a result and support falls to 14 hours. Activation rises from 11 divided by 40 = 27.5% to 21 divided by 40 = 52.5%. Support cost falls to 14 x £28 = £392.
Nine reduced-cohort users pay £49, compared with five in the original cohort. First-month revenue rises from £245 to £441. At day 60, eight reduced users remain versus four original users. The cut improves both clarity and retained payment.
Heatmaps are not deleted. They become a later add-on tested with retained customers who ask for diagnostic context. Pop-ups are removed because they do not support the central job.
Avoid replacing one broad product with one narrow guess
Early usage can reflect what is easiest to find, not what customers value most. That is why outcome and payment matter. Also check whether the early cohort represents the intended segment. Hacker News feedback may suit developer-facing software but mislead a product intended for a different buyer.
If two jobs both score strongly, test separate landing pages and onboarding paths before splitting development. The article on [identifying your first profitable customer segment](/market-research/first-profitable-customer-segment/) helps determine whether the apparent feature conflict is actually a segment conflict.
Make the cut in 21 days
In days 1 to 5, observe ten users and classify every feature against the five signals. Choose the one complete job by day 7. Create a reversible reduced experience during the next week.
Run it with at least 20 comparable new users, or a smaller number of high-value buyers with stronger commitments. Review activation, time to value, support, payment and early retention on day 21. Keep, revise or reverse the cut from those measures. Do not reopen the full roadmap because one loud user misses a feature.
Related guides
Frequently asked questions
Should I delete the unused features immediately?
Usually not. First hide or freeze them for a defined cohort, because low usage may result from poor discovery or the wrong sample. Preserve customer data and existing workflows while you test. If retained paying customers depend on a feature, give notice and a migration route before removal. Deletion becomes sensible when the capability has weak outcome and payment evidence, creates material maintenance cost and no viable segment depends on it. Contract, data-retention and consumer obligations vary, so seek qualified local advice before withdrawing a promised function.
What if different customers value different features?
You may have multiple segments rather than one overloaded product. Group customers by trigger, buyer, outcome and willingness to pay, then calculate contribution and support for each group. If two segments are attractive, give them separate entry paths or packages before building two products. If one segment pays more but requires extensive bespoke work, do not assume it is superior. Choose the first segment whose complete job you can serve repeatably. A product can broaden later, but early messaging and onboarding should make one path unmistakable.
How many user interviews are enough to justify a cut?
Five repeated observations can identify a serious friction point, while ten to 15 across successful and abandoned users usually provide a better decision base. Numbers are indicative and should reflect purchase value and cycle length. Do not count agreement with a leading question. Watch people attempt the task, inspect usage and ask what they did instead. Then validate the proposed reduction in a live cohort. Interviews identify the hypothesis; changes in activation, payment and retention decide whether the cut was correct.
Can fewer features justify a higher price?
Yes, when the reduced product completes a valuable job faster or more reliably. Customers pay for an outcome, not feature volume. Test the price independently after confirming that the simpler experience works, because changing scope and price together makes the result harder to interpret. Quote the higher price to the next five comparable prospects and compare contribution, not just win rate. A narrow product that reduces support and acquisition friction can earn more contribution at the same price even before an increase.
What if users ask for removed features after paying?
Record the request, the job behind it and whether it blocks renewal. Do not automatically restore the old interface. A removed feature may represent a genuine adjacent need, a familiar habit or a workaround for a flaw in the core. If several retained customers share the same job and would pay, test it as a clearly scoped add-on or later step. Honour capabilities promised in the sale and communicate material changes. The aim is not permanent minimalism; it is controlled expansion from a understood core.
Is an all-in-one product ever right at launch?
Yes, when the value comes specifically from combining the functions and customers already buy the category as an integrated system. Even then, onboarding should lead to one first outcome rather than presenting every capability equally. Evidence might include customers replacing several connected tools, paying for consolidated reporting or requiring one compliance record. An all-in-one claim without integrated value is usually a feature inventory. Test whether removing one component breaks the outcome. If it does not, that component should not complicate the first experience.
Comments (0)