Your startup has no dedicated researchers. Your PM does research between building features. Your PMM does research between writing launches. Your designer does research between mocking up screens.
Everyone knows research matters. Nobody has time to do it systematically.
This is the reality for most companies under 100 people. You need customer insights, but you can't hire a research team or invest in expensive tools.
The answer isn't to skip research. It's to build lean research operations—lightweight processes that make research feasible even when nobody's job is solely research.
Here's how to run customer research when everyone wears multiple hats.
Why Ad-Hoc Research Breaks Down
Early-stage companies start with scrappy research. The PM interviews some users. The founder talks to customers. The designer watches a few people use the product.
This works until it doesn't.
The breakdown:
Problem 1: Research gets deprioritized
When research isn't someone's job, it gets pushed aside for "urgent" work. Roadmap planning happens without customer input. Launches happen without validation. Nobody has time to run interviews.
Problem 2: Insights get lost
Someone does an interview. They share it in Slack. It gets buried. Three months later, someone else asks the same question and nobody remembers the answer.
Problem 3: Quality varies wildly
Different people run research differently. One person does rigorous interviews. Another person asks leading questions that confirm their biases. Findings are inconsistent.
Problem 4: Redundant work
Product interviews users about Feature X. Two weeks later, PMM interviews different users about Feature X. Nobody coordinated.
Lean research ops solves these problems with lightweight structure:
- Clear ownership (even if it's only 20% of someone's job)
- Shared tools and templates (so anyone can run good research)
- A knowledge repository (so insights don't get lost)
- A research calendar (so teams coordinate)
The Minimum Viable Research Operations Setup
Component 1: Assign part-time research ownership
Someone needs to own research, even if it's not their full job.
This person (often a PMM, PM, or designer):
- Maintains research tooling and templates
- Tracks what research has been done
- Coordinates research requests across teams
- Ensures findings get documented and shared
They don't have to conduct all research. They make sure research happens and findings are captured.
Allocate 20-30% of their time to this. More is better, but even 20% creates accountability.
Component 2: Create reusable research templates
Don't reinvent research every time. Standardize common formats.
Template 1: User interview guide
Standard structure for customer interviews:
- Intro and framing
- Background questions (understand context)
- Core questions (address research goal)
- Wrap-up and thanks
Teams can customize for their specific research question, but they start from a proven structure.
Template 2: Research synthesis doc
Standard format for documenting findings:
- Research question
- Methodology (who we talked to, how)
- Key findings (3-5 main insights)
- Evidence (quotes, examples)
- Recommendations (what should we do based on this?)
Everyone uses the same format, making findings easier to compare and aggregate.
Template 3: Research request form
When someone wants to run research, they fill out a request:
- What question are you trying to answer?
- Why does this matter now?
- Who should we talk to?
- Timeline and urgency
This prevents redundant research and helps prioritize when multiple requests exist.
Component 3: Build a research repository
All findings go in one place—not scattered across Slack, Google Docs, and people's laptops.
Options:
- Notion database (cheap, flexible)
- Airtable (good for tagging and filtering)
- Dovetail or similar tools (purpose-built for research)
Structure:
- Each research project gets an entry
- Tag by type (user interviews, surveys, usability tests)
- Tag by topic (onboarding, pricing, Feature X)
- Tag by date
- Link to raw data (recordings, transcripts, notes)
Now when someone asks "have we researched onboarding?" you can search the repository, not your memory.
Component 4: Establish a research calendar
Track what research is happening and avoid duplication.
Simple shared calendar showing:
- Upcoming research projects
- Who's leading them
- Timeline
Before starting new research, check the calendar. Maybe someone's already researching a related question.
The Research Workflow That Works for Lean Teams
Step 1: Submit research request
Anyone can propose research by filling out the request template.
Examples:
- "We need to understand why users churn in their first 30 days"
- "We're deciding between two onboarding flows—which is clearer?"
- "We're considering pricing changes—what would customers pay?"
Step 2: Research owner reviews and prioritizes
The research owner (that 20% person) reviews requests and asks:
- Is this the right question? (Sometimes the real question is different than requested)
- Has this been researched already? (Check repository)
- Is this the right methodology? (Interview, survey, usability test?)
- When does this need to happen?
They either approve, defer, or recommend changes.
Step 3: Research lead conducts research
The person who requested research usually leads it (with templates and support from research owner).
They schedule participants, run sessions, and document findings using standard templates.
Step 4: Findings are documented and shared
All findings go into the research repository.
Key findings are shared with relevant teams via:
- Slack summary (quick highlights)
- Team meeting presentation (if it impacts roadmap or strategy)
- Written report (if it's significant strategic research)
Step 5: Insights inform decisions
Research is only valuable if it changes what you build or how you sell.
Track: Did this research inform a product decision? A marketing campaign? A sales strategy?
If research doesn't drive decisions, either the research wasn't asking the right questions, or stakeholders aren't engaged with findings.
How to Recruit Participants Without a Dedicated Recruiter
Lean teams can't afford recruiting agencies. You need DIY recruiting that works.
Source 1: Your existing customers
Ask your CS team to identify customers who:
- Are actively engaged (use product regularly)
- Represent your target segment
- Have been customers long enough to have informed opinions
Reach out with clear value exchange:
- "We'd love your input on [topic]. 30-minute call, $100 gift card as thanks."
Hit rate: 40-60% of customers will participate if you make it easy.
Source 2: Recent churned customers
Churned customers are surprisingly willing to talk if you:
- Wait 2-4 weeks after churn (emotions cool down)
- Frame it as helping you improve, not winning them back
- Offer compensation ($100-150)
They often give more candid feedback than active customers.
Source 3: Trial users who didn't convert
People who tried your product but didn't buy can explain barriers to purchase.
Reach out 1-2 weeks after trial ends:
- "We noticed you tried [product]. Would you be open to sharing feedback on what did or didn't work?"
Hit rate: 20-30%, but insights are valuable.
Source 4: Sales prospects who didn't buy
With permission from sales, reach out to deals that closed-lost:
- "We'd love to understand what drove your decision. 20-minute call, no sales pitch."
This doubles as win/loss research.
Source 5: Online communities
If you can't recruit from your customer base (pre-launch, pivoting), recruit from communities where your target users hang out:
- LinkedIn groups
- Reddit communities
- Slack communities
- Industry forums
Offer higher compensation ($150-200) since they have no existing relationship with you.
The Research Methods That Work Best for Lean Teams
Some research methods require lots of resources. Others are lean-friendly.
Method 1: User interviews (lean-friendly)
One person can conduct 5-8 interviews per week while doing other work.
Best for: Understanding motivations, pain points, decision-making processes
Time per project: 2-3 weeks (recruiting, conducting, synthesis)
Method 2: Usability testing (lean-friendly)
Run 5-6 usability tests to catch most major issues.
Best for: Finding UX problems before launching features
Time per project: 1-2 weeks
Method 3: Surveys (lean-friendly for quantitative validation)
Surveys scale—you can reach hundreds of users with minimal time investment.
Best for: Validating hypotheses, prioritizing features, measuring satisfaction
Time per project: 1 week (design survey, collect responses, analyze)
Not good for: Open-ended exploration or understanding "why"
Method 4: Prototype testing (lean-friendly)
Show users designs or prototypes before building.
Best for: Validating concepts, comparing alternatives, getting early feedback
Time per project: 1-2 weeks
Method 5: Data analysis (lean-friendly if you have data)
Analyze product usage, support tickets, and CRM data for patterns.
Best for: Understanding behavior at scale, spotting trends
Time per project: Ongoing
Method 6: Ethnographic research (NOT lean-friendly)
Following users through their day, observing in their environment.
Best for: Deep contextual understanding
Time per project: 4-8 weeks
Skip this unless it's critical. It's too resource-intensive for lean teams.
How to Make Time for Research When Everyone's Busy
The biggest barrier to research: "We don't have time."
Tactic 1: Bake research into existing processes
Don't create new research projects. Integrate research into work that's already happening:
- Product is planning next quarter's roadmap → Schedule customer interviews to inform priorities
- Marketing is launching a campaign → Survey customers about messaging before launch
- Sales is pitching a new segment → Interview prospects from that segment to refine pitch
Research becomes part of the workflow, not extra work.
Tactic 2: Timebox research
Research can spiral. "Let's interview 50 customers" feels overwhelming.
Instead: "Let's interview 5 customers over the next 2 weeks."
Five interviews often reveal 80% of insights. You can always do more later if needed.
Tactic 3: Use async research methods
Live interviews require scheduling and real-time participation.
Async alternatives:
- Video diaries (users record themselves using product)
- Written surveys (users respond on their schedule)
- Unmoderated usability tests (users complete tasks, software records them)
Async research requires less coordination and fits busy schedules.
Tactic 4: Share research load across teams
Product, marketing, and design can all conduct research.
If three people each do one interview per week, you have 12 interviews per month. That's enough to stay connected to customers.
How to Know if Your Lean Research Ops Is Working
Signal 1: Research happens consistently
You're running at least one research project per month. It's not sporadic.
Signal 2: Findings are being used
Teams reference research in planning meetings. Product decisions cite customer feedback. Marketing uses customer language in messaging.
Signal 3: Research requests are manageable
You're not drowning in requests. Teams coordinate to avoid redundant research.
Signal 4: Quality is consistent
Different people run research, but findings are reliable and well-documented.
When to Graduate from Lean Research Ops
Lean research ops works until you hit scale:
Signal it's time to hire a dedicated researcher:
- You're running 3+ research projects simultaneously and can't keep up
- Research requests exceed capacity by 2x
- Teams are blocked waiting for research
- Research findings are strategic inputs to major company decisions
At that point, hire a full-time researcher. But until then, lean research ops keeps you connected to customers without burning resources you don't have.
Research doesn't require a team or a budget. It requires discipline, lightweight process, and commitment to listening to customers. That's something any company can build.