Quicken was built for households. It was meant to sit on a kitchen table and balance a checkbook. Then Intuit ran a survey to understand who was actually using it, and, as cofounder Scott Cook later told CPA Practice Advisor, “we found that half of [the users] were businesses.”
Half. Not a rounding error, not an edge segment. Half the customer base was using a personal finance program to run a company’s books, and nobody inside Intuit had designed for them.
The survey caught the anomaly. It could not explain it. That second step is where most product teams stall, and it is the reason the Quicken story is still worth studying as a lesson in contextual inquiry more than three decades later.
What the survey said, and what it couldn’t say
A survey is good at counting. It told Intuit roughly how many users were businesses. It could not tell them why a bookkeeper at a small contractor would choose a household checkbook program over the accounting packages that already existed for exactly that job.
The obvious internal reading was that these were confused customers who would eventually “graduate” to real accounting software. Real accounting, the conventional wisdom went, had to be done with what Cook called “debits and credits and journals and ledgers.” If you had started from that assumption, the logical product response was to build a better double-entry package and win those users back from the toy they were misusing.
Cook’s team did something less comfortable. “So, we finally went out and called up some of these people,” he said. What they heard flipped the assumption. In a later conversation at the Wisconsin School of Business, Cook summarized the finding in four words: “No, they hate accounting.” The small business owners were not choosing Quicken in spite of its missing ledgers. They were choosing it because of them.
That reframing produced QuickBooks in 1992, which Intuit positioned, in Cook’s words, as “the first accounting software with no accounting in it.” By his account it outsold the established competitors within two months.
Notice the sequence. The quantitative data flagged the surprise. Only direct contact with the people doing the work explained it, and the explanation was the opposite of what the experts in the building would have predicted.
Intuit turned the lucky break into a habit
One accidental discovery is a story. What makes Intuit useful to a product manager is that the company didn’t leave it as luck. It turned going to the customer into a named, repeatable practice called Follow Me Home.
Intuit’s own description of the method is blunt about what it is not. “A Follow-Me-Home is not an interview,” the company writes. You go to where the customer experiences the problem (their home for consumer products, their office for small business products), you spend 30 to 90 minutes, and you follow a fixed order: “Observe first, ask to show you second, and elicit customer knowledge with objective inquiry third.” Then you debrief with your team as soon as possible afterward, while the details are still sharp.
By 2011 Intuit had built this into a program of internal coaches who helped teams across the company get in front of customers and test ideas quickly, a model Roger Martin profiled in Harvard Business Review as The Innovation Catalysts. The point was to make observation something any team did routinely, not something a research department did on the team’s behalf.
Why watching beats asking
The research community has a name for what Intuit operationalized: contextual inquiry. Hugh Beyer and Karen Holtzblatt formalized it as the front end of their Contextual Design method, and the Nielsen Norman Group’s summary of contextual inquiry captures the core mechanism in one line: users “can easily talk about what they are doing and why when they are doing it.”
The opposite is also true. Away from the work, people summarize. Summaries drop the workarounds, the sticky notes, the spreadsheet they keep open in a second window, the step they skip because it never made sense. Those dropped details are usually where the product opportunity lives.
The method rests on four principles, and each one guards against a specific failure:
- Context. You go to the user’s real environment, not a conference room. The environment is data.
- Partnership. The user is the expert in their own work. You are the apprentice learning the craft by watching.
- Interpretation. You say what you think you are seeing, and the user corrects you. Your misreadings get caught on the spot instead of in a launch retrospective.
- Focus. You know the decision the research serves, so you know which details to chase.
This is not a new insight in product history either. In the early 1980s, anthropologist Lucy Suchman videotaped office workers and scientists struggling to use a Xerox copier fitted with an experimental help system. The machine was designed around the plan its engineers assumed people would follow. The tapes showed people improvising, misreading the machine, and recovering in ways the plan never anticipated. Her work became a foundation of the human-computer interaction field because it showed, on camera, that what people do with a product and what the designers believe they do are two different things.
The ticketing system that worked perfectly in every meeting
I learned this the expensive way. Running operations at a large telecom, I sat through months of status meetings about a new trouble ticketing workflow. Adoption numbers looked fine. Field managers reported that their teams were using it. Nobody in those meetings was lying.
Then I spent part of a shift sitting beside a technician in the operations center. He had the new system open, and he used it. He also had a paper notepad where he tracked every ticket he was actually working, because the new screens made it slow to see what he had touched in the last hour. The system was the official record. The notepad was the real one. Every technician on that floor had some version of it.
None of that would have come out in an interview. Ask him how he used the ticketing system and he would have described the system, accurately. The notepad wasn’t part of “using the system” in his mind; it was just how he got through a shift. It took about forty minutes of watching to see a gap that months of adoption reporting had hidden, and the fix (a simple “my recent tickets” view) was smaller than most of the features we had been debating.
Running your own version without a research team
You do not need Intuit’s budget to do this. You need permission to sit beside someone while they work, and the discipline to keep your mouth shut for the first half of the session. A workable version for a product team:
- Start from a surprise, not a curiosity. Intuit’s trigger was a number that didn’t fit. Look in your own data for the segment that shouldn’t be there, the feature used in a way you didn’t design for, the account that churned despite healthy usage. That anomaly is your research question, which keeps the work scoped to a real decision.
- Go to the work. For a B2B product, that means a screen share of their real setup or, better, a seat in their office. A demo environment teaches you nothing.
- Watch before you ask. Ask them to do the task they would have done anyway. Note every switch to another tool, every pause, every copy and paste. Hold your questions.
- Ask about what just happened. “I saw you open the spreadsheet there. What were you checking?” is a question about observed behavior, which is far more reliable than the hypothetical questions that quietly bias customer interviews.
- Say your interpretation out loud. “It looks like you don’t trust the total on that screen. Is that right?” Let them correct you.
- Debrief the same day. Intuit is explicit about this for a reason. Within 48 hours, the notepad becomes “some users have workarounds.”
If you already run regular customer conversations as part of a continuous discovery cadence, swap one interview a month for an observation session. The difference in what you learn tends to make the case for doing it more often.
The lesson isn’t “talk to customers”
Every product team already believes it should talk to customers. The Quicken story makes a sharper point. Intuit’s experts had a confident theory about what small businesses needed, and the theory was wrong in a specific, profitable direction. A survey revealed that something odd was happening. Only going to the people doing the work revealed what it meant.
When your data shows you something that doesn’t fit, the instinct is to explain it from your desk. Cook’s advice was the opposite: savor the surprise, then go find out what it means.