Most product teams treat discovery as a blank-page ritual.
- Kickoff.
- Interviews.
- A journey map that looks expensive and says almost nothing.
- Then a backlog that still starts from what the loudest stakeholder imagined last quarter.
The ritual feels rigorous and the output is still a guess. That is not a research problem. It is a starting-point problem. Audience intelligence for product discovery starts somewhere else: with how people already behave. People do not arrive at your product as an average user. They arrive with habits, resistances, and decision shortcuts that already exist in the wild. Ignore those patterns and you spend the first six weeks rediscovering what a good audience intelligence practice already knows.
Psychohistory.
Audience intelligence without the science fiction.
Audience intelligence, done seriously, is the practice of understanding how real people think, what drives their decisions, and why they behave the way they do, with enough precision that you stop designing for an imagined midpoint. Asimov’s psychohistory predicted the behavior of whole populations while saying nothing certain about any one person. Audience intelligence works on a similar principle, minus the science fiction. We apply this behavioral data science to product, leadership, and learning. It gives you a lens that changes what you build and how you advise.
We came to this work from the other side of the industry: audience intelligence for large consumer brands, the pattern recognition that once powered hyper-personalized media at scale. That lineage does not mean we paste a media model onto a software problem. It means we refuse to pretend every engagement starts at zero. People have already shown us how they adopt, stall, abandon, and decide. The library is there. Discovery should map your users or team and their needs onto those patterns.
Start from the patterns that already exist … then discover what is actually different.
What “pattern-first” audience intelligence for product discovery actually changes
Pattern-first discovery flips the usual sequence. You do not wander until a theme appears. You arrive with a living base of how audiences move and the behavior patterns already understood, then run short, targeted research to map your specific people and constraints onto those patterns. The result is not a thicker slide deck. It is a sharper decision: what to build, what to cut, what to say, and who to coach.
This is uncomfortable for teams that equate research hours with rigor. Hours are not the point. Signal is. A short discovery that starts from a real library can outperform a long one that starts from a sticky-note wall, because the first is using existing research to test a hypothesis about people instead of hoping one appears.
Cohorts beat personas
Personas are often fiction with a job title: one imaginary adult who “values simplicity” and “is busy.” Cohorts are different. A cohort is a cluster of people who already share a behavioral pattern, such as how they adopt a tool, when they resist a change, or what they abandon after week two. Grouping people this way changes the question from “what does the user want?” to “which pattern are we serving, and which one are we willing to ignore?” That is a leadership question as much as a research question.
It also means treating the library as a lens, not a report. A report gets filed. A lens gets used. If your discovery artifacts cannot change a priority, a prototype, or a coaching conversation, they were theater.
See how Pattern-First Discovery works
It sits underneath build, advise, coaching, and training not beside them.
A real example: the support team that left in a week
A local sports training organization lost its entire three-person customer service team in a single week, right as its summer high season approached. That team answered the phones, replied to customer emails, captured feedback, did basic lookups, and opened tickets for other teams to resolve.
The original plan was the familiar one: build a solution that covers every possible support scenario, then route each request to the right team. It sounds thorough. It was also a guess about two things nobody had examined yet: who would live with this system, and what customers actually asked for.
So we started with history instead of a blank page. We studied past tickets and the teams that had been resolving them. Two patterns turned up that we already knew.
The first was the people. The teams inheriting this work were not customer service teams. They were busy teams elsewhere in the company who now had to handle it on top of everything else. Too busy to care, but they have to do it. That told us how the product should work before we designed a single screen: no new place to look. Notifications had to arrive inside the workflows they already used.
The second was the customers. The most common ticket types followed predictable patterns in how customers asked and what they expected back. Because we had to release something quickly, we mapped those patterns to intelligent AI responses for the common cases rather than trying to cover every scenario.
Beyond basic functionality, we tested two things. First, that the agent gave correct information in a tone that matched the client’s brand voice, over both email and phone calls. Second, when it should escalate to a human and when it could resolve a request itself. We set a deliberately conservative limit on self-resolution, one we expected to move as the solution improved. People stayed in charge of what the agent knew and where it had to hand off.
Then the pattern broke, in the best way. We expected the team to spend real time validating the agent’s work and reviewing escalations in the dashboard. After a few days of testing, they trusted it instead. They checked in periodically and mostly opened the dashboard to update the knowledge base.
We believed the people, not the plan. We cut the dashboard down to the few metrics and items that mattered, moved everything else to a secondary page, and let users spend less time in the interface we built for them.
What was meant to be an interim solution until the team was rebuilt became a standard part of how the company operates, and they updated their workflows around it. With a lot of hard work on their side, they had their most successful summer yet.
Notice what the library did and did not do. It told us who we were designing for and what they would tolerate, which shaped the first version before we ran a single interview. It did not predict how quickly trust would form. That exception became the redesign. This is what audience intelligence for product discovery buys you: the surprise arrives early, while it is still cheap to act on.
Targeted product discovery, not more interviews
Once the library is on the table, discovery gets smaller and meaner. You are not collecting stories for their own sake. You are looking for the places your context breaks the pattern: a regulatory constraint, a buying committee that does not match the consumer model, a workforce that will not touch a tool unless a peer already has, or a team that trusts a tool faster than anyone predicted. Those exceptions are the work. Everything else is confirmation, and confirmation should be fast.
None of this replaces talking to people. It changes what you ask. Instead of “walk me through your day,” you ask “when you last ignored a new tool, what made it easy to ignore?” Instead of “what would delight you,” you ask “what would have to be true for this to become a habit?” Those questions assume people already have a pattern. They usually do.
Instead of “walk me through your day,” you ask “when you last ignored a new tool, what made it easy to ignore?”
Instead of “what would delight you,” you ask “what would have to be true for this to become a habit?”
Where this shows up in the work
On a build, pattern-first discovery decides the first prototype. Not the tenth. The first. On fractional product work, it moves roadmap items that serve a real behavioral pattern up and the ones that serve an imagined average down. In coaching and training, it is the same lens, taught: it all comes down to understanding the psychology and motivation behind decisions and preferences.
A note on data, and the people it is about
Pattern-first is not a license to treat people as rows. In fact it is the opposite. The library is a starting map, not a verdict. Some of the worst product decisions we have seen came from a team that believed their segment labels harder than the humans in front of them. When a person breaks the pattern, believe the person. Update the library. That is how the practice stays honest instead of becoming a more sophisticated form of stereotype.
It is also why we keep a human in the loop when this work touches media, product, or management. Models can cluster. They cannot take responsibility for a choice that will land on someone’s week. If your organization wants audience intelligence as an autopilot, we are the wrong studio. If you want audience intelligence for product discovery that stops the guessing and keeps you accountable, we should talk.
Bring us a decision you’re already stuck on.
Tell us the call you can’t make. We’ll tell you which patterns we’d start from, what we’d still need to learn, and how we would approach coming to a decision.
