I believe research and strategy need to run in parallel.
One without the other is like having a map without a destination or a destination without directions.
What follows is a framework to get started. It equips not just research teams, but everyone in the ecosystem, from product managers to compliance leads, to work from the same set of truths.
Teams often run the same studies or pull identical data without realizing it. This, by far, is the biggest challenge, and I’ve been guilty of it, too. Without a shared repository, teams end up reinventing the wheel. Even when research repositories exist, they’re usually confined to specific functions. Adjacent teams can’t access them, and at a larger org level, the same resources get used repeatedly to synthesize the same findings in different capacities.
Reports and decks are created, presented once, then left to gather dust. In complex B2B SaaS environments, this problem multiplies. There are separate teams connected to the same product, beyond product design, development, and product management teams. There could very well be a sales team, a back-end ops team, a billing & services team, customer support, as well as a team that only helps with data management. Multiple teams will work in parallel with their counterparts from different product spaces to move forward. This is a nightmare.
Often, teams are solving the same problems from different sources of truth, leading to duplication and confusion.
Insights age fast, especially when teams move at supersonic speeds. Yet outdated data continues to shape decisions. In reality, most teams don’t have time to dig into your process or rigor; they want concise, actionable answers. What’s missing? What might work? What does the data show? Many of these decisions happen in a 60-second hallway conversation.
If you already use current-state and future-state maps, you’re making a Lean move. I extend that practice by linking research notes, analytics, support data, and compliance information—so answers are traceable, verifiable, and visible in one place. Once people know and trust how you think, they start relying on that system.
Related read: Lean Thinking in UXÂ Research: Maximizing value, minimizing waste by Sara Ulius-Sabel
The hidden cost of the above issues runs deep. Teams spend valuable time searching for answers instead of acting on them. McKinsey notes that knowledge workers spend nearly one full day each week just gathering information.
That’s a day lost to inefficiency, every single week.
When knowledge is scattered, teams end up repeating studies that already exist. We all know how resource-intensive research can be. The cost of researchers, participants, recruitment, and the effort required to align multiple leaders in one room. Every duplicated study drains time, money, and focus that could have gone toward uncovering new insights.
When product, design, and research teams stop believing in each other’s evidence, trust erodes.
From a service design perspective, trust is everything. You want every partner to believe in the process, not just the output. But trust isn’t built overnight. You need to build relationships, engage effectively, and repeat. The same goes for all other teams in their own capacity. The moment there’s hesitation about data accuracy, rebuilding that confidence becomes exponentially harder.
To set the context, let’s look at how service design can help. There are countless ways to define it; however, I frame it as:
A process that highlights how our internal processes impact the end customer, thus improving efficiency for internal teams and product experience for our users.
You can always explore the theory further, but a simple and practical way to start is by developing a target-state blueprint.Â
This is where service design comes alive. It begins with understanding the entire ecosystem, mapping the current state blueprint, identifying both backend and customer-facing processes, and identifying critical touchpoints as well as gaps. Those gaps then become your entry points to locate existing research, commission new studies where evidence is missing, and ideate what product, service, or feature could fill them.
Even if you don’t have a dedicated service designer, this approach is still possible. Try it for one project and reuse that blueprint in later conversations. Each iteration builds trust with stakeholders, prevents duplicate research, and helps teams move faster through roadmap cycles.
An insight ecosystem gives your organization one place where anyone can type a question and get a sourced, traceable answer.
That’s how I use these current-state and target-state blueprints—as live tools in workshops. I bring key people into the room, show them the blueprint, and ask targeted questions that typically take three directions:
Instead of static decks, research notes, analytics, support tickets, sales calls, and compliance docs are linked together.
Within my blueprints, I reference all relevant materials, linking decks where needed so stakeholders aren’t sifting through endless Drive folders.
It’s as much for me as for them; by connecting these pieces, I can form more cohesive recommendations.
As richer data layers are added, it becomes clear to everyone why certain actions matter.
Ultimately, building an insight ecosystem sets organizations up for faster decisions, fewer repeated efforts, and evidence people trust.
Through facilitation, you get better at guiding teams toward decisions that extend beyond their immediate frame of referenceÂ
As one of my professors from Parsons School of Design shared:
A researcher or service designer must learn to expand their own frame of reference, one that integrates the diverse perspectives of every stakeholder involved.
Related read: Beyond the "black box": Measuring research impact by Pedro Vargas
Start at the ecosystem level. Identify the key people around the product you are working on, then map adjacent teams and product verticals. In B2B SaaS, this gets complex, since some internal products cut across several product-facing areas. Trace how these teams connect and what value they exchange. This first step shows you who to reach out to, helps you build product context, and clarifies who knows what and when. I use it to make internal connections and to spot gaps in my target state blueprint.
At a minimum, yes, the current state blueprint connects the research repository with CRM, product analytics, support, and other relevant sources. The difference is that it is not a static knowledge base. It is an insight layer that sits on top of those tools. It links every claim to its evidence, keeps provenance, and answers plain-language questions with citations. The original systems remain the source of truth. This layer makes them work together.
In practice, you map the data from the tools teams already use and clean it. AI helps extract key facts, surface patterns, and detect contradictions. NotebookLM is useful here. I maintain notebooks across product documents and customer discovery reports, then use them to summarize and prompt for answers, with sources visible so stakeholders can verify the trail. Start by picking one high-value question, select the few sources that can answer it, define simple guardrails for what counts as evidence, and repeat. After a few cycles, you will see the deeper architecture. This is also where you spot gaps for new research, or use existing research to show stakeholders what might be missing.
In systems, no work is successful if done in isolation. Different tools and roles tie this together for it to work beautifully.
Once these roles have clarity on the larger goal, things are easier. But they essentially make it stick.
One way to use your work is to cause conversations, moments of friction (in a healthy way) to get clarity. Referencing the current or target state as a visual to help guide people through some conversations.
By this time, I have developed such deep product and process knowledge that I can ask better questions that align with my business or project goals.
As you share sources of truth and domain expertise, you build trust and a genuine human connection with your stakeholders. A good metric to check if this is working is how frequently they come back to you asking for your process maps for their work. That means your work is being sought after. Your voice is important.‍
The ultimate metric isn’t the number of studies you run, but the confidence with which leaders act, knowing their choices rest on evidence they can trust.
Dhairya Sathvara is currently a Senior Service Designer at Intuit. Previously he has helped startups and mission-driven organizations create products that blend business impact with human-centered design. His work focuses on navigating the messy, ambiguous stages of product development, ensuring teams make informed decisions backed by research. Dhairya holds an MS in Strategic Design & Management from Parsons School of Design and is currently based in San Francisco. Connect with Dhairya on LinkedIn.
