The value of qualitative research in a consulting or market research practice does not come from individual conversations. It comes from the synthesis across conversations: the pattern that emerges when you have 30 expert interviews pointing in the same direction, or the specific tension you can only see when you can compare how different customer segments describe the same product experience.
The problem most firms face is not finding good researchers. It is building the infrastructure that allows researchers to work together on a shared analytical corpus, rather than each managing their own siloed set of interviews in their own format on their own drive.
This guide covers how to set up a shared Skimle project that allows a team of researchers to upload, code, and synthesise interviews together, with the analytical consistency and audit trail that professional work requires.
Why research at scale breaks down without shared infrastructure
When each researcher manages their own data, four things predictably go wrong.
Data is scattered. Transcripts exist in multiple formats across multiple drives and inboxes. At the end of a project, assembling the full corpus for analysis requires tracking down files from everyone, converting formats, and reconciling naming conventions. This administrative overhead typically consumes a significant portion of the analytical budget.
Coding is inconsistent. Without a shared coding scheme or central review, two researchers working on the same study may code identical responses differently. The resulting "analysis" is not a systematic read of the data; it is the aggregate of several individually consistent but mutually incompatible readings. As Noren's Head of Research Linda Sivander described before adopting a shared infrastructure: "We used to have transcripts scattered in different formats on different drives by researcher."
Synthesis is done by one person at the end. When data is siloed, synthesis defaults to the project lead reading everyone's summaries and constructing a narrative from notes on notes. This introduces a further layer of interpretation and distance from the original data, and concentrates the analytical risk in one person at the end of the project when time is shortest.
Nothing is reusable. Each project starts from scratch. Themes identified in one engagement cannot be compared to themes from a similar engagement six months earlier. The institutional knowledge sits in the researcher's head rather than in a searchable, structured repository.
Example: Shared infrastructure at Noren
Recommended reading
Noren x Skimle: Spending more time thinking with clients
Noren, a Helsinki-based strategy consultancy that combines human sciences with business development, adopted Skimle as the central research platform for their project teams.
The key shift was moving from a model where each researcher owned their data or it was stored in emails and shared folders to a model where each project is a shared and organized environment. Analysis happens inside that shared environment, where everyone can see the emerging themes, review the underlying evidence, and contribute to the synthesis.
"Skimle projects give a good overview of the data collected so far and the emerging themes," says Linda Sivander, Noren's Head of Research.
Setting up a shared Skimle project
Project scope decisions
Before creating the project, decide on scope. Two common configurations:
One project per study. Each client engagement or research study gets its own Skimle project. This is the standard setup for consulting and market research. It keeps data clearly bounded, makes export straightforward, and prevents accidental cross-contamination of findings between engagements.
One project per programme. For ongoing research programmes (a continuous customer voice programme, or a multi-wave panel study), a single project accumulates data over time. This allows longitudinal analysis: how have themes shifted from Q1 to Q3? Which customer segments have changed their experience of the product? This model requires more discipline in metadata tagging (each document must be tagged with its wave, date, and relevant context) but enables analysis that the single-study model cannot.
Most firms start with the per-study model and adopt the programme model for specific ongoing initiatives.
Team roles and permissions
In a shared Skimle project, define who does what before the project starts:
Research lead (project owner). Sets up the project structure, defines the metadata scheme, reviews and consolidates the AI's initial theme output, and is responsible for the final synthesis. This person makes the key analytical decisions.
Research contributors. Upload their own interviews, add metadata, and contribute to theme review. Contributors should be briefed on the metadata scheme and any analytical framework before they begin uploading.
Client or stakeholder read access. For clients who want to see the data as it accumulates, read access allows them to observe emerging themes without being able to modify the project.
Defining the metadata scheme
The metadata scheme is the analytical backbone of the project. Every document should be tagged with:
- Source type (expert interview, customer interview, internal stakeholder, focus group)
- Participant role or segment (e.g., VP of Product, mid-market customer, churned account)
- Geography (relevant for multi-market studies)
- Interview date (or wave, for longitudinal studies)
- Any other grouping variable relevant to the research question
Define this scheme at the project outset and communicate it to all contributors. Inconsistent metadata tagging is the primary reason cross-tabulation fails at the end of a project.
Creating analytical frameworks: issue trees in Skimle
One of the most valuable features for consulting and research teams is the ability to build custom analytical frameworks within a project, rather than relying entirely on the AI's inductively generated theme structure.
In consulting, the primary analytical framework is the issue tree: a structured decomposition of the central question into the component issues that, taken together, answer it. An issue tree for a customer experience study might look like:
What is causing the decline in customer satisfaction scores?
- Product experience
- Core feature reliability
- Speed and performance
- Integration quality
- Onboarding and implementation
- Time to value
- Support quality during setup
- Documentation completeness
- Ongoing customer success
- Proactive communication
- Problem resolution speed
- Strategic account management quality
In Skimle, you can create categories that reflect this issue tree structure, and then review whether the AI-generated themes map onto the issue tree or reveal gaps and unexpected dimensions the issue tree did not anticipate. The combination is more powerful than either approach alone: the issue tree ensures coverage of the hypothesised dimensions; the inductive AI analysis surfaces the dimensions the issue tree missed.
This hybrid approach (deductive structure + inductive openness) is what makes AI-assisted analysis particularly well suited to consulting work, where you typically arrive with hypotheses but need to test them against data rather than confirming them uncritically.
For the methodological background on this combination, see thematic analysis in qualitative research and the discussion of deductive vs inductive analysis.
Workflow for a multi-researcher project
Week 1: setup and early collection
- Research lead creates the Skimle project and defines the metadata scheme
- Research lead creates the initial analytical framework (issue tree or equivalent)
- All researchers are added to the project with appropriate permissions
- Brief all contributors on the metadata scheme and analytical framework (30-minute team call is usually sufficient)
- Each researcher begins uploading their completed interviews with consistent metadata
During collection: real-time visibility
As interviews are uploaded, the research lead can monitor the emerging picture in real time. This is one of the most underused capabilities of a shared research infrastructure: rather than waiting until all data is collected to begin analysis, the lead can see which themes are already emerging and adjust the remaining interview guide or participant mix if the data is pointing somewhere unexpected.
If the first 15 interviews are clustering strongly around one issue that was not hypothesised, that is a signal to probe it more deliberately in the remaining 25 conversations.
End of collection: collaborative review
When all interviews are uploaded, the AI produces a full-corpus thematic output. At this stage, bring the research team together for a structured theme review session (typically 2-3 hours):
- Each researcher reads through the AI's themes and adds comments on where they agree, where they would revise the label, and where they believe the AI has missed something from their own interviews
- The research lead consolidates the team's feedback and produces a revised theme structure
- Cross-tabulation by metadata is reviewed: are there meaningful differences between participant segments that the overall theme picture is masking?
- The team agrees on the 5-8 primary themes that will anchor the final synthesis
This collaborative review step is where the team's contextual knowledge from being in the room for the interviews intersects with the systematic coverage of the AI analysis.
Synthesis and output
The research lead writes the synthesis narrative, drawing on the confirmed themes, the supporting evidence in Skimle, and the team's interpretive input from the review session. The output includes:
- The synthesised themes with supporting quotes
- Cross-segment comparisons where the differences are analytically significant
- Recommendations or implications if the brief requires them
For guidance on translating this synthesis into a format suitable for executive audiences, see presenting qualitative research findings to executives.
Cross-project analysis: building institutional knowledge
The long-term value of a shared infrastructure is the ability to compare across projects. For firms with a recurring focus area (customer experience research in the financial services sector, or commercial due diligence in technology) the themes identified in one engagement are relevant context for the next.
This requires a discipline most firms do not currently have: tagging projects consistently so they can be searched and compared across engagements. Practical approaches include:
- A standard taxonomy of study types, industries, and research questions applied consistently to all projects
- A periodic review (quarterly or annual) of themes across a set of related engagements to identify cross-cutting patterns
- A knowledge management process that captures surprising or counter-intuitive findings from each project in a form that future teams can access
This is early-stage practice for most firms. The tools to support it exist, and the ROI is significant for firms where a significant proportion of work touches the same industries or question types repeatedly.
Frequently asked questions
How many researchers can work in a shared Skimle project?
There is no fixed limit on collaborators within a Skimle project. In practice, projects with more than 5-6 active contributors benefit from clearer role definition (who is responsible for which interviews, who has final authority on theme consolidation) to avoid the project becoming unwieldy. Large teams also benefit from a clearer metadata scheme: with more contributors, inconsistency in tagging is more likely without explicit standards.
How do you maintain analytical consistency when multiple researchers are coding the same project?
The primary mechanism is the shared metadata scheme and the shared analytical framework (issue tree or equivalent), combined with a team review session. Unlike traditional qualitative coding software where each researcher codes independently, Skimle's AI analysis provides a single consistent baseline that all researchers then review together. This is often more consistent than human coding across multiple researchers, where inter-rater reliability is typically a challenge.
Can we use Skimle for ongoing programmes (not just single studies)?
Yes, the programme model works well for continuous customer voice programmes, panel studies, and ongoing expert intelligence functions. Tag each document with its wave or collection date so you can filter by time period and track how themes shift over successive waves. The longitudinal view in Statistics View makes this analysis straightforward once the metadata is in place.
What happens to data after a project is complete?
Skimle projects remain accessible after the active research phase. For client confidentiality purposes, many consulting firms archive completed projects and restrict access after delivery. The export function produces a complete offline record of all themes, insights, and source quotes that can be stored according to the firm's data retention policy.
Building a research practice and need a shared infrastructure that scales? Try Skimle for free and see how a shared project environment changes what your team can produce.
Related reading: Noren x Skimle: spending more time thinking with clients | How to find themes across a large set of interviews | Qualitative research for consultants
About the authors
Henri Schildt is a Professor of Strategy at Aalto University School of Business and co-founder of Skimle. He has published over a dozen peer-reviewed articles using qualitative methods, including work in Academy of Management Journal, Organisation Science, and Strategic Management Journal. His research focuses on organisational strategy, innovation, and qualitative methodology. Google Scholar profile
Olli Salo is a former Partner at McKinsey & Company where he spent 18 years helping clients understand the markets and themselves, develop winning strategies and improve their operating models. He has done over 1000 client interviews and published over 10 articles on McKinsey.com and beyond. LinkedIn profile
