The Fundamental Research Question

Product teams must answer one question about their users: "what are they doing right now?"
The Fundamental Research Question

There's one question whose answer always contains the kind of information that drives good product and design decisions: What are they doing right now?

It points to the strongest signal we can get for product work. The answer to this question — a characterization of actual, current behavior — deserves to be pursued at a level of effort that corresponds with the size of risk and opportunity at hand. It is the source and the key for predicting and creating How they are going to do it next.

All good product and design decisions start with and ultimately depend on answering a context-specific version of "What are they doing right now?" This distillation of user research is potent already, and it gains real power when it's applied with increasing nuance and specificity over time.

A focusing lens

In the unspecific form, the question offers productive constraints for making sense of what's important. It highlights the kinds of information that will focus our work and drive meaningful product evolution:

  • What
    [activities, interactions, steps, sequences, and behaviors we’re targeting]
  • are they
    [users, roles, profiles, and customer segments we're serving]
  • doing
    [effort, progress, workflows, mindsets, and larger needs we're supporting]
  • right now?
    [situations, time scales, frequencies, durations, and contexts we're solving for]

Applying the question to a specific product context snaps our attention to the reality of users' actions as concrete areas of work that we can choose to inspect, explore, understand, and improve. This is the reality we seek to change and improve with every choice we make. The question also serves as a quick means of assessing a team's existing understanding: how well can they answer it given the users, work, and contexts in their scope?

More than a matter of language

With the question as our frame, we simplify and demystify the black box of "research." One great trap that even experienced researchers fall into is invoking research itself as a useful end, instead of beginning the conversation by suggesting the kind of information that will inform an important decision or help mitigate the risk at hand. It is both a matter of new language and an extremely important means of driving value in product and design research.

Imagine a B2B startup team seeing a troubling increase in their churn rate. They're advised to "do research" to address it, which is neither helpful nor instructive. The team doesn't really want "research," and that's not what they need: they need to be informed so they can make good choices, or, at the least, know enough to see where the wrong decisions lie.

Instead, we can and should replace "research" with a form of the fundamental question. Imagine that the team with a retention problem is advised to "find a reasonable set of customers who stopped using the product and figure out what they're doing right now." This is a concrete and achievable effort: it elevates the conversation to suggest a concrete kind of information, allows for discussion of its suitability to the problem at hand, and already points to potential follow-up steps, e.g., compare the churned users' current activities with those of users who are strongly engaged. (The team in question surfaced clear divisions in customer goals and mindset: some of which the product served quite well, some of which had never been considered, and the team was able to address.)

The churn example may feel trivial; I believe there is surprising power here because of and despite the obvious simplicity in "what are they doing right now?" Let's look a bit further...

All good questions are isomorphic to the fundamental

To be effective in our choices, we have the right information to address our goals, risks, and questions at hand. And this means figuring out what we need to know to move forward. I have found in recent engagements that research capability itself is not always the largest value add — that can be in helping the team figure out what to learn so they can move forward.

It's a sensibility that any experienced and perceptive researcher (or designer, or product manager) brings to product work. They take into account the current situation — the product or concept as it exists now; the team's goals, risks, and trajectory; and their existing insights and bases for decision-making — to figure out where the real questions lie, and what is most important to learn. (You'll see they are effectively asking our core question, pointed at the team itself.)

Here's the shortcut: we can sidestep so much of this figuring-out-what-we-need-to-figure-out by recognizing the need to maintain a well-scoped and living answer to one fundamental question: "What are they doing right now?".

All useful research, all of the kind that drives product and design work, effectively answers some form of the fundamental question. And, more importantly, it works in both directions. Whatever the team's current questions, risks, and problems are, I claim they can be addressed by adapting the fundamental question to the team's specific problem context.

Here are some rough-sketch scenarios. They carry little in the way of actual specifics that give the question its power, but show directionality: all of the important things to see are framed by the question.

  • Opportunities reported to customer support? We need to find the relevant class of users and their existing workflows, and any subsequent workarounds, to isolate the extent of the problem. We reach out by email to ask about the current project work and what they were doing when they encountered the problem. The weight of our response is dictated by its importance and impact on the larger work that they're doing right now.
  • Churn? We need to find people who left and figure out what they're doing right now, so we can compare it to people who are still strong users of the product. We look at the models, mindsets, methods, and contexts that drive them, and find the fundamental differences that will predict behavior. (User segmentation is a similar class of problem — but they're all still on-platform.)
  • Usability problems? We need to take a live or mocked-up version of the product and watch real people as they actually use it. We ask the question in an artificial scenario, and the closer we are to the "right now," the better we can understand their rationale and ask questions of how they interpret different design choices.
  • New product innovation? We have a hunch, and we need to co-evolve our definition of "they" along with what they're "doing" until we can chart out a useful picture of the workflows-and-experiences we're targeting, and define repeatable characteristics of the users we expect to serve. This is an ongoing, ever-focusing, and sometimes wildly-shifting application of the fundamental question.
  • MVP or Beta launch? We need to get the product into the hands of a small subset of users who will give us a special kind of access to their action, and the appropriate consent to track 'what they are doing right now' across a number of potential channels: product analytics dashboards, cadenced check-in interviews, email feedback prompts, priority customer support agreements, and so on.

In each scenario, the question that drives useful decisions is isomorphic to the fundamental: a fractal offshoot of the master question adapted down into the relevant specifics.

We start with "What are they doing right now?," and once the door is open, its core companions "How does that work?" and "Why do they do it that way?" and "What did you do the last time that happened?" also perform heavy lifting. So long as we maintain focus on concrete behavior (a what), real people (a they), workflows and effort (a doing), in some time-bound context (a right now)... we'll be moving in the right direction.

It's tempting to look past existing behavior and jump straight ahead to the future. We must recognize that the future-hypothetical can serve as a destination or aspiration, but can never serve as a rationale for decisions. Rationale requires a basis in concrete and actually-existing data: in the present.

Current conditions: start in the present

Our goal is a humane and effective product, one that real and actual people are going to use. They won't do so in a vacuum. People have existing and specific behaviors in context, some of which will be co-opted, replaced, substituted, improved, eliminated, or transferred — between something else and our product, or a prior version and a new version of our offering.

The fundamental research question is "what are they doing right now?" The 'right now' is crucial for informing decisions that depend on if, and how, those changes in behavior will happen. Product work is constantly looking to create state changes, not hypothetical futures in the formless void, and we can only talk about the 'to' if we understand the 'from.' In our work, the 'from' is always whatever is happening right now.

So we seek to answer the fundamental question first in the present. We look backward and ask for specific details about the past to understand time cycles and trajectories. We synthesize our understanding of existing behavior and past perspectives to make useful judgments about future behavior.

It's always tempting to ask questions about the future, and always surprising how useless those answers prove to be when we get there. Few people are any good at predicting their future behavior, and the same when it comes to accurately generalizing about their past — think "how often do you go to the gym?" vs. "how many times did you go last week?" The strong signal we have available is real-and-current-behavior, observed, or recounted in as much recent detail as possible.

Working with product teams, I like to bring the question down to the very specific: "Can you tell me about one actual customer and what they're doing right now? Why is [thing we're building] good for them?" We'll save the discussion of qualitative sample size for the future, and for now, just ask: if a team is moving forward without confidence that their work will serve at least one real-world actual user and why, on what basis can we trust that they will successfully serve hundreds, thousands, or millions of them?

As designers, technologists, and product people, we are — for better and for worse — creating bits and pieces of the future. That future gets instantiated each time a new user participates in our vision and version of the future. We try to envision for ourselves and convince others how the current behaviors of today will translate into the future capabilities we're building and launching.

The driver of that change, the place where users' motivations are uncovered, where effort is placed, where latent needs and unsolved problems and new opportunities lie, is present behavior. "What are they doing right now?" points the way.

A signpost on the path

If you want to make good decisions, you have to know what’s going on. Assume this to be true, and, given our work — as teams of people making software products — there's a very consistent kind of human-oriented “what’s going on” that's important for us.

We try to create how they are going to do it next by evolving new paths of action that open from “what are they doing right now?”

At least, it's how I currently understand the work. I wonder what might have happened if, fifteen years ago, my professors of Human-Computer Interaction had let me in on this overarching secret — "research is just learning what people are doing right now and framing it so your engineers, designers, and product people can make smart choices about what's coming next" — before delving into bedeviling depth of GOMS models, contextual inquiry procedures, Fitts' law, and task sequence models.

I like to imagine that it would have saved me the first five years of professional thrashing (e.g., opening episode in The Researcher's Journey) while trying to figure out how product development works. Then again, perhaps not. Even a shortcut to framing useful product insights is just one more marker that can help point us to good choices: it won't do the work on its own.

No good piece of informedness, research, or insights work will survive if the human element of our work is overlooked. Tangible and concrete insights about what they are doing right now may not fit existing narratives so neatly. Good insights collected by a disjointed team may go the way of trees falling in an empty wood: did they even make a sound? Informed pursuit of the fundamental question may challenge organizational hierarchies, internal biases, lines of ownership, or even — heaven forbid — team funding and headcount.

These aren't reasons to avoid being well-informed: they're reminders that research alone won't save us. Depending on the team context, being well-informed may not be the largest obstacle to good decisions. Regardless, a reasonable view of the current-state reality, of what they are doing right now, is a necessary table stake for effective, future-facing decisions.

So start with the fundamental research question, frame the research right, and stay close to the useful truth on the ground. Then we can spend our time on what really matters: strategy, execution, and internal politics.


This is part of an ongoing exploration into research as it co-evolves with product practices and re-integrates into the organization.

For weekly thoughts on the nexus of products-organizations-process-strategy, and updates on larger resources like this, consider joining my newsletter.

About the author
Dave Hora

Dave Hora

Research consultant and product strategist. || Understand what is being considered. Focus on user needs. Visualize the challenge at hand.

Dave's Research Co.

shaping useful product lines — consulting, writing, advising

Dave's Research Co.

Great! You’ve successfully signed up.

Welcome back! You've successfully signed in.

You've successfully subscribed to Dave's Research Co..

Success! Check your email for magic link to sign-in.

Success! Your billing info has been updated.

Your billing was not updated.