Concepts / Role of Echo in a Startup

Role of Echo in a Startup

An Echo is a domain rebel: someone who came from the domain, understands it deeply, and has concluded that the current way of doing things is inadequate.

  • Programming

Why the Most Experienced Expert Can Mislead

When a small team starts building an AI product for an unfamiliar industry, a natural instinct is to find the most experienced person in that industry and ask what they think. The reasoning seems sound: the person who has done the work longest should be able to say whether the new system is needed. This instinct rests on a hidden assumption, that a practitioner who knows a field well will also see its problems clearly. The source points out that this assumption often fails. The most experienced person is frequently the least likely to say that the way things are done is broken, because they have built their working life around that way of doing things.

What do you think happens?

Two people have years of experience in the same domain. One is content with how the domain currently operates. The other understands the domain just as deeply but has concluded that the current approach is inadequate. Which of them is more useful when you are testing whether your new AI system solves a real problem?

  • The contented expert, because their experience is larger

  • The rebel, because they can say specifically what is broken and what must change

  • Both are equally useful, since they have the same depth of knowledge

Reveal answer
Answer:

The rebel, the Echo, is more useful. Both have the same depth of domain knowledge, but the rebel can say exactly where the current approach fails, why earlier attempts failed, and what would need to change for a new attempt to succeed.

Experience alone does not tell you how a person will judge the system you want to build. What matters is how that person relates to the current state of the domain. The source treats the rebel's feedback as far more valuable, even though such people are harder to find.

Two Profiles Side by Side

The source draws a sharp line between the Echo and what it calls a satisfied practitioner. A satisfied practitioner regards the current approach as fine and may call the system you are building unnecessary. Their skills, habits and sense of competence are tied to how things are done today, so they have a stake in the status quo. The Echo, by contrast, understands the domain deeply and has concluded that the current way of handling it is inadequate. Both profiles can be deeply experienced. The difference lies in how each one judges the current state of the domain.

Deep domainexperienceDeep domainunderstandingContent with statusquoRejects status quoCalls new systemunnecessarySpecific feedback tobuild againstleads toproducescombined withproduces
Which two traits does an Echo have that a satisfied practitioner lacks, and how do the two profiles differ side by side?

Read the two columns as a contrast in judgment. Both columns start from real domain experience. The satisfied practitioner stops at approval of the current approach, which leads them to dismiss the new system. The Echo carries the same depth into a critical judgment, which produces feedback you can act on.

Three Traits That Define an Echo

Definition

An Echo is a domain rebel: someone who came from the domain, understands it deeply, and has concluded that the current way of doing things is inadequate.

The source describes the Echo through a combination of three traits rather than a single credential. Each trait is listed below, and the source insists that the combination is what matters. Any one trait on its own does not make an Echo.

  • Origin: the Echo came from the domain.
  • Depth: the Echo understands the domain deeply.
  • Judgment: the Echo has concluded that the way the domain is currently handled is inadequate.

Following Feedback from Each Profile

The clearest way to see the difference is to follow the same moment through two different reviewers. The scenario below is an invented illustration, not a case from the source. It shows how the feedback each profile produces changes what the engineering team can do next.

Worked example

Testing a draft AI tool with two reviewers

A small AI startup shows a draft tool to two experienced people from the same industry. Reviewer A is a satisfied practitioner. Reviewer B is an Echo. The team wants to know which feedback it can build against.

  1. 1
    Reviewer A responds

    Reviewer A says the existing process already works and the tool is not needed. The feedback gives the team no failure to address and no condition to change.

  2. 2
    Reviewer B responds

    Reviewer B says the current process fails at a specific step, names the earlier attempts that did not fix it, and describes what would have to change before a new tool could succeed.

  3. 3
    Compare what the team can do

    Reviewer A's answer closes the question without giving direction. Reviewer B's answer gives three things to build against: a failure, its cause, and a condition for success.

Result

The Echo's feedback is the one the engineers can turn into requirements. The satisfied practitioner's feedback, though sincere, does not tell the team what to build.

Checking Your Reasoning on an Echo

MEDIUM

A colleague says, I have worked in this industry for twenty years, so I can tell you whether our AI system is needed. Using the two traits that separate an Echo from a satisfied practitioner, explain why years of experience alone may not answer that question, and say what you would ask this person to find out whether they are an Echo.

Hints
  • Think about how the colleague relates to the current state of the domain, not just how long they have worked in it.
  • An Echo needs both deep understanding and a judgment that the current approach is inadequate. Ask questions that test each of these.

The Job an Echo Does in a Small AI Startup

The source moves from the individual profile to the startup that needs one. A small AI startup without an Echo team should bring in a customer-side rebel early. This person needs two things: the domain credibility to be taken seriously by people on the customer side, and the institutional skepticism to question how the customer's work is being done. Their role is to translate between the startup's engineering team and the customer's reality. Without that translation, the engineers may build against an idealized version of the customer's work rather than what the customer actually faces.

  1. 1
    Hold domain credibility so that people on the customer side take the Echo seriously.
  2. 2
    Question how the customer's work is currently done, rather than accepting it as fine.
  3. 3
    Relay what is actually broken and what conditions must change to the engineering team.
  4. 4
    Check the engineers' work against the customer's real situation so the build does not drift toward an idealized version.

Why Presence Matters More Than the Arrangement

The source is explicit that the role of the Echo can be filled in more than one way. The rebel may be paid by the startup, may serve as an advisor, or may already work inside the customer organization and have been thinking about the problem for years. The source adds that the structure of the arrangement does not matter. What matters is that the rebel is present. A contract, a salary, or an advisory agreement is a means of bringing the person in. The value comes from what the person sees and says about the domain, which is why the arrangement matters less than their presence.

Key point

The arrangement that brings an Echo in is a practical choice. The Echo's presence is the thing that supplies the specific, critical feedback the startup needs.

Mistakes Teams Make When Choosing Reviewers

  • Common mistake

    Treating the most experienced practitioner as the ideal source of guidance for a new system.

    Why it fails

    Experience alone does not show whether a person sees the domain's problems. The source notes that the most experienced person is often the least likely to say the current way of working is broken.

    Do this instead

    Ask how the person relates to the current state of the domain, and look for a judgment that the current approach is inadequate.

  • Common mistake

    Assuming that rejection of the status quo is enough to make someone an Echo.

    Why it fails

    The source insists the combination of traits matters. Rejection without deep understanding does not give you specific, usable feedback.

    Do this instead

    Look for both deep domain understanding and a judgment that the current approach is inadequate.

  • Common mistake

    Choosing an Echo only once a particular contract structure is in place.

    Why it fails

    The source says the structure of the arrangement does not matter. What matters is that the rebel is present.

    Do this instead

    Focus first on finding the right person, then decide which arrangement fits.

Key Takeaways for Working with an Echo

At a glance

  • An Echo is a domain rebel: someone who came from the domain, understands it deeply, and has concluded that the current way of doing things is inadequate.
  • A satisfied practitioner regards the current approach as fine and may call the system you are building unnecessary, so their experience alone is a weak signal of need.
  • An Echo's deep understanding combined with a rejection of the status quo lets them say what is broken, why earlier attempts failed, and what must change for a new attempt to succeed.
  • A small AI startup without an Echo team should bring in a customer-side rebel early to translate between engineering and the customer's reality.
  • The arrangement that brings an Echo in can take many forms, and what matters most is that the rebel is present.