Summary
Research must match the product's evolving fidelity: generative research at the idea stage, formative evaluation during prototyping, summative evaluation before launch, and continuous feedback after launch. The foundation for effective research is a psychologically safe team where members can question, disagree, and admit failure. Skipping generative research is the single most expensive mistake an organization can make.
One of the most common points of friction in organizations is not about budget or methods, it is about timing.
The simple answer to "When is the best time for research?" is "always." The real-world answer is that it is a constant battle, because for many teams, it will never feel like the right time.
The Internal Foundation: Your Team
Before discussing how to navigate stakeholders, we must start with the most critical component of your success: your immediate team.
The quality of your insights is a direct reflection of the health of your team's collaboration. You can have the most rigorous methods and sharpest analysis, but if your internal team operates in silos or lacks trust, your work will never reach its full potential.
Psychological Safety
The goal is to create an environment where disciplines like market research, CX, and UX research are collaborative partners, not competing functions [1].
In a research context, psychological safety means:
| Behavior | What It Looks Like |
|---|---|
| Questioning with curiosity | Challenging a methodology without being seen as incompetent |
| Disagreeing with respect | Debating data interpretation to arrive at more robust findings |
| Failing without fear | Openly admitting when a study is not working or a hypothesis was wrong |
A team that feels psychologically safe internally is far more resilient externally. It provides the collective confidence to deliver the difficult, objective truths that stakeholders need to hear.
For a deep dive on building research culture and team collaboration, see Building Research Culture: Safety & Collaboration.
Matching Research to Product Fidelity
Your core job is to reframe research from a single, disruptive event into a continuous, value-adding loop. To do this, you must match your research activities to the product's evolving fidelity.
Stage 1: Idea and Concept (Generative Research)
When: Before you build anything, when dealing with abstract ideas and concepts.
Purpose: Determine what to build before thinking about how to build it. De-risk your entire strategy by ensuring you are solving a real problem for a real audience.
Stage 2: During Prototyping (Formative Evaluation)
When: As ideas turn into tangible prototypes, low, medium, and high fidelity.
Purpose: Find and fix issues while they are still cheap to solve. A UX test should be triggered at every major iteration or whenever a cluster of important questions accumulates.
Today, a prototype might be:
- A clickable Figma or Adobe XD design
- A partially functional coded app
- An SDK or test build distributed through platforms like TestFlight
Regardless of format, this is the prime time to identify and resolve problems while changes are inexpensive.
Stage 3: Before Launch (Summative Evaluation)
When: Approaching a release with a high-fidelity prototype or MVP.
Purpose: The final quality check. However, you must manage expectations about what is possible at this stage.
Stage 4: After Launch (Live Product)
When: Once the product is on the market.
Purpose: Continuous feedback loop combining:
- Passive data: Analytics and A/B tests providing quantitative data at scale
- Active research: UX benchmarking, ongoing qualitative studies to understand the "why" behind the numbers
In this mature phase, the lines blur. A single session might start by evaluating an existing workflow and end with generative questions to validate new feature ideas.
For the detailed research plan that each fidelity stage requires, see The Research Plan.
The Research Timing Lifecycle
| Stage | Research Type | Key Question | Cost of Skipping |
|---|---|---|---|
| Idea/Concept | Generative | "What should we build?" | Building the wrong thing entirely |
| Prototyping | Formative | "What's not working?" | Expensive rework after development |
| Pre-Launch | Summative | "How well does it perform?" | Launching with avoidable issues |
| Post-Launch | Continuous | "What's happening and why?" | Blind to real-world performance |
The Three Critical Moments for Research
Research is not a one-off event; it changes as the product matures. Here is the timeline every PM should internalize:
START → Idea Stage (Generative) Before code. Validate the problem, not the solution. Do not ask "Do you like this idea?" Ask "How do you currently solve this?" This prevents building features nobody wants.
MIDDLE → Prototyping (Formative) During design. Iterative usability testing finds friction while it is cheap to fix. A change in Figma costs €50; the same change in code costs €5,000.
END → Live Product (Summative) After launch. Benchmarking and analytics answer: Did we hit the goal? Use standardized metrics (SUS, NPS) to track improvement over time.
Handling the "Not Now" Response
When stakeholders push back on research timing, the root cause is usually fear or pressure:
"It's too early": Fear that negative feedback on an unpolished prototype will be discouraging.
Response: "That's exactly why we should test now. If we find a fundamental problem at this stage, it's much cheaper to fix than after weeks of development."
"It will slow us down": Pressure to move fast.
Response: "Research won't be a bottleneck. Think of it like a Git branch, development continues on the main branch while research runs in parallel. When we're finished, we merge the findings back in."
What This Means for Practice
Research is not a gate to pass through; it is a continuous pulse that informs every stage of product development.
Build a team foundation of psychological safety that enables honest, rigorous work. Then map your research activities to the product's fidelity, generative at the start, formative during development, summative before launch, and continuous after.
The goal is not to do research to the product team. It is to do research with them, throughout the entire journey.
For detailed phase-by-phase timing guidance, see When to Research: A Guide for Product Teams.
References
- [1]