Looking Through the Wrong End of the Telescope

This is the last post in the series. We’ve covered dashboards that don’t decide, programs missing their doing wing, flying on a single dial, too few dots to trust, and correlation mistaken for causation. This week, the piece that ties them together.

The wrong end of the telescope

Look through the wrong end of a telescope and everything shrinks. The mountain that should fill your view becomes a distant smudge. It’s a good trick for making something feel further away and smaller than it really is. It’s a terrible way to actually get closer to it.

Most feedback software is sold, and built, through the wrong end of the telescope. Go and look at how the major platforms describe themselves: Qualtrics leads with “Listen, Understand, Act” Medallia talks about helping you “collect, analyze, and act” on feedback. GetFeedback, under Momentive/Symphony Technology Group, uses much the same three-step shape: listen, bring the customer into focus, then act on the insight. SurveyVista has told a version of this story too. It’s not a bad framework. It’s just built starting from the wrong end.

Collect-first is backwards

Notice the order. Every one of these frameworks starts with the process of collection. Go out, gather feedback, then figure out what it means, then, eventually, work out what to do about it. Action is the last step, arrived at only after the data already exists. It’s the same instinct as pointing a telescope at a mountain range and asking what you can see, rather than deciding which peak you’re trying to climb and then working out what you need to see to get up it safely.

The consequence is a survey built to be comprehensive rather than a survey built to be decisive. Ask about everything, because you don’t yet know what you’ll need to act on. Cover satisfaction, loyalty, product, service, price, communication, and a free-text box for anything missed, because narrowing the questions down would mean admitting you don’t actually know what decision you’re trying to inform. The result is exactly what customers have started to resist: long, generic, low-relevance surveys that ask a lot and promise nothing in return, because nothing was designed to happen with the answers before the survey went out.

Design the action, then work backwards

The alternative (and what we are building at SurveyVista) is to turn the telescope around before you start collecting anything.

• Start with what you want to achieve. Not “understand the customer better” but a real, specific outcome. Fewer customers churning after onboarding. Faster resolution of the issue driving your highest-cost support tickets. Higher attach rate on a particular product line. If you can’t name the outcome, you’re not ready to design the survey yet.
• Decide how you’ll achieve it. What decision has to be made, by whom, and what would trigger it? A poor product setup should trigger a product change, and perhaps an interim guidance video. Who owns that intervention, and at what threshold do they act? Naming this before you’ve collected a single response is uncomfortable. Yes, it forces an honest answer about whether anyone is actually ready to act, but it’s far better to find that out now than after the data arrives.
• Work out what data would reliably justify and trigger that decision. Only now do you design the questions and required data sets: specific enough to route to the right owner, timed to catch the moment that matters, and structured so a genuine answer is unambiguous about what should happen next.

This produces a smaller, sharper survey almost by accident. When you know exactly what decision a question needs to inform, most of the questions companies ask “just in case” fall away, because “just in case” was never connected to an action anyone was planning to take.

Collect, Understand, Act: right sequence, wrong starting point

To be fair to the vendors (especially us), “collect, understand, act” isn’t a bad description of what needs to happen once a survey goes out. The problem is that the framework starts the clock at collection, when the real design work needs to happen before a single question is written. By the time you’re “understanding” what you’ve collected, you’ve already locked in whether the data can support the action you’ll eventually want to take. Understanding can’t retrieve context you never captured, and it can’t invent an owner for an action nobody assigned.

Flip it, and the framework becomes: decide the outcome, then design what decision would achieve it, then design what you’d need to Understand, then Collect precisely that. The words are the same three ideas, with one added at the front: the outcome nobody names until it’s too late. The sequence, and the discipline it forces, are completely different.

What this looks like in practice

A team designing backwards doesn’t start with “let’s measure the customer experience.” It starts with an outcome: “we want to reduce churn in the first ninety days.” That outcome implies a decision someone has to actually take, with an owner (customer service, product, or both), a trigger (a specific score, event, or comment pattern), and a timeframe (feedback collected early enough in the ninety days to act before the customer has already decided to leave). Only once those things are agreed does the survey get built — built to serve that action specifically, not to serve every possible future question someone might ask of the data.

The test of whether you’ve done this properly is simple. Before you launch, you should be able to say exactly what happens for every plausible answer a customer could give. If you can’t, you haven’t designed an action. You’ve designed a data collection exercise and are hoping the action reveals itself afterward. It rarely does.

This is uncomfortable for a reason: it exposes teams who aren’t actually ready to act. If nobody can answer “what happens when a customer says X” before the survey goes live, the survey isn’t the problem to fix first. The readiness to act is. Better to discover that gap at the design stage, when it costs a difficult conversation, than three months later, when it costs a stack of unactioned data and a customer who’s already decided your listening was theatre.

David Jackson put it to me more bluntly than I’ve managed to here: nobody buys a feedback platform to collect feedback. They buy it to change something. If you can’t say what changes, you don’t need a survey yet, you need a decision.

Which end are you looking through?

If your survey exists because you thought you should be listening, but nobody could tell you in advance what would happen with a low score before you started collecting them, you’re looking through the wrong end. The mountain looks small and distant – manageable, someone’s problem sometime in the future.

Turn the telescope around. Decide what you’re climbing, work out what you need to see to do it, and only then start surveying the view. Everything gets closer, and a lot more climbable, once you’re looking through the right end.

Where this series leaves us

Six posts, six ways the same underlying problem shows up: dashboards mistaken for deliverables, programs with only one working wing, single scores asked to fly the whole plane, feedback treated as a finished picture instead of a handful of dots, correlations mistaken for causes, and surveys designed before anyone agreed what they were for.

Every one of these is a design problem, not a survey problem. Surveys aren’t dead. But a feedback program that hasn’t turned the telescope around was never going to drive results for the business, regardless of how good the survey questions were.

We’ve spent the last several months building what turning the telescope around actually looks like in practice, inside Salesforce, without a second data store or a second vendor. Follow SurveyVista on LinkedIn to learn more soon.

Frequently Asked Questions

1. What’s wrong with the “collect, understand, act” framework most feedback platforms use?
   The sequence itself isn’t wrong, but starting the design process at collection means the survey is built before anyone has agreed what outcome it needs to drive, or what action would actually get there. By the time a team gets to “understanding” the data, they’ve already locked in whether it can support the action they eventually want to take.
2. How should a company design a customer feedback program differently?
   Start by naming the specific outcome the program needs to drive, then decide what action and owner would need to exist to achieve it, and only then design the survey questions and data needed to trigger that action — rather than collecting broadly and hoping the right action reveals itself afterward.
3. What’s the test for whether a feedback program is designed to drive action?
   Before launch, a team should be able to state exactly what happens for every plausible customer response. If they can’t, the program hasn’t designed an action — it’s designed as a data collection exercise, and the action is unlikely to materialize on its own once the data arrives.