Building and managing a regulatory function as a small-to-medium sized sponsor presents unique opportunities…and unique challenges. The processes, tools and workflows that the big guys use aren’t accessible to those of us that are single-person regulatory teams, or have only a few teammates to lean on. So how do you build a lean regulatory function that will not only support your first IND, but will scale sustainably alongside your pipeline?
Choosing the right partners - both services and software - can accelerate or hinder your ability to get the job done with less manual work and a lot less stress.
What you'll learn:
To learn more about how Kivo can help streamline regulatory submissions for your organization, request a demo today.
Kevin Tate: I'm Kevin Tate, CRO here at Kivo. Thank you so much for joining. We're glad you're here. We've got a big crowd today, so obviously a hot topic, and we're excited to talk about how to think about scaling your regulatory operations in today's world, particularly with the focus on how do you think about using partners and technology in a way that that works best for your team.
First, I want to introduce today's speakers. We are going to hear first from Dr. Lisa Jenkins VanLuvanee. Lisa is the VP of R&D and COO at Facet Life Sciences. She began her career on the sponsor side, where she led numerous NDA and BLA teams, and in her consulting role at Facet she has provided strategy, guidance, and content review for over 200 products. So a great deal of experience in helping teams bring new products to market.
Then we're going to hear from Toban Zolman. Toban is the CEO and founder of Kivo. Kivo provides a compliant DMS and a regulatory solution that's particularly built for small and scaling teams. Toban has 20 years of regulatory experience. He's consulted with 47 of the world's top 50 pharma companies. So a lot of work with regulatory teams and helping those teams work quickly and and confidently. So excited to hear from our panelists today.
I'm gonna start by framing the topic just a little bit, and then I'm gonna hand it off to Lisa and Toban to dive deeper. So why are we talking about this? And why is this such an interesting time to be looking at how regulatory teams work?
From our perspective, one of the things that is shaping how regulatory teams work today is some really interesting market dynamics. First, everything's moving faster. So we're seeing pipeline acceleration. And we're seeing a call for even more timely exits or business success driven in part by the funding environment. So VC and private equity backers are looking for faster exit opportunities. And of course, the use of AI and more modern tools is significantly reducing the pre-clinical phases, for example, taking those from 3 to 5 years to more like 18 months. So everything is trying to go faster.
We're also starting to see a resurgence of investment in the space. As we all know, a lot of investors took some time off after 2021 / interest rate hikes. We're starting to see that come back now, especially in hot sectors, and with a expectation that that's gonna grow significantly in the next year. And ultimately, that's going to mean more development. Estimates call for over 30,000 active trials by the end of this year, and that's up 36 from just 2020. So that's a huge change in the volume of what's coming through the pipe, and that's before we see the effect of an AI-fueled wave that we're expecting to hit in 2025 and then continue on. So this wheel is starting to turn faster with different types of expectations and market dynamics. So that's an interesting backdrop to what it's like to be in a small and scaling regulatory team today.
Part of what we see at Kivo is how that has been and continues to really change how these teams work. And in fact, we see something of a new operating model for life science companies and the regulatory teams. To paint that in broad strokes, the way it worked then was you tended to have big teams working all in the same place working together to build a big pharma company or enterprise, and together they moved steadily toward commercial launch. Right? And we all know, it takes 13 and a half years on average to get a product to market that way. And that was the model.
But today's model - as many of you are living - doesn't work that way anymore. Most of the drug development happening today is in small distributed teams that are working with expert partners and trying to use technology to get more done with a smaller group. A lot of the focus is on building a pipeline of products and staying agile with the opportunities to drive toward an acquisition or create a partnership or other positive outcomes around that that product and pipeline. And that creates a really different way of working together. Right? So if the old way is kinda like "Everybody get on the big train and we're gonna roll down the tracks to market," now it feels more like a fleet of cars driving together. Many of those aren't inside your organization, with regulatory in the lead, we've got partners on the writing side, on the publishing side, and of course, the CRO bus back there. So this is a very different landscape in which to be building and managing a team. So part of what we wanted to explore in the webinar today is, how is that manifesting itself as teams think about how to best build and scale their regulatory function.
So first we're gonna hear from Lisa, who's gonna be talking a bit about what it's like as you're putting together that initial planning and building out that team. With that, Lisa.
Lisa VanLuvanee: Thank you, Kevin. So a little bit first about Facet and then I'll get into the topic. We are a regulatory and development organization that helps very small emerging companies get their products to and through FDA and then into patients in need, and that's really our focus.
You talked a little bit about how the landscape has changed / what we're seeing, and what we've seen for some time is that actually, the big pharmas actually aren't developing their own products. It's the smaller companies that are coming up with a scientific innovation. They develop it to a certain point. Most of them plan exit after proof of concept, or a little bit later, and then it is purchased by either a large pharma or a company that can take it all the way.
So in terms of service offerings at Facet, we do everything that you would expect a full service regulatory development CRO to do except we don't run clinical trials. We don't run non clinical studies, and we don't manufacture products. We do handle full service regulatory affairs. We write all the documents within regulatory submissions. We provide statistics support both for FDA meetings, but also an interesting area of innovation that seems to be new and growing, and interesting, is using statistical simulations to be able to improve clinical trials of success. So we're seeing a lot of interest in that space.
And then commercialization services...To be honest, for a long time Facet was focused on the regulatory process. We could get products approved with FDA, but then it was on the sponsor to ensure that they got the best pricing reimbursement and were able to get market access product into patients. And what we've learned is actually small companies, especially those who wanna take their products all the way right into the marketplace, small companies actually need to plan for that commercialization upfront. One of the things we're seeing an uptick in in early companies that are trying to make go/no-go decisions about what to develop. They actually are being required by their investors and board members to provide a commercialization package. Is there value in this product from an economic standpoint? From a market standpoint? How much money should we be putting into development in order to realize benefit post approval? So those kinds of things have really started to come into play in order for small organizations to get the best price and value out of the development that they do choose to pursue.So that's Facet.
Things that we are seeing and the things that I'm seeing...In small companies, it's very common for these companies to be virtual and be distributed throughout the world. They are folks who have been there and done that, generally, or they're the innovators of their product. And they work with their friends, single shingles, experts that they've worked with in the past. That's fantastic in very early development. But when you start heading towards your 1st application and even later applications with FDA, you really need to have a more comprehensive and full set of service support.
So we're seeing a move away from those single shingle specialty groups to a full service organization, and that offers small companies a benefit that they tell me time and time again they didn't anticipate, but they really value. And that is when you go with a full service specialty CRO that can do everything that is needed for that small company. In early development, it minimizes the number of contracts you need to have with your partners. It minimizes the invoicing process and all those business details that go along also working with one comprehensive unit.
Another benefit we're hearing is that if you have a full service specialty organization working with you all those pieces that I just talked about - regulatory, statistics, commercial - they're all working together because they're all on the same team. So it helps those small organizations be more efficient.
Second thing we're seeing is right-sized asset development. I can't emphasize this enough, especially with what Kevin had to say about funding. Everybody's trying to do more with less, so we want our development plans to be done in right size bytes in accordance with how much money we have, but we also want to do it in the context of of business. We want to make sure that all the decisions we're making - the scientific ones medical ones, regulatory ones and commercial ones - all support our stage and development.
What we're trying to accomplish as a small organization is securing regulatory assets early and often. We say this all the time - you are developing a product, and there is value in that product. Your value as an organization is tied up in the value of your products, so the more regulatory assets...one of our clients termed it as a "regulatory, shiny bobble"...But the more regulatory assets you can accumulate early in development, the more value you're building in. When you secure an orphan designation. when you secure a breakthrough designation...Those regulatory assets translate into financial assets. Investors pay attention to the regulatory assets you're accumulating, and often that is the trigger to getting additional investment.
Let's talk a little bit about scientific expertise and what kinds of things we're seeing the industry developing.
Of course, everybody is talking about obesity products. That's cross cutting throughout the market, and we are seeing it in every stage and phase. Kevin, you also mentioned cell and gene therapies. Absolutely. Those are go unspoken.
We are seeing real innovation and interest in rare disease development, especially because the regulatory pathways are uncertain.We're seeing a lot of development and innovation and psychedelic product and development. The recent Advisory Committee didn't go the way that it was expected to go, so I think the psychedelics market is...there's going to be a little bit of a readjustment. But there's still enormous development in that space, because there's great CNS potential for those products, and that those are indications that have not seen a lot of new product development since the SSRI days. It's been 20 years.
Pharmaceuticals related to radiochemistry, both diagnostics as well as therapeutics are extremely hot, those products are very interesting in their development and innovation. They have special regulations that dictate their development, but they pose enormous promise for oncology and oncology development, which still remains a very, very hot area from a development and regulation standpoint. And a strategic standpoint for small companies. What we're seeing is a very smart, regulatory pathway, and that is, let's do our 1st in human studies in Australia. The regulatory hurdle is low, and we can get to proof of concept in humans to determine, "Is this product worth the additional investment to undertake non-clinical testing? To undertake CMC development? Is it worth it to proceed based on data we've collected in Australia?" So that's becoming a very, very common pathway.
Another thing we're seeing that I'm particularly excited about...in the old days, Kevin, as you painted, we used to just use clinical trial data to support regulatory applications. The agency is more interested now in than ever in real world data, patient information, caregiver information information from diverse populations...all add value and a nice complexion to understanding how the products we are developing work and how they have value. We're seeing things from post-marketing databases. Of course, we're seeing things from registries and observational studies. We're seeing compassionate use provide significant evidence to FDA to get products that are being used fairly routinely to to secure those approvals in the US.
Repurposing of products were often taken the 505(b)(2) route. Is that the way? This has been, and probably always will be, a very effective approach to product development, repurposing existing FDA approved products for new indications or creating new formulations that patients need to to be able to to use products that are currently approved. I don't see that changing anytime soon. I'm seeing creativity and how folks are doing it, which is really exciting, but repurposing, I think, is here to stay.
Then you mentioned AI in the pharmaceutical industry. Everybody's talking about it from a content development standpoint. We're seeing some success in narratives generation for clinical trials. But we've been asked, "hey, can I create my IND using AI?" And unfortunately, the answer right now is, maybe in the future. But not right now.
I've been doing this for a very, very long time. And I've talked to many organizations about the things that I think help to drive success and to set organizations up for success. The 1st thing, and I think the most important thing is actually to work with a regulatory development organization that has been there and done that. They have a proven track record of success with FDA. This is very real for them. They've been living it day in and day out. They know the tips. They know the tricks to be able to get you further, and to get you further with less. And that's tied up in an aggressive development program.
So we have seen organizations who say, "Well, I did that at Big Pharma Company X, and that's how I want to develop this product". And I've said, "You're in a company of 3 people. You don't have the funding or the time to be able to develop your product as if you were at Big Pharma X. We need a lean and aggressive development program, something that survives the red face test. Something that is data driven and something that ensures you're moving at the right pace, all at the same time with your non-clinical data package, your CMC package, your clinical package, as well as regulatory and commercial."
We have seen companies that have incredibly promising products. One we worked with that had an oncology product for an unmet need, and everything was on point. They applied for a breakthrough designation, and they didn't get it because their CMC was 12 months behind. That's a place where we don't want to be. So making sure that your regulatory and development organization has that proven track record helps you ensure that your aggressive development program is going to be able to have everything moving at the same pace, and that your development program is lean and nimble.
We get a lot of companies who come to us and say, well, a nonclinical CRO has told us we need to do 27 nonclinical studies. I say, "Well, yes, and you can do that. That's a fantastic package. But you don't need to do that to support where you're headed with your product. Let's talk about how we can do a limited package and progress further faster."
We've also seen places where companies have a great product. We're very excited about its potential, and because they're not performing essentially under an aggressive development program they run out of money, and that product dies on the vine. That is heartbreaking because patients don't get the treatments that they need.
Understanding companies, goals and objectives and risk tolerance. This is important for your regulatory team. We can propose any kind of development plan you'd like. But if it's too risky for you, that's not gonna work. If it's not risky enough, that's not gonna work. And if it doesn't align with what you're trying to do as a company, and what you're trying to do with your product, that's also not gonna work. So, being open and honest with your your team about what you want to accomplish, and your risk tolerance is incredibly important to being ultimately successful.
Understanding the business and commercial value of your product. We had one company that said, "We want to develop this lifesaving product, and we don't want anybody to have to pay for it." We think that's incredibly admirable. We love that idea. They could not get investment because no investor was willing to do that for no return.
Strong and experienced product leadership is fairly self-explanatory. But you need somebody to lead your teams to make sure that all the toes are pointing in the right direction, and I think Toban is going to talk about this a little bit later. We have seen incredible success and efficiency when small companies get a document management system in place the earlier the better, because that enables everyone to work from a common repository. There's no issue with losing documents. What version the document is or finalizing documents...Everything's in one streamlined place.
And then publishing. We're asked this all the time. "Should we bring publishing in house and do our own publishing, or should we outsource that?" I'm happy to go into that in much, much more detail later. But essentially, unless you're doing 200 submissions yourself in-house, you probably are better positioned to have that be with a partner. And the reason for that is because publishing, like anything else, is an expertise. It's a science. It changes and evolves over time. And having an expert in that place is gonna save you a lot of headache.
Alrighty. So 2 case studies. This is something that we experienced in working with our document management system of what can go right, and then we'll show you what can go wrong in a bit if you don't have one. So compliance system and processes go a long way.
We were working with a 5-person ex-US company. We're preparing an NDA. It was a medium-sized NDA. They had no document management system prior to phase 2. They were doing all their work ex-US.They had several locations throughout the world, and different people in different locations were working on different parts of the NDA. Interestingly, the Head of Regulatory Affairs at the sponsor organization left the company 2 months before the NDA went in. We thought it might be a challenge, but the reality was that the processes and the compliant document management system that we had set up made this seamless. The new Head of Regulatory came right in. It was obvious what needed to be done, and we were able to finish preparing that NDA, we were able to get it submitted, and it got a 1st round approval. Very exciting success story.
What can happen when it goes wrong? Well, when it goes wrong, it can go really wrong. So this is a situation where we were working with a US-based small company. They were conducting a phase 2 efficacy and safety trial in Canada. They terminated this study for business reasons. Health authority audited them. The company couldn't find source documentation. They didn't have a document management system in place, to add to their problems. A key team member was disgruntled and they were set up to cause major problems with the company because they had a lot of source files on their computer. And they destroyed their computer. So all those records were lost. Health authority ultimately issued a non-compliance letter. And this cost this company years of going off their path and not developing their products and spending the money that they wanted to put toward their product development into remediation activities, and it damaged the company's reputation. So, document management systems and good processes (in addition to finding the right partner to help you through your development) can make all the difference.
Kevin Tate: Wow, yeah, those 2 stories kinda speak for themselves. Thank you. Lisa. So much, so much to think about in there. And I think so much that relates to both the strategy and then the, you know, execution and path for a company that is bringing a product to market. Part of what I want to ask is, when's the right approach, or when's the right time to engage a regulatory partner? You know, when there's a lot here to think about but budgets are limited. So when when's the right time to invest in this type of relationship?
Lisa VanLuvanee: So we often will say it's never too early. But when you engage that regulatory partner, you want to make sure that you're getting right-sized guidance. So if we talk to an organization that hasn't completed their non-clinical testing, if they haven't selected their product candidate, we're happy to have conversations with them about what the next steps might look like, so that they can guide their current work and planning. So it's a small amount of discussion with your regulatory provider, but that discussion can set you on the right pathway, so that you're not doing too much. Without a doubt, if your interest is to talk with the FDA, you want to engage someone at least 6 months in advance.
Kevin Tate: Gotcha! You used a phrase in there that I really liked, you know, making sure you have an approach that's gonna, "Get you further and get you further with less". And I think such an important reality and mindset a as a regulatory leader. Any advice for how that regulatory leader can set expectations with their executive team about how they're gonna do that, and and what is required from a budgeting standpoint? How do you teach the rest of your exec team what to expect as a Reg leader?
Lisa VanLuvanee: Oh, that's such a great question. And I probably should add that actually to my pillars of success, because ultimately success for the team working on developing the product is going to be directly related to how they can sell that work and the progress that's being made to that board and to all the investors. So, working with the regulatory team that can provide not just regulatory guidance, but again, cost estimates and timelines, even if approximate, can help set expectations for those people who are making financial decisions about development.
Kevin Tate: Excellent. Thank you. All right, we're gonna hand the time now to Toban, who's gonna kinda take us to the the next step where now they've they've got a process and a team that's forming. And they're looking to put technology to work in the right way to help scale those operations. Toban?
Toban Zolman: Yeah, thanks. I'll start just by framing very briefly and at a high level what Kivo does, so that it gives you some context for how we how we think about and talk about this stuff. So to begin, you know, Kivo is built on a compliant DMS. We have a full Part-11 and Annex 11 Compliant document management system, e-signatures, workflows, everything built in. On top of that, we layer in fit-for-purpose modules that align to Regulatory, Clinical, and Quality. You can see specifically on the regulatory side, we've got obviously all of the document management pieces for regulatory documents. Authoring templates that follow ICH granularity and then a host of tools that are really focused on Submission Assembly, working directly with publishing partners, ECTD viewing, etc, and then traditional RIM features around correspondence and commitment tracking, things of that sort.
One of the things that we do at Kivo that is differentiated is this top layer where we really focus on the process that you're going to follow. And so we've kind of baked into Kivo project management capabilities. So think of it as like a Asana or Monday.com-style project management that has direct visibility into regulatory and into the underlying documents to kind of give you the ability to manage all of that. So I think that kind of project or process perspective in the product carries through. And you'll hear me talk about that today, in terms of how we really think about how a RegOps team is going to get a submission into the agency, manage that over time, etc. So that maybe gives you some some perspective or orientation to to what I'm gonna talk about today.
What I want to focus on 1st is really how to go about building a process. And I'll anchor this a little bit based on my perspective. So we've got customers at Kivo that are as small as 4 employees, and I've worked also with Tier 1 pharma building global RegOps processes across 12 global sites. And you know, 30 god-awful days and windowless conference rooms developing said process. So I've seen the spectrum there. And really, what I want to talk about here is - if you're an emerging company, maybe working on your 1st or one of your 1st submissions, how do you go about doing that? These first bullet points here are super critical to that.
First is, define a process early. And it doesn't have to be perfect. You can iterate on it. But putting a stake in the ground on process is super critical. I'm in about 3-4 kickoffs a month at this point, typically with companies that have never done an IND, and I can tell very quickly when we are onboarding folks to begin authoring the IND from, you know, CMC, non-clinical, clinical folks, how that process is going to go. So usually, if we have an hour of time blocked out to train them on process and how to use Kivo, if I speak at all in the 1st 30 minutes of that...things aren't going well. The reason for that is really, what that initial training should be focused on is what your process is internally in that company to author the content. It should have nothing to do with the tools. And anytime it is tool-centric, ultimately it becomes problematic.
What I see effective sponsors doing is mapping a process that focuses on how content and ownership gets handed off between groups. If you've got a hundred people or less in the organization really micromanaging how CMC does their work, or how clinical does their work, is not where you should be when it comes to submissions. It should really be the handoff from one department to another, the handoff from clinical to regulatory, etc. Because that's really where there is (let's be honest) tension in the process where there has to be formality. If you have a department of less than half a dozen people, that process can often be turning to your colleague and asking a question or using Teams. It doesn't have to be a super elaborate, overwrought process with multiple handoffs and reviews. Keep it simple.Keep it simple.
And if you find instances where you have repeatable challenges, that's when you then formalize the process. So that's why I say, define that process early. Iterate on it. And what you're iterating on - any failures, gaps, if you miss a deadline - that's usually an indication that you can go back and review that in Kivo.
You know, we've blended the Life Sciences viewpoint with the enterprise SaaS viewpoint. Since a lot of us have kind of worked in and out of Life Sciences, we focus a lot on the lean methodology, doing retrospectives, doing 5 whys. So when there's a failure, when there's a challenge, formalize that, you know? Do 5 whys to understand what the root cause of that was, and then make a small adjustment to your process to allow for that.
The final thing I want to say on the slide here is, when you're a small company and you are relying heavily on partners, whether that's Reg Affairs, RegOps, CROs, medical writers, you name it...Most of our customers, if you look at their Kivo accounts, it's probably 3:1 for every employee that the sponsor has in Kivo. They have 3 other accounts from partners, and the number of times we get into a kickoff meeting and find out that none of the contract medical writers they've hired have Word licenses, have corporate email addresses and can't access systems - not just Kivo, but kind of basic systems...It's very, very common. There needs to be alignment not just in process, but just in basic access permissions, IT infrastructure ,to ensure that this constellation of partners around you can all access the same material at the same time and have the right privileges in order to get the work done.
Final thing I'll say on this is when a document is approved, work is not done. Ultimately this has to be published and go to the regulatory agency. I see an awful lot of processes that really stop with document approval, and "hand wavy" it just appears at the FDA. Don't "hand wavy" over the "and then appears to the FDA" part. You'll likely, to Lisa's point, be working with a publishing partner. In fact, at Kivo, since we focus on emerging companies, we haven't even built a publishing tool, because we don't believe smaller companies should even worry about publishing until you are at kind of that multi-submission-a-week threshold, you know, 200 submissions a year as Lisa framed it, and that's really pretty accurate. It just doesn't pencil from a cost or a expertise standpoint to scale your group to do in-house publishing until that point, which is totally fine. It just means you need to be able to define a process for how all of your content goes to that publishing group, what their responsibility is in terms of taking that through publishing, how they're going to hand it back to you, how you're going to facilitate QC of that before it ultimately goes into the agency.
So, you know, to put a bow around this: define an imperfect process early, iterate on it. But make sure that you think about that imperfect process in a holistic fashion that really goes, you know, not just from the initial draft of the document through approval, but through publishing and quite frankly through the overall submission lifecycle. Because all of this content is going to get lifecycled in future sequences. And you need to be able to handle that.
So that's how we talk about kind of optimizing your process. But if you apply that to an individual submission, fundamentally what we're talking about is project management.I think it's super important to frame each submission as a project and treat it as such, with very explicit milestones, deadlines, gates, whatever kind of project management concepts you want to apply to it. And really, your project plan for a submission is just as important as your content plan. In fact, we don't even distinguish between those in our software. We treat our project management tool as effectively a living, content plan where that where you can track all of this, and it's super critical that the person who is running your project is someone in your organization who is on point and actually understands what is going into the submission.
It's too common where I'm involved in one of these IND kickoffs, and the person from the sponsor who is on point for the submission fundamentally doesn't understand what goes into the submission! Has never seen an ECTD has never participated in one. If you don't have that expertise in house that's fine. Be transparent and honest about that, and bring in external resources to help execute on that submission, execute on that project in a way that you can actually hit your timelines and your deliverables.
I think Kevin has a couple of views of our software teed up. My intent is to not make this a commercial for Kivo, but really just to kind of articulate how we think about this work getting done in the system. So this is an example of IND project that we have in Kivo. If we take a look here, maybe at 3.2.1 facilities and equipment. You can see kind of how we go about doing this. And I really, what I want to show here is not to look at Kivo. But really, these are the things that you need to track. So as an example: when we think about content in the system or content that's going into a submission, we're very explicit about the workflow that needs to happen for that in order for it to be completed. So in this case we have a task that represents this
3.2.1 granule for facilities and equipment. If you look at the bottom of this pane here, we literally link this to the documents in Kivo, so that you can see where it's at. And if that document is approved or not we build a checklist here that every document needs to pass through, and even identify how long those steps are going to take. We do all of this so that for everything that's going into a submission, you have an accurate representation of how long it's going to take that document to get to an approved state where it can go into the submission.
And if you have dependencies on that, you can understand what those are. We are very specific when it comes to things like dependencies, and you should be as well, even if you're doing this in Microsoft project, or something where we don't just show dependencies from one document to another, but we can literally structure those. So that when a document is, let's say, ready for review or past a certain draft step that you can then trigger a follow-on task. So, as an example, if you have a CSR, you could start authoring some of the summary documents related to that before it gets approved and the content is in a final state. So really understanding in your submission how all of those dependencies are going to work gives you an accurate representation of overall timeframe and makes that possible to manage.
We also have a host of reports that that we built in. One of the things that we have found that is critical is really offering visibility across the organization. This is an example here of a regulatory project management dashboard, so that you can look at any given area. CMC. Nonclinical, etc. See how many documents are approved and draft haven't been started, understand resource levels. So you can start to see, "Holy cow. Teresa has 45 documents assigned to her. We should shift that workload," or whatever the case may be. Understanding not just the overall status but the implications from individual to individual are key.
The final thing I'll say is, we do a lot of work directly with our customers, building very specific reports that literally let them dig in and understand, "Okay, where is a document at in any given state," so that you don't have to go chasing everyone down, asking, "Hey, where are you at?" On the cover letter, or the protocol, or whatever it is, you can literally leverage reporting tools like you can see here to understand exactly is someone in progress on a document? Have they already completed it? Is it in review? Is it approved? etc?
So all of this is a way to say that what really makes customers successful from what we are seeing is understanding how they're going to work with partners and then generating transparency internally in order to really drive successful timeframes. I'll talk through a case study on this and and I'll be honest, there's probably half a dozen customers that I could have talked about who have followed a similar pattern.
This is a a company with fewer than 75 internal employees, probably an equal number of of partners that they're working with, kicking off their first major IND with the second one right behind it. They ran all of this with a newly scaled team. So they secured funding, hired to execute on this...virtually everything. It was green field, and they completed the IND in 8 months. I'm not saying that's good or bad. That's just kind of the timeframe it took them to do that with this team, and here's what what worked well with them.
The first thing is, they consolidated all of their project management tools. In this case they happen to use Kivo. That's not really the point. I think the point is to have a single source of truth for how you're managing your project. The number of times we talked to sponsors...they've got 10 employees, and one group is using SmartSheets, the other is using Microsoft Project...They're not aligned. They're not synced. There is no source of truth for deadlines or milestones, no single source of truth for the project.
The second thing that they did that was super critical; they built really consistent reporting, and they tracked the same progress and KPIs during the entire submission, or entire project is probably a better way of framing it. So they were able to look at how many documents for any given section or milestone were in progress, how many were in review, how many were approved, how many were handed off to publishing, and literally could reflect that in charts and see stuff burn down as they moved through milestones. If doing that is hard, that doesn't mean you shouldn't do it. That means you should focus on tools that make it easier versus not tracking it. So this is an area where we were able to help them by building reports that helped accelerate that and create visibility.
I would also say, defining milestones and communicating those early and use those as forcing functions to gate the overall schedule. What I mean by that is if you miss very early timeframes on, like, you know, getting nonclinical stuff in, or authoring CMC pieces, that cascades. So you need to understand what your ultimate timeframe is, and then how you are progressing to it. If you're missing those earlier things, you can't just magically make the time up. I mean frankly, your velocity is your velocity, and if it's slower than you estimated, you need to bring more resources in, or you need to change something in that dynamic to accelerate it. It can't just be everyone's gonna work nights and weekends. That only goes so far at some level. This is a resource and velocity issue that you have to be honest about. As I said, pay close attention to dependencies. You can really get specific on how those work if you're dependent on something being approved versus in a draft.
And the final thing is, they really committed to training team members and doing it consistently. So they were very much on this iterative path; define a process, run with it for a period of time, typically about a month, optimize it, run with it for a period of time, optimize it in every step. The way they retrained folks on what was happening, by the end those trainings were 15-20 min. This wasn't a huge time commitment, but it just constantly improved and iterated as they went. So from my perspective, that's the way to do it. And what ultimately drives process optimization and accuracy in your timeframe.
Kevin Tate: Thank you, Toban. That was that was great. We've had a number of questions come in through the chat and through the QA. I invite you to lob in more, as we have a few minutes here at the end. Toban, you said something tat was right on point, which is, make sure that your process is driving your tools and not the other way around. But I feel like we often see regulatory leaders come into a situation where there's existing tools, and maybe an existing document or file system, that can be a bit of a mess. So unfortunately, they're in a spot where you kinda need to get the house in order to then be able to put process ahead of tools. And it depends right? But I think we've all seen that, so recognizing that that's just a reality. What advice would you have for those Reg leaders as they think about sort of, you know, getting in a place with the process that can drive the tools?
Toban Zolman: Yeah, so it's a good question, and I'll be honest, I have said on webinars both to define the process and then shape the tool, and I've also said for small companies you don't have that luxury. You need to pick a tool that solves your needs and figure out how you adapt your process to it. I think the reality is, is probably somewhere in the middle, and what I mean by that is, your house has to be in order in order to be compliant and and frankly just in order to to manage life cycle over time. You need a document management system. It needs to be Part-11 Compliant etc, etc.
What I would say is, it is a key component of success in the organizations that I've worked with who define a process. And look, the reality is that process is going to be somewhat dependent on what the software you pick can do. But the key thing is to have a process. You can't do a kickoff meeting, and it is "We are using Kivo to do this. Tell us how Kivo works, and we'll follow that." That's that's the tool. That's not the process, even though the tool is going to shape your process. So you know, one of the things that that we push our customers to do as much as we can is define a subset of folks in the organization, typically some cross functional representation, and hammer that handoff process and authoring process out. And then we map how we're gonna train people to use Kivo in that process. And that could be true if you're using a different software platform or using even something off the shelf like Sharepoint or something that. You can still define a process and define how everyone is going to work through that with the technology that you have at your disposal.
Kevin Tate: That makes sense. So kind of zooming back up to our overall theme...How do you bring the right partners and technology to bear in the way things work today? Lisa, that's obviously a big, a big part of your focus as well. I feel like we touched on the theme of decentralized teams and the fact that everybody is working in a distributed way these days. But I feel like that's such a big factor in how work gets done today. And it's so different than it was even 5 years ago. Looking through that lens for a moment, how do you think about working with partners and working with these technology assets? How does being a virtual and distributed team change that? Or what should what should teams be thinking about, given that everybody's working remotely? Lisa, any thoughts on that?
Lisa VanLuvanee: So, Facet uses Kivo. One of the things I love about Kivo, and has made all the difference in the world, is that you have the ability to have multiple people contribute to document content simultaneously. So you can open a collaboration, and whether I'm working at 2am or I'm working during normal US East Coast business hours, doesn't matter. Anybody who needs to contribute to that document can work whenever they need to. They can communicate within collaboration and ask questions. You can resolve comments dynamically. It makes all the difference in the world to have that virtual room. In the previous days, we used to just bring the entire team together into a room and say, "All right, we're not letting anybody leave until the document is done."This provides a current way to solve that distributed problem very eloquently and in a compliant way.
Toban Zolman: You brought up how we do it in Kivo...I would just say, from a from a product perspective, one of the things that we've learned from watching how our customers get work done is there really are 2 models. There is a, "let's create a virtual environment where people can simulate the same sort of work that they used to do in a conference room, together with the documents up on a projector." So how can we facilitate that? And also, how can we facilitate truly asynchronous work? And so I think both of those models ultimately are how documents get done that are going into a submission. You really want to define a process and have tools in place that support both of those workstreams and do that in a fairly equivalent way. So it's not, like, you know, working on a document together as a second class citizen to doing stuff asynchronously, because you're going to find that many, many documents go through both processes, and both the process management and the document management needs to support that.
Kevin Tate: This is this is probably our last question for today... As we explore how how to best put to work the right types of consulting partners and regulatory expertise and the right types of technology to fit your process, I think a lot of our audience might be a couple of steps ahead of that, right? So they're starting to think about when the time comes, how do I make sure I do that in the right way? And as we all know, when the time comes, it's crunch time, and it's really hard to get ahead of the process and the team. So my question would be, what advice would you have for teams that know they're gonna be looking at partners and technology like this in the near or midterm? And what should they be thinking about now to prepare for that? Toban, you want to take the first whack?
Toban Zolman: I guess I would frame it in 2 ways. One is if you know you're going to cross that threshold and implement technology, doing it obviously earlier is better, purely from a data migration standpoint. The fewer documents you have to worry about and and deal with, the easier and cheaper it is. But I think there's kind of a bigger aspect here that's not just tactical, but really understanding what your organization's goals are. So, Kevin, you talked early on about, you know the train versus the the highway of electric cars and how that model is shifted. There is a fundamental shift in the business model of these early stage companies, and the drive to get to a product pipeline that can be leveraged, either by selling it, licensing it, whatever that is, that is much more important than building a company at scale. The priorities are different. It means your documents and data are more important than your departments, because that is the asset that you're going to sell license partner with, etc. That means you need to be diligence ready. Stuff needs to be organized. You need a way to hand that off. So I think it's important, as I see folks move from Tier 1 companies to emerging companies, they don't always shift that mindset that they're not building a department or a company. They're building an asset that is ultimately going to be sold, and sold way faster than it traditionally would have been, you know, post approval. So I think that's just an important nuance to understand. The goals are different. The finish line is different.
Kevin Tate: Lisa, any advice for what they should be thinking about now?
Lisa VanLuvanee: Yeah, I'll add to that. So you know, because the goals are different, the decision-making may be different. For example, we worked with a customer who said, "We need to have GMP product in order to to go forward." And our position was that, "Well, no, you don't for your first-in-human trial. That wouldn't be required for this type of product. Financially, you don't have the backing, nor do you have the time to get to GMP product. Get to proof of concept, and then allow the acquirer to do the work to establish GMP product." And so don't hire a CMC person. At this stage, use consulting to your advantage to get what you need when you need it, and nothing more.
We see similar things with hiring chief medical officers. They're early in development. They probably don't need a chief medical officer before they're in patients. Toban concepts a different way from resourcing and decision-making about who you're going to to provide support. But also what systems you're going to put in place. You need to think about that with the end in mind, because you may make different decisions about your personnel as well as the systems that you decide to use.
Kevin Tate: Hmm! Great great points. Thank you. Thank you so much, Toban and Lisa. Thank you so much to our audience. And we'll see you next time. Thanks for joining.
Toban Zolman: Thanks, everyone.
Lisa VanLuvanee: Thanks, everyone.