It was Monday morning when my VP stopped by with a request from Mark Zuckerberg. “Mark wants to know what makes an ad feel creepy and why people think their phones are listening to them.”
I got excited. These were rich questions. I started mentally mapping the research directions, the methods, the participants I’d want to recruit. Then I asked when he needed it.
Thursday.
New plan. Forget new research. What do we already know?
I put together a Google Doc with his questions, my initial thinking, and a call to action: share every piece of existing research you have that touches these questions, inside or outside the company. I sent it broadly across research, product, and marketing, and told people to keep passing it along.
Within 24 hours I had more research than I expected. It still needed synthesis, but the insights were there, interesting, useful, and defensible. That bought me time to pitch follow-on primary research to go deeper.
For much of my career, even as a research leader, I was the one who took whatever timeline I was handed and figured out how to make it work. I felt accomplished when I could pull off solid research under pressure.
But over time I learned that being responsive wasn’t enough. Responsiveness made me reliable, but it kept me answering other people’s questions on other people’s timelines. The user researchers whose work actually shaped decisions weren’t just fast. They did three things well: they framed the real question, timed the work to the decision, and made sure the answer was absorbed before the decision got made.
Which Researcher Are You?
Avery knows speed matters. When her team asks for research on a short timeline, she delivers, working long days, cutting corners when she has to, getting the results just in time. Her stakeholders are pleased, but they may be missing the insights the business context actually called for.
Andrea operates differently. She’s learned that each product team runs on its own development timeline, and she’s mapped hers accordingly. She starts her research two to four weeks before decisions get made, not because she’s slow, but because that lead time is what makes the rest possible. Before she designs anything, she digs into the real question beneath the request, the decision her stakeholders are actually trying to make and the business context driving it, so her study speaks to what is being decided rather than what was literally asked. And that lead time lets the insight get absorbed, questioned, and built on well before the decision locks.
In practice, Avery’s work gets heard. Andrea’s work gets used.
The difference wasn’t research skill. It was three things: timing, framing, and socialization. Knowing when the work was needed, what the real question was, and making sure the insight landed before the decision locked.
Learn the Rhythm Before You Design the Study
The Mark story didn’t make me Andrea overnight. If anything, it reinforced my identity as someone who could deliver under pressure, like Avery. It took years of watching research land as “interesting” but not translate into a decision before I started asking a different question: not “can we get this done in time?” but “are we getting this done at the right time?”
That’s what I mean by rhythm. An actual map of when and how decisions get made.
Every product organization has a rhythm, even the chaotic ones, even the five-person startups without a roadmap at all. On some teams, the roadmap gets rewritten frequently and nothing feels locked. But the rhythm is still there. Depending on the org, it might be a fundraising deadline, a founder’s gut-check meeting, a board meeting, or an earnings call. Or it might be more familiar markers: sprints ending, roadmaps locking, quarterly business reviews, leadership offsites, budget season. These are the moments when your research can shape a decision or miss it entirely. If you don’t know when they happen, your research will arrive after the decisions are already made.
How to Map the Rhythm When You’re New
This is hardest when you’ve just joined a team or company. The calendar looks one way. Reality is usually different.
Start by asking about two levels in your first conversations with Product Managers (PMs), designers, engineers, and leads: the day-to-day and the bigger bets. For the day-to-day, ask: “Walk me through how a typical feature goes from idea to shipped.” For the bigger bets, ask: “When does this team set direction or decide what to prioritize, and who’s in the room?” Listen for when research tends to enter each process, and more importantly, when it tends to be too late. Most people will tell you, if you ask directly.
From there, learn by doing. You don’t have to watch a full cycle before you act, and in a fast-moving org, showing some action beats waiting for a full cycle to play out. Treat it as research on the process: the conversations tell you the official version, but sitting in on a planning meeting, a roadmap review, or a sprint kickoff shows you how it actually works, who has influence, what kind of evidence lands, and when the room has already moved on.
At the same time, start small. If the team has a planning meeting next week, pull together the top three insights that are relevant and work them into your 1:1s and group chats beforehand. You’re not running the whole play yet, just testing whether you can get material into the conversation before the decision instead of after, and learning from how the room responds.
Over time you’ll develop a feel for it. But feel isn’t enough on its own. The researchers I most admired kept a simple running note: upcoming decisions, the teams making them, and the deadlines that actually mattered. Not the official deadlines. The real ones.
Getting Ahead of the Ask
Once you understand the rhythm, the next shift is from reactive to anticipatory. This is where Andrea lives. She’s not waiting to be asked. She’s already three weeks into a study that her team doesn’t know they need yet.
It starts with a simple habit: stay close enough to your PMs, designers, engineers, and data scientists, so that you hear what’s taking shape before it’s official. How you do that depends on your team’s culture. Some researchers have standing check-ins. Others stay connected through Slack or just by showing up to team meetings regularly. Ask questions like: “Where do you see this product in six months?” or “How do you hope people will use it?”
It also means looking beyond your immediate team: competitor launches, earnings calls if your company has them, industry news, company and team all-hands and Q&As. These are where you learn what leadership is actually worried about, months before it turns into a research request.
Once you know a decision is coming, work backwards from it. If it needs to be made in six weeks, and you need two weeks for socialization, you have four weeks to do the work. That window determines everything: your method, your sample size, your level of rigor. Sometimes you can shrink the socialization window by bringing your team into the first few research sessions, so they’re learning in real time.
Ask the Right Question, Not Just the One You Were Handed
Timing gets your research in front of the decision, but framing determines whether it’s the research that decision actually needed. The fastest way to the real question is to ask it outright: “What decision are you trying to make, and by when?” If the stakeholder asks for a specific method, probe on what decision they’re trying to make. If they say they want to learn about a topic, understand why. Understanding the business context around the ask is what lets you design a study that speaks to what’s being decided rather than what was literally asked.
It’s also how you right-size the work. Not every decision needs a gold standard study. A low-stakes UI tweak might need a quick usability study. A full product redesign might need a mixed-methods study with a representative sample. The calibration comes down to two questions: how easily can this be undone if we’re wrong, and how many people does it affect? Changing the color of a button is cheap to reverse and affects almost no one materially. A redesign is expensive to unwind and touches everyone. The skill is matching your rigor to those stakes, not defaulting to the most thorough approach you know.
Before launching anything new, look at what already exists. This was the instinct that saved me on the Monday-to-Thursday Mark deadline, and it holds in less pressured moments too. Past research is underused in most organizations. A study from two years ago may answer sixty percent of the current question, freeing you to focus new work on the forty percent that’s genuinely unknown. It also keeps the team moving: if they need to start building, they can act on what you already know while you dig into the rest.
And when the timeline handed to you is genuinely impossible, say so clearly and offer a scoped alternative. Not as a negotiation tactic. As a matter of professional judgment. “We can’t do this well in three days, but here’s what we can do, and here’s what we’d learn from it.” Teams respect that more than a rushed deliverable that quietly misses the point, or worse, faulty findings that lead to the wrong outcome.
Socialize, Don’t Just Deliver
You’ve timed the work and framed the real question. There’s still one way to lose: hand the finding over and hope someone acts on it. The researchers I’ve seen drive the most impact treat the rhythm map like a tool. They know that to influence a planning cycle, their research needs to be done and socialized in advance. Not delivered. Socialized. There’s a difference. Delivered means you sent the deck. Socialized means you facilitated discussions and brainstorms, built a prototype, or co-created the recommendation with the team, so that the PM has internalized the key finding, the designer is sketching around it, the engineer knows what it means for what they’re building, and the data scientist has corroborating signals. By the time the team is making the decision, your research isn’t new information. It’s shared context.
What Changes When AI Enters the Picture
AI tools are changing how fast research can move, though not always in the ways the hype suggests. Synthesis that required a full week of analysis can be drafted in an afternoon. Screening and recruiting can be partially automated. Even where AI doesn’t do the whole job, it speeds up the parts around it: surfacing sources for a literature review, summarizing your notes once you’ve verified them, helping you think through how to present what you found. For researchers who are reactive, this feels like relief. Finally, a way to keep up.
But here’s the uncomfortable truth: your colleagues are moving faster too. PMs are using AI to generate synthetic personas, monitor competitors in real time, and pressure-test product assumptions before they ever come to you. Designers are using it to generate prototypes and run quick concept tests before a study is even scheduled. Engineers are using it to pull their own signal from usage data before asking research to confirm it. The decisions aren’t slowing down. They’re accelerating.
Which means the premium on timing has never been higher. If anything, AI makes Andrea’s approach more important, not less. When everyone can get a quick answer in minutes, what becomes scarce is the researcher who can see the real question beneath the request, who can find the insights that matter and make sense of what they mean for the team, who has built enough context to know what the team is about to need, and who has socialized those findings so they actually shape the decision, not just arrive before it.
AI can also help you be more anticipatory. Even partial speedups mean more time to invest in understanding the roadmap. It can act as a thought partner, poking holes in your plan before a stakeholder does, questioning your assumptions, surfacing what you haven’t considered. And it can help you translate what you’re learning into language that actually lands with a specific stakeholder, so the finding doesn’t just get delivered. It gets understood.
The rhythm still has to be learned. AI just raises the cost of not learning it.
The Researcher Who Shapes the Product
The researcher who shapes the product isn’t just the one with the most rigorous methods. It’s the one who shows up at the right moment, with an insight aimed at the real question beneath the request, already translated into what should change.
It’s the difference between research that lands after decisions are made and research that shapes the decision. Where PMs are already thinking about your last study while they start planning the next feature. Where your insights aren’t a deliverable at the end of a process but an input at the beginning of one. Where you don’t just hand over a finding and hope someone acts on it. You show up with a prototype, a recommendation, a version of what could change. Not just a finding, but the gap already closed between what you learned and what to do about it.
Learning the rhythm of the business is unsung work. It’s relationship building, tracking deadlines that aren’t yours, digging for the real question beneath the request, and socializing an insight so it’s absorbed before the decision locks. But it’s what separates Avery from Andrea. Avery’s work gets heard. Andrea’s work gets used.
You will still have your Avery moments. Deadlines that are impossible, requests that arrive too late, stakeholders who want answers by Thursday. New teams and new stakeholders will put you back in reactive mode, too, until you’ve learned their rhythm. That’s the job too. Reactive research will always exist. The goal is to shift the balance toward anticipatory, so reactive becomes the exception, not the default.
The researchers who shape products don’t just understand users. They understand the organizations building those products well enough to ask the real question, time the work to the decision, and make sure the answer is absorbed before the decision is locked.
That’s the difference: knowing what to ask, when it’s needed, and how to make it land. That’s what gets your work used.
***
A big thank you to Jeralyn Reese, whose thoughtful feedback and practitioner reality check helped shape the section on AI.