Ignoring users.

Companies rarely fail because nobody ever spoke to a user. They fail because user reality cannot change a consequential decision.

Feedback exists everywhere: sales calls, support tickets, churn, product analytics, reviews, implementation work, community posts and interviews. Yet the company can remain blind. Signals are sampled badly, softened during synthesis, detached from context, routed to teams without authority or collected after the roadmap is already irreversible.

The sequence is:

user behavior → partial signal → narrative filter → ownerless insight → unchanged commitment → widening reality gap.

The causal thesis is:

Ignoring users becomes fatal when the company has no truth-preserving loop that converts observed behavior, negative evidence and dissent into a decision with an owner, so internal narrative keeps winning even while feedback exists.

Ignoring users does not mean refusing every feature request. Users are experts in their circumstances, struggle, alternatives and costs. They are not obliged to design a coherent product or predict technology. Obeying requests literally can be another way to avoid learning.

The operating requirement is a feedback loop:

1. define the decision question;
2. observe relevant users in the relevant context;
3. preserve behavior and contradiction;
4. synthesize without erasing minority or negative evidence;
5. assign an owner and threshold;
6. change, test or consciously retain the decision; and
7. return the outcome to users and the organization.

This manual covers failure of that loop. It excludes teams that listen accurately, learn quickly and still choose a product or segment that does not produce sufficient demand. It also excludes founder exhaustion that prevents action despite accepted evidence. Those are related but distinct.

Tunnel vision is not stubbornness alone. It is an information architecture that protects a story.

## The company listens through proxies

Executives hear selected enterprise accounts. Product sees summarized tickets. Sales reports objections from open deals. Success teams protect relationships. Analytics reports events the product was instrumented to capture.

Each view is useful and biased by role.

Proxy-only listening creates systematic omissions:

• people who never complete onboarding;
• prospects who decline the first call;
• quiet users who construct workarounds;
• former customers who stopped replying;
• non-buyers excluded by the current product; and
• frontline employees whose evidence conflicts with leadership.

Direct contact is not ceremonial empathy. It lets decision-makers inspect the distance between raw behavior and organizational summary.

## Feedback is sampled to confirm the roadmap

Teams recruit available, enthusiastic users. They ask what people think of a concept after explaining it. They count positive reactions without requiring behavior or sacrifice. They treat power users as representative of new users.

A research sample is not representative merely because it is large. It must contain the situations that determine the decision. If the question concerns onboarding, existing advocates are a weak sample. If the question concerns willingness to pay, free users praising a feature are incomplete evidence.

## Requests lose their context

A feature request is a proposed solution. Remove the circumstance and it becomes dangerous.

“Export to spreadsheets” might mean:

• the user cannot complete analysis in the product;
• a manager needs an audit artifact;
• procurement fears lock-in;
• an integration is missing;
• a user wants offline review; or
• the product is not trusted as a system of record.

Six identical request labels can describe six different failures. Counting them may produce the wrong feature while preserving the original problem.

Capture the job, trigger, current workaround, consequence and evidence of importance.

## Negative evidence is normalized away

Organizations learn to protect morale and commitments through language:

• churn becomes “customer fit”;
• abandonment becomes “low intent”;
• repeated support work becomes “education”;
• refusal to pay becomes “budget timing”;
• a workaround becomes “power-user behavior”; and
• a failed pilot becomes “valuable learning” without a changed decision.

Positive evidence enters roadmaps. Negative evidence enters footnotes.

The user truth system must therefore carry disconfirming evidence explicitly and require leaders to state why it does not change the decision.

## Research is detached from authority

A research team can produce excellent findings while the company ignores users structurally. If roadmap owners can acknowledge a report, thank the team and proceed unchanged, insight has no control path.

Every study needs a decision owner, a decision date and predeclared possible actions. Otherwise research becomes internal publishing.

## Build size makes learning politically expensive

The longer and larger the initiative, the harder it is to accept contradictory evidence. Careers, board narratives, vendor contracts and launch plans attach to it. Teams then ask feedback questions that optimize the chosen design rather than test the premise.

The cheapest learning happens before commitment. The most valuable listening often threatens work already done.

Build a map from raw user evidence to product decision.

## Begin with a decision question

Bad question: “What features do users want?”

Useful questions:

• Can a new operations manager reach the first valuable outcome without expert help?
• Which event causes a finance lead to replace the current workflow?
• Why do retained users export data before the monthly review?
• Which risk prevents a qualified buyer from beginning a pilot?
• What behavior predicts abandonment in the first week?

A decision question defines whom to observe and which evidence matters.

## Triangulate evidence

Use at least three forms where the decision is material:

• behavior: observed workflow, usage sequence, abandonment, workaround;
• reported context: interview, support narrative, sales or success account;
• sacrifice: time, money, data, reputation, switching effort or repeated return.

Statements without behavior can be politeness or aspiration. Analytics without context shows what happened but can misstate why. Sacrifice distinguishes interest from importance.

The UK government service standard similarly places continuing user research and evidence at the center of understanding needs ^[6]. The useful principle is not government-specific: understanding must persist through delivery, not end after discovery.

## Audit representation

For each evidence set record:

• target segment;
• recruitment source;
• lifecycle stage;
• user versus buyer role;
• success, failure and churn status;
• important exclusions; and
• incentives for participating.

Do not hide exclusions in a research appendix. They determine how far a conclusion can travel.

## Preserve the chain

Every synthesis claim should link back to raw evidence. Keep exact behavior, relevant quotations, sample context and contrary examples. A colorful theme label without traceability invites narrative editing.

## Inspect decision throughput

Track:

• material questions opened;
• time from evidence to decision;
• decisions changed, retained or killed;
• assumptions with reversal thresholds;
• experiments completed;
• user outcomes after change; and
• unresolved contradictions.

The goal is not to maximize the percentage of decisions changed. It is to make the treatment of evidence observable.

## Use loop states

• Green: representative evidence reaches a named owner, changes a testable decision and returns as measured outcome.
• Amber: evidence is credible but sample, authority or closure is incomplete.
• Red: roadmap claims cannot be traced to user behavior, or negative evidence has no decision path.
• Black: an irreversible build rests on a contradicted user premise and remaining runway cannot support a reset.

Nextt was a social product intended to help friends plan future activities. Founder Mark McGuire’s postmortem describes early conversations and later returning to customer discovery, but identifies a long “middle” in which the team spent months coding without enough consumer insight ^[1].

That interval is the case.

The problem was not that the founders never cared about users. It was discontinuity. Initial research helped form the idea. Building then became the dominant activity. The product accumulated decisions faster than user evidence could challenge them.

Consumer social products contain several linked uncertainties:

• who initiates;
• why another person responds;
• whether coordination moves from an existing channel;
• how frequently the triggering situation occurs;
• what social discomfort blocks action;
• what creates a useful network at small scale; and
• whether the behavior repeats without founder prompting.

These questions cannot be settled by completing the architecture. Each needs observable user behavior in small cohorts.

A user truth ledger would have turned the “big middle” into a sequence of decision loops. For example:

Question: Will an organizer create an activity in Nextt instead of sending a group message?

Context: Existing friend group planning a real event within two weeks.

Evidence: Initiation without team prompting, invitations sent, responses received, activity completed and subsequent reuse.

Decision: Continue, narrow the use case, change the coordination mechanism or stop.

The ledger would also preserve failures. If people praised the concept but reverted to existing messaging, that behavior would outrank enthusiasm.

Nextt eventually closed. Its postmortem includes competition, growth mechanics and other product lessons ^[1]. The defensible causal finding is not that one more interview would have saved it. It is that a long build interval without an active feedback-to-decision loop allowed product commitments to accumulate while core consumer behavior remained uncertain.

## Wesabe: principles must survive contact with effort

Wesabe and Mint both addressed personal financial management. In his postmortem, Wesabe co-founder Marc Hedlund rejected simple myths about speed or financing and focused on product choices. He argued that Wesabe’s approach preserved user control and privacy but imposed more work than Mint’s easier account aggregation and categorization ^[2].

This is a subtle ignoring-users case because the choice had a principled rationale. Privacy and data ownership can be genuine user needs. The failure occurs when leadership treats its interpretation of the user’s interest as more authoritative than the observed burden users accept.

The correct feedback question was not “Do people care about privacy?” Many may say yes. It was:

Under what conditions will target users repeatedly perform the extra setup and correction work required by this privacy architecture, and does the resulting value compensate them?

That can be observed:

• onboarding completion;
• time to first useful view;
• repeated correction behavior;
• support need;
• retention by setup path;
• migration to lower-effort alternatives; and
• willingness to pay for the trade.

A value can remain strategically correct while its implementation fails. Listening does not require abandoning privacy. It may require automatic imports with user-controlled storage, a narrower high-privacy segment, assisted setup or a different promise.

Wesabe demonstrates why founders must separate the principle they protect from the design chosen to express it.

## Digg v4: delayed feedback meets an irreversible rewrite

Digg’s fourth major version followed a long engineering rewrite. A first-hand engineering account describes a roughly two-year effort, difficult launch conditions and major traffic deterioration ^[3]. Contemporaneous reporting cited sharp declines in visits following the redesign ^[4]. Later product changes were explicitly described as responses to community feedback ^[5].

It would be too simple to claim that Digg never listened. Platform competition, technical debt, publisher dynamics, moderation and the rise of other social products mattered. The failure pattern is the combination of:

• a large, long-lived rewrite;
• accumulated product changes;
• a broad migration event;
• high dependence on community behavior; and
• weak reversibility once users experienced the new system.

When a community product changes ranking, submission or social interaction, the users are part of the operating system. Technical completion is not user readiness.

The safer route is progressive evidence: shadow ranking, opt-in cohorts, side-by-side behavior, community role analysis, reversible flags and explicit stop thresholds. Metrics should include contributor concentration, submission diversity, return behavior, downstream publisher effect and migration of core groups—not just total visits.

Digg illustrates a hard truth: feedback gathered after a large release may be accurate and still arrive too late to preserve the prior network.

Use a user truth ledger for every load-bearing product decision.

## Decision header

• question and why it matters now;
• accountable decision owner;
• user segment and context;
• current assumption;
• possible actions;
• reversal threshold; and
• deadline before commitment becomes expensive.

## Evidence rows

Each row records:

• source and recruitment path;
• observed behavior;
• relevant reported language;
• sacrifice or consequence;
• current alternative;
• product and lifecycle context;
• interpretation;
• contrary interpretation; and
• link to raw material.

Do not combine rows from incompatible segments merely to produce a count.

## Contradiction box

List the strongest evidence against the current assumption. Assign someone other than the initiative owner to present it. Record why it does or does not travel to the target population.

## Decision record

Choose:

• retain the decision and state why;
• run a discriminating test;
• narrow the segment;
• change the design;
• remove a claim;
• stop the initiative; or
• escalate an unresolved value or strategy tradeoff.

## Return loop

Record what shipped or changed, the resulting behavior and which users were told. Support, sales and research teams should see whether their evidence affected action. Otherwise they learn that reporting truth has no value.

## First week: expose the filter

Select three major roadmap commitments. Trace each from decision back to raw user evidence. Note where the chain breaks, which users are absent and which negative evidence was reclassified.

Pause any irreversible commitment whose core premise has no traceable evidence.

## Weeks two to four: rebuild direct contact

Create a cross-functional listening rotation involving the executive owner, product, engineering, design, sales and support. Observe target users performing real work. Include new users, failed users, churned users and non-buyers.

Open user truth ledgers for the largest uncertainties. Precommit possible decisions before the research result arrives.

## Following month: run reversal tests

For each contradicted premise, design the smallest behavior test that distinguishes competing explanations. Use prototypes, concierge work, limited cohorts, fake-door tests with care, migration observation or pricing sacrifice as appropriate.

Publish decisions and dissent internally. Instrument the outcome.

## Following quarter: institutionalize the loop

• require evidence chains in roadmap review;
• give research a named decision interface;
• integrate support, churn and loss data;
• audit sample representation;
• preserve contrary cases;
• cap build size before behavioral proof;
• review decision throughput; and
• close loops back to users.

Repair succeeds when credible negative evidence can stop or reshape executive work. More interviews without that authority are activity.

1. Which user behaviors support the three largest product bets?
2. Who is missing from the evidence sample?
3. What do users do that contradicts what they say?
4. Which sacrifice proves the problem matters?
5. Can each roadmap claim be traced to raw evidence?
6. What is the strongest contrary case?
7. Who owns the decision after research?
8. What evidence would reverse the current commitment?
9. How long does it take for user evidence to change a roadmap decision?
10. Which initiative is too large to learn cheaply?
11. Are support, churn and loss signals visible beside feature requests?
12. Did the last major feedback cycle produce an observable user outcome?

The board should not demand that leadership “talk to more customers” as a slogan. It should inspect whether the truth loop is complete.

The final distinction:

Listening is not collecting reactions. Listening is building a system in which user reality can defeat internal narrative.