What do you need to know before you start looking?

One of the most expensive mistakes in market access work is not knowing what you’re looking for before you start. Teams jump into research too quickly, pulling publications, scanning HTA reports, and downloading data, without a clear sense of what matters. The result is often a bloated deck or a spreadsheet full of information that doesn’t move the strategy forward.

That’s not a research problem. It’s a scoping problem.

At Knowledgeable, we believe every project should begin with structured, thoughtful framing. But structure only works when it’s backed by experience. That’s why I asked Louise Street-Docherty, our VP of Market Access, to share her perspective. Louise has spent years helping teams decide what matters, what to prioritize, and where not to waste time.

Here’s how she approaches the earliest and arguably most important phase of any project: defining the landscape.

What types of landscape elements are most often overlooked?

Louise:

One of the most common blind spots is stakeholder context. Many teams focus heavily on trial data and market activity but overlook who is shaping the conversation in a particular space. That includes national payer bodies, HTA contributors, guideline authors, and clinical experts who influence policy decisions.

Another element that is often missed is regional variation. A landscape might look one way at the global level but shift entirely when viewed through a country-specific lens. This is particularly relevant in Europe, where access decisions and commercial viability can differ significantly between markets.

Finally, teams sometimes fail to capture historical signals. Understanding what’s been tried before, and why it did or did not work, can prevent teams from repeating past mistakes. That history is rarely captured in the abstract. It lives in HTA reviews, pricing outcomes, and subtle shifts in reimbursement logic.

How do you decide which data types matter for a specific indication or project phase?

Louise:

Context is everything. For early clinical-stage assets, your focus might be on mechanism of action, clinical differentiation, and emerging biomarkers. For late-stage or launch-ready products, you’re more likely to be looking at trial comparators, prior HTA outcomes, price analogues, and stakeholder sentiment.

I always start with the decision the project needs to support. Is this about shaping a TPP? Defining an access strategy? Supporting a payer communication plan? Each of these needs a different blend of data, some more quantitative, others more opinion-led.

When teams rush into search mode without stopping to define that blend, they often collect too much of the wrong thing and not enough of what really matters.

What role does payer behavior play in shaping your research scope?

Louise:

A central one. If you’re building a value narrative or pricing strategy and payer behavior is not part of your research scope, you’re likely to miss what actually drives access outcomes.

Payers are not just passive reviewers. Their behavior is shaped by precedent, sentiment, risk tolerance, and evolving priorities. That shows up in what they approve, what they reject, and what conditions they attach to reimbursement.

When I scope a project, I look at payer decisions from similar assets, how they’ve interpreted uncertainty in the past, and whether local conditions, budget cycles, political shifts, or policy updates might influence their view.

Sometimes, this means including payer sentiment as a formal track in the research plan. Other times, it means weighting evidence based on its likely persuasive value. Either way, it informs both what we look for and how we interpret it.

How do experienced consultants narrow the field without missing something important?

Louise:

They start by being honest about what is in scope and what is not. Trying to include everything is a quick path to confusion. A well-framed research scope is tight enough to keep the work focused, but flexible enough to allow for unexpected insight.

That usually means beginning with a small number of high-impact questions. From there, you can test which areas have enough evidence to support strategic decisions and which are likely to be unproductive. I also recommend pre-identifying exclusion criteria, for example, outdated trials, irrelevant comparators, or regions outside the target market.

Experienced consultants also know that scoping is iterative. You may start narrow, learn something useful, then expand slightly. That approach is more efficient than trying to cover everything from the start.

How does Knowledgeable bring structure to early landscape scoping so projects don’t waste time chasing the wrong data?

Louise:

We built Knowledgeable to support this exact phase of thinking. Every project begins with a structured setup. That includes selecting the project’s goal type, whether it’s value strategy, TPP design, competitive landscaping, or price research and then tagging it with the relevant disease area, mechanism of action, and strategic concepts.

Because the ontology is designed around real consulting work, those tags are meaningful. They help guide the literature review, stakeholder mapping, and evidence extraction efforts so they stay focused on what the project is trying to achieve.

The platform also captures the scoping logic itself. This means you’re not relying on scattered notes or memory to explain why certain areas were prioritized. Everyone on the team can see what’s in scope, what’s out, and why.

And because all this happens before the search begins, it helps prevent wasted effort and duplicated work later in the project.

Summary

This phase of the work often happens quietly. It doesn’t always show up in the slide deck. But when it’s done well, everything else moves faster. The literature is easier to manage. The insights are more relevant. The outputs feel intentional.

Louise’s approach shows that good scoping is not just about knowing where to look. It’s about knowing what you need, what to ignore, and how to stay focused on the decision the client needs to make. We built Knowledgeable to make that kind of thinking easier, more consistent, and easier to scale.

Because if you get the first step right, the rest of the work gets a lot simpler.