How to build a research practice from zero as the first researcher hired at a growth-stage startup

Being the first researcher hired at a growth-stage startup is one of the most challenging and rewarding roles in UX research. You walk into an organization that has achieved product-market fit—or something close to it—largely on instinct, founder intuition, and fast iteration. People are excited about research in the abstract but may have no idea what it looks like in practice. There are no templates, no participant panels, no repositories, and no established expectations for how research fits into the product development process.

Your job is not just to do research. It's to build the conditions that make research a lasting part of how the company makes decisions.

This guide covers how to approach that work practically, from your first weeks through your first year.

Understand the landscape before you change anything

The instinct when starting a new role is to move fast and prove your value. Resist it—at least for the first few weeks. Growth-stage startups have developed their own ways of learning about customers, even if those methods are informal. Sales teams run demos and hear objections daily. Support teams see the same complaints surface week after week. Founders have strong mental models of who their users are and what they need.

Before introducing new processes, spend time understanding what already exists.

Map the informal research that's already happening

Talk to people across the organization—product managers, designers, engineers, salespeople, support leads, and founders. Ask questions like:

• How do you currently learn about what customers need?
• When was the last time you talked to a customer, and what did you learn?
• What decisions are you making right now that you feel uncertain about?
• Where do customer insights live today?

You'll almost always discover that research-like activities are happening, they're just scattered and unsystematic. Sales call recordings sit in a CRM. Support tickets contain rich qualitative data. Product managers run occasional user interviews but don't have a consistent way to synthesize or share what they learn.

Documenting this landscape gives you two things: a clear picture of the gaps you need to fill and a way to position research as complementary to what people are already doing rather than a replacement for it.

Identify the decision-makers and their open questions

At a growth-stage startup, the people who will determine whether your research practice succeeds are the ones making product and business decisions daily. These are typically product managers, the VP of Product, designers, and often the CEO or CTO.

Meet with each of them. Understand their roadmaps, their biggest uncertainties, and the decisions they're facing in the next quarter. This is not just relationship-building—it's your intake process. Their open questions become your first research opportunities.

Pick your first project carefully

Your first study sets the tone for how the organization perceives research. Choose it deliberately.

The ideal first project has several characteristics:

• High organizational visibility. The results should matter to people beyond a single product team.
• A clear decision it will inform. Avoid open-ended exploration for your first project. Tie the research to a specific choice the team needs to make.
• A reasonable timeline. Aim for something you can complete within two to four weeks, including recruitment, sessions, analysis, and a readout.
• A receptive stakeholder. Work with someone who is already enthusiastic about research. Early adopters become your internal advocates.

For many first researchers, a usability study on a feature in active development is the right starting point. It's concrete, fast, and produces findings that designers and product managers can act on within days. Nothing builds credibility faster than a stakeholder watching a user struggle with something they assumed was intuitive.

Whatever you choose, involve stakeholders from the start. Invite them to help shape the research questions. Encourage them to observe sessions. When people participate in the process, they trust the findings more and are far more likely to act on them.

Build credibility through visible impact

At a growth-stage startup, research must earn its place. Unlike at a large enterprise where research may be an accepted function with its own budget and headcount plan, a startup will continuously—if informally—evaluate whether research is worth the investment.

This means the first six months are as much about demonstrating value as they are about doing rigorous work.

Share findings where people already are

Don't rely on a 40-slide deck that sits in a shared folder. Bring findings to existing meetings—sprint planning, design critiques, product reviews. Post highlight clips in Slack. Create one-page summaries that lead with the decision implications, not the methodology.

The format matters. A two-minute video clip of a user struggling to complete a task is often more persuasive than a detailed thematic analysis. Use the full analysis to inform your recommendations, but lead with what will resonate.

Track outcomes, not just outputs

Keep a running record of decisions that were influenced by research. When a product team changes a design based on usability findings, note it. When a discovery study reshapes a roadmap, document it. Over time, this record becomes your strongest argument for expanding the practice.

Be honest about what research can and cannot do

One of the fastest ways to lose credibility is to overstate what a single study proves. Be clear about confidence levels, sample sizes, and the boundaries of your findings. Stakeholders at growth-stage startups are sharp—they will respect intellectual honesty far more than inflated certainty.

Establish lightweight systems early

You don't need a fully mature research operations setup in your first quarter, but you do need basic systems that make your work repeatable and your findings discoverable.

Create a research repository

If findings only live in individual slide decks and documents, they effectively disappear after the readout meeting. A research repository is a centralized, searchable place where all research findings are stored, tagged, and accessible to anyone in the organization.

This is where a tool like Dovetail becomes particularly valuable for solo researchers. Rather than spending hours maintaining spreadsheets and folders, you can tag and organize data from interviews, usability tests, and surveys in a single place. When a product manager six months from now asks "What do we know about how customers think about onboarding?", the answer should be findable without asking you directly.

Start simple. Even a well-organized shared folder with a consistent naming convention is better than nothing. But if you can invest in a dedicated repository early, it pays dividends as the volume of research grows.

Build a participant recruitment pipeline

Recruitment is the biggest bottleneck for most solo researchers. Establish your approach early:

• Internal sources. Work with sales, support, and customer success teams to identify customers who are willing to participate. Create a simple opt-in process—a short form on your website or an email flow triggered after certain product interactions.
• External panels. For studies that require non-customers or specific demographics, a recruitment panel service can save significant time.
• A participant database. Track who has participated, when, and in what studies. This prevents over-contacting the same people and helps you ensure diversity across studies.

Develop templates and protocols

Standardize the artifacts you use most often: discussion guides, consent forms, note-taking templates, research briefs, and readout formats. These save time on every study and make it easier for non-researchers to participate in or observe sessions.

Templates also make your process legible to the organization. When a product manager can look at a research brief template and understand exactly what information you need from them to kick off a study, the intake process becomes smoother for everyone.

Democratize research without losing rigor

At a growth-stage startup, you will never have enough capacity to run every study the organization needs. Nor should you try. Part of building a research practice is enabling others to conduct lightweight research on their own while you focus on the work that requires deeper expertise.

Define tiers of research

A useful framework is to think about research in tiers:

• Self-service research. Product managers and designers run quick usability tests, surveys, or unmoderated tests using established templates and tools. You provide the templates, training, and quality checks.
• Supported research. You help a product team design a study, review their discussion guide, and coach them through analysis, but they run the sessions themselves.
• Full-service research. You own the study end to end—typically reserved for complex, strategic, or cross-functional questions.

This model multiplies your impact without requiring you to personally run every study. It also builds research fluency across the organization, which is the foundation of a true research culture.

Train, don't gatekeep

Run short workshops on interviewing fundamentals, how to write a good discussion guide, and common cognitive biases that affect research. Make these practical—30 to 60 minutes, with real examples from your company. When colleagues know how to ask open-ended questions and avoid leading participants, the quality of self-service research improves dramatically.

Dovetail can support democratization by giving cross-functional teams a shared space to contribute observations, review tagged highlights, and access past findings—without needing to go through you as a bottleneck.

Navigate the political realities

Building a research practice is not purely a methodological challenge. It's an organizational one. You'll encounter dynamics that require careful navigation.

When stakeholders want research to validate, not learn

You will inevitably receive requests framed as "Can you do some research to prove that this feature is needed?" This is confirmation research, and it undermines the function. Handle it by reframing: "I can help us understand how customers think about this problem space so we can make a confident decision about whether to build this feature and how to design it."

Most stakeholders are open to reframing when you make clear that the research will still help them move forward—it just might move them in a direction they didn't expect.

When speed conflicts with rigor

Startups move fast. You will be asked to deliver insights on timelines that feel uncomfortably short. Develop a sense for when speed is genuinely important and when it's just a habit. For truly urgent decisions, a few quick interviews or a rapid usability test is far better than no research at all. Communicate clearly what a compressed timeline means for confidence and scope.

When leadership is skeptical

Some executives will be skeptical of research, especially if the company has been successful without it. The best response is not to argue—it's to show. Deliver findings that surprise people or that directly contradict a confident assumption. When research reveals something no one in the room expected, skeptics start paying attention.

Plan for growth

If you do your job well, demand for research will outstrip your capacity within six to twelve months. Start thinking early about what growth looks like.

Document what you've built

Write down your processes, templates, and operating principles. This documentation serves two purposes: it makes it possible for new hires to onboard quickly, and it forces you to be explicit about decisions you've made implicitly.

Make the case with evidence

When it's time to request additional headcount, your record of tracked outcomes becomes essential. Show the volume of research requests, the decisions influenced, and the studies you had to decline or delay due to capacity constraints. Frame the request in terms of organizational impact, not just workload.

Think about specialization

As the team grows, consider whether you need generalists who can cover multiple product areas or specialists in specific methods—quant research, field research, or research operations. The right answer depends on your organization's needs, but having a point of view will help you hire deliberately.

A long game worth playing

Building a research practice from zero is slow, messy, and deeply satisfying work. You won't have the infrastructure of a mature organization. You'll wear many hats—researcher, evangelist, ops manager, coach, and occasional therapist for a product manager navigating ambiguous data.

But you'll also have something rare: the chance to shape how an entire company relates to its customers. The systems you build, the habits you instill, and the culture you cultivate will influence product decisions long after you've moved on.

Start with the relationships. Deliver early wins. Build systems that outlast any single study. And trust that a company that learns to listen to its customers systematically will make better decisions than one that relies on intuition alone.

Most first researchers report that it takes six to twelve months to establish a functioning research practice with visible organizational buy-in. The first three months are typically focused on understanding the business, building relationships, and delivering a few high-impact studies that demonstrate value. From there, you shift toward building systems—templates, repositories, recruitment pipelines—that make research repeatable. A mature practice with embedded rituals and broad stakeholder participation often takes 18 months or more.

It depends on what the organization needs most urgently, but many first researchers find early success with evaluative research—usability tests, concept tests, or design reviews—because it delivers fast, tangible results that product teams can act on immediately. Once you've built credibility through evaluative wins, it becomes easier to advocate for generative research like discovery interviews or field studies, which require more time and organizational patience but often yield the most strategic insights.

At minimum, you need a way to recruit participants, conduct and record sessions, analyze qualitative data, and share findings. Many solo researchers start with a video conferencing tool for remote interviews, a participant recruitment platform or panel, and a research repository like Dovetail for organizing notes, tagging themes, and distributing insights across teams. A simple spreadsheet for tracking studies and a shared drive for consent forms and protocols round out the essentials. Avoid over-investing in tooling early on—start lean and add complexity as your practice matures.