Episode Transcript
Kirsten Carroll.
Welcome to MedtechWOMEN Talks.
We are here today at DeviceTalks West, October
18 and 19th, 2023 in Santa Clara.
Really appreciate you spending your time with
us today.
Thank you so much for having me.
I’m really excited to do this.
So, I want to take it back.
This is a really different narrative that
we’re going to have today where you didn’t
have a kind of traditional, “I had an idea.
I developed a product.
I went through that entire lifecycle.
Now I’m a CEO, and I’ve moved on from
there.”
I mean, you’ve been with the Large OEMs
- and I’ll have you go into that shortly
- you went from Large OEM to what would have
been considered a startup, as we know Imperative
Care, which is not a startup any longer, to
pivoting a little bit outside of Medtech into
Kandu Health.
So, can you take us back?
How did you get into medical devices?
Take it away, Kirsten.
Yeah, so I went to college thinking I was
going to be an orthopedic surgeon.
I was a swimmer.
I had shoulder injuries all the time.
I was going to become an orthopedic surgeon,
and I was going to fix people like me.
And I took a History of Medicine class my
sophomore year that got me thinking maybe
I didn’t want to practice medicine.
I had a shoulder injury that sort of ended
my swimming career and there was a brand new
major, and it was a major in Biomedical Engineering.
And I thought, I want to do that.
I want to do biomedical engineering, and I
want to work on the technologies that clinicians
use to treat their patients.
I got to take a wonderful class on creativity
and product design, a gentleman named Henry
Belanos, who was an extraordinary early mentor
to me and has since passed on.
But I sort of got this idea, which was a bit
strange at this time, when med device wasn’t
that big a thing, that I was going to be in
medical devices.
It was a brand-new major.
The classes were all sort of clewed together
in a way that I was never in the core of the
thing I knew well.
I was taking mechanical engineering with the
mechi majors, and I was taking fluid dynamics,
and I was taking differential equations.
I was taking biology.
And this led to me deciding I wasn’t a very
good engineer and there wasn’t a career
path in that.
And I got really lucky in falling into product
management at a little startup company that
was working in embolic protection.
I remember before I graduated, I flew and
did a weekend course on sort of CFR design
control regulation and what does it mean to
work in design control?
And then I was off to the races of this tiny
little startup.
I decided pretty quickly that I needed more
education to be doing what I was doing and
was lucky enough to get into the MBA MPH program
at UC Berkeley.
So, I did that.
It was a five-semester program.
But I think the lasting thing that had happened
in my early experience was developing this
passion for neurovascular care.
So moving up from the carotids into the brain.
My entire essay when I applied to UC Berkeley,
and it said, what do you want to do with your
career?
I want to make stroke treatable.
So, there was one company I felt like was
really focused on that, and that was Boston
Scientific.
And I called up someone I knew there, talked
my way into a summer internship, and that
was the next 15 years of my life with that
group; and I love them dearly, in spite of
having advanced to the next thing in my career.
So, it was eight years at Boston Scientific
Neurovascular, and then they divested our
division and sold it to Stryker Neurovascular.
So, then another seven years at Stryker before
I went on this path now with Imperative Care
and Kandu.
I’m blown away.
I have not heard the story yet of kind of
piecing together a medical technology major.
I have many questions that came from that
question.
Was there a specific course or class that
you took when you were piecing it together
that helped you validate that medical technology
is a space you wanted to continue exploring?
Again, it was this creativity and product
design class with Henry Belanos, and he was
a medical device person.
He had been VP of R&D at US Surgical.
He did a lot of the early stapling IP, and
so Henry is the one who made me aware that
this was a possibility.
But then, of course, I had no idea what product
management was.
I sort of fell into that, and I think if I
look back academically if I wasn’t going
to be a doctor, I was going to be a writer.
It was a really hard decision to be a science
major and not an English major.
And this early career of product management
allowed me to bring these things together.
This ability to speak R&D and speak engineering
and the ability to communicate.
And such a big part of my role in product
management was sort of understanding what
the clinicians need, breathing that in and
then breathing it out and packaging it up
in a way that the engineers could use it.
My job was to define problems in such a way
that the engineers could go find a million
creative ways to solve that problem because
they understood it so well, but not dictating
the solution to them.
Right?
And there’s an art in that in problem definition
and not dictating a solution.
Two very powerful skill sets.
Yeah.
That clearly led to an incredibly successful
career in medical technology.
I want to take a step away from your experience
and talk a little bit about the medical device
product development cycle itself.
So where would you say your role, which is
kind of hard to define based off of your incredible
experience.
But if you could try to define it - could
you ignore your title, ignore the company
that you work with, Kandu Health - how would
you define your role?
Yeah, and I think we do need to separate those
things because a big part of my career right
now as a first-time CEO is moving on from
the role that I’ve traditionally done, where
I sort of made a name for myself.
So, let’s talk about sort of what I built
my career and reputation on and not what I’m
doing as CEO.
So, it’s really interesting, and this is
something I’ve learned as I’ve transitioned
into digital health and working with tech,
and that it’s unique in med device that
product management sits in marketing instead
of sitting in R&D.
So in tech, product management sits with engineering.
And marketing is more about branding and downstream
demand, generation, selling, et cetera.
In medical device product management, this
sort of lifecycle approach sits in the marketing
department.
And that means that as an exceptional product
manager or director of marketing or whatever
it may be, you have this incredible opportunity
to stay with the lifecycle of the product.
And one thing I always caution if a CEO or
a division president is pressuring a marketing
team to have an exceptional, best-in-class
commercialization, if you haven’t gotten
it right from the very early understanding
of the product need and why you’re building
it and who you’re building it for, you’re
not going to have as effective a commercialization.
It starts at the very beginning in understanding
the clinical need you’re solving and understanding
the user needs of the clinicians who are touching
that product and understanding how they make
decisions.
What are the claims that I’m going to want
to be able to make about this product in two,
three years down the line to allow for an
exceptional commercialization?
Right.
And so the thing that I always did and the
thing I loved in the way they structured marketing
at the companies I was at, was that I did
get to sit with a product for years.
And so maybe I’m a little different in that
I wasn’t looking for that next job every
six months.
I wasn’t looking for that growth in my career
or my title.
I lived and breathed a single product for
five years from concept to launch.
And really got to say that was so much about
me and what I did in neuro intervention.
In particular, I got to grow up with these
physicians, right?
The ladies and gentlemen who are leading the
field now were coming out of residency as
I was starting my career.
And we all grew up together.
And I would go and I would watch their cases
and I would learn what they needed and I knew
exactly how they held their catheter and I
knew exactly what freaked them out and I knew
exactly how they got frustrated.
And all of that went into writing that initial
market spec or user needs document.
And there’s so much strategy in doing that
well, and it sets the tone for the entire
product.
Sorry, that was a long answer.
No, I mean, you’re the true embodiment of
medical technology development.
You’re from concept to commercialization.
I can feel like I won the lottery.
I love it.
I think my favorite job ever for the longest
time was being a product manager at that early
stage of my career, right.
Living and breathing with my clinicians and
my engineers and getting to do that all day
long.
Well, we’re going to definitely dig into
that.
So you said where you want to begin development
is at the beginning, of course, but you had
talked about how the early stages and the
considerations of the early stages is really
integral to the entire process.
I’m trying to understand where product development
and your role sort of fits in into the entire
cycle.
I mean, is it the cycle or is it a stage within
the cycle?
Yeah, so if we talk about the cycle, I moved
from product management and marketing into
strategic development.
And so if you think there’s a cycle in running
a business, the first one is developing your
strategy.
Do you know where to play, how to win, how
to sequence it?
Do you know the economic logic of what you’re
trying to do?
Can you articulate that?
From there, you go into portfolio planning.
What are the sets of products that I’m going
to develop to actually achieve that strategy?
What are the bets I’m going to place?
I have this many dollars put into R&D and
clinical, where are they going to go?
And then from portfolio planning, you go into
operational planning.
How am I going to resource this, right?
How many engineers on the team, how many product
managers, how many clinical team members,
et cetera, and you’re off to the races in
execution.
So there’s that overarching sort of lifecycle
management company strategy management, that
has to be done.
If you’re a product manager, you are now
given that result of that portfolio planning
and operating planning process, you are developing
a product that is intended to play this role
in the company, achieve these things.
These are the resources you’ve been given.
You have a project manager in the center who’s
organizing everybody.
But now your job as the product manager again
is to write that initial opening document
of what are the user needs that we’re deciding
to address.
And that’s a really big deal.
I have a colleague, Chad Wu, and one of my
favorite things he ever said to me is, Kirsten,
I can do anything, but I can’t do everything.
And that’s true of a product as well.
If you try to write a user needs document
for the perfect product that achieves everything
and satisfies every user, you are never going
to get to market, right?
So you have to understand who this product
is built for, which situation it’s built
for, what are the things that are absolutely
immovable and what it has to achieve, and
where can you give a little and you set that
tone and you help the whole team understand
why are we doing this?
And what does success look like?
I’m hearing a lot of collaboration and I
think that’s an incredible phrase.
You can’t do everything, right?
The product can’t do everything, the company
can’t do everything.
Exactly.
So let’s talk about collaboration.
At what point do you collaborate with the
other groups?
So, R&D, clinical affairs, engineering, at
what stage do you collaborate?
From the beginning.
From the beginning, you should have a core
team.
So while marketing or product management is
responsible for writing the user needs document,
you should never do that in a vacuum where
you’re not bouncing it off the people who
now have to take it into what is the spec
that goes with that user need, how are we
going to prove that it works?
So, a couple of my favorite things to do as
a product manager, one of them is to write
a flowchart of every single step of how this
product is going to be used, starting with
how do I identify it on the shelf, how do
I pull it off the shelf, how do I open it
right?
Every single step is an opportunity for something
to be done wrong.
Every single step is an opportunity to delight
your end user.
So you’re going to need your clinical experts
involved in understanding all those steps,
all of those techniques, all of the choices,
et cetera.
As you write a user need, you may think you’re
incredibly articulate, you may think it is
obvious what you meant.
Inevitably, an engineer reading it might have
interpreted it differently.
So when you’re developing a market spec,
you start with called a numeric, that’s
sort of a draft revision you’re working
on, and then the first time you lock it in,
that this is the market spec we’re working
off of, you go to alpha.
And Alpha means this is sort of a document
controlled, locked in thing that not just
marketing is signed off on, but R&D, clinical
regulatory.
We’ve all agreed to this set of user needs.
The very next thing that I like to do is start
talking about at the end of product development,
how are we going to prove that we actually
met these user needs?
What does that test look like?
Is it a hands on evaluation?
Is it a lab evaluation?
Is it a benchtop test?
Because when you actually start talking about
how am I going to prove it?
And what’s the claim I’m going to make,
all of a sudden you start realizing all the
places that people misunderstood, right?
Oh, you said it needed to be soft.
I thought that meant it had to be bendable.
It turns out it’s actually how hard it pokes.
Right?
A completely different understanding of what
the word soft might mean to somebody.
So the collaboration should be from day one.
And there is nothing worse than having a user
needs document or a market spec that feels
like a box checking exercise and isn’t adding
value or that people disagree with and think,
well, I want to work on a different product
than what was articulated here.
I don’t understand why I’m working on
this.
That reminds me of another point of clarification.
Can you walk me through the difference between
design verification and design validation?
Yeah, absolutely.
These are such important concepts in design
control, and there’s very different roles
for product management or marketing in each
of them.
So when you go through design control, we
just talked a lot about establishing user
needs, understanding what people need when
they use the product, and from there, your
engineers are going to translate those into
specifications.
So if I say the product needs to be able to
get to this vessel in the brain, the engineers
are going to say, well, that means it needs
to be this flexible, it needs to be this soft,
it needs to be this long.
Right?
They turn it into specifications.
So when you do design verification, you’re
proving that you meet the specification.
However that was written, the product is long
enough, it’s flexible enough, it’s soft
enough, the transitions are in the right places,
and it does that reliably every single time
that you use it.
That’s design verification.
But if you remember, we didn’t start with
a spec.
We started with a user need.
The user need was it needs to be able to get
to this part of the anatomy.
So now you have a product coming out of design
verification that meets all of the specifications,
is built and performing as intended.
The question now is, can you get to that anatomy
or does that doctor say, this feels good in
their hands?
And so that’s where design validation comes
in.
So when I said, you want to agree early on
that we all understand this user need and
we’re going to prove that we actually met
the user need, in the end, that’s design
validation.
And so that’s where if you have a really
great product manager who understands the
use environment and the users.
They’re going to work with you on what is
a legitimate design validation plan that is
going to represent the end case, represent
the people using it, and prove to ourselves
that the product we’ve built are doing the
same thing.
There’s analogy that I give sometimes for
early product managers and it’s a kind of
silly one, but let’s say somebody wants
a hot bath, right?
You have all uniformly agreed somebody wants
a hot bath.
You write in the product spec, this needs
or in the user need, this needs to be a hot
bath.
The engineers are then going to say a hot
bath is 110 degrees and then they’re going
to design the bath to be 110 degrees and they’re
going to make sure statistically they meet
110 degrees every single time.
At the end of the day, you still need to put
somebody in that bathtub and say, is this
actually hot?
You don’t need to put 200 people in the
bathtub.
You’re going to know pretty quickly after
three people get in, right?
But that’s your design validation is putting
someone in the bath and saying, is it actually
hot?
That definitely helps clarify that.
Thank you.
I had a chuckle because of the statistical
accuracy.
There are different types of people - except
for you.
I mean, we were talking about your background,
and you have two different skill sets.
You have this kind of scientific brain.
You have this humanities, humanities is what
I was trying to look for.
Engineering and sciences and humanities equal
really seeing how a product isn’t just developed,
but how it’s used.
And then the later stages of how it’s being
used.
Is it comfortable?
Is it not just meeting the goal, but is it
providing more than just that comfort?
Oh, I’m escaping the terminology.
But it’s just about, I think, whether you’re
running a company or you’re running a clinical
procedure, and particularly in stroke, where
everything is so time sensitive, being aware
of how people make decisions, are they getting
the information that they need?
Are they able to make a decision?
Do they know how to manage this product?
Well, being cognizant of that, when you’re
designing a product, are they getting the
visual, the haptic, whatever other feedback
it is, and do they know in advance how to
use it?
If I turn it this way, it’s going to do
that.
If I push it that way, it’s going to go
here, right?
But so much is not just understanding how
people touch things, but understanding how
people think and make decisions.
That’s really, really important.
That’s a much better way of putting it than
I was trying to grasp my way through.
So, it’s really trying to understand how
people think.
So, kind of into that same category.
When you test a product, I’m assuming you
have to have a diverse group of people because
people think differently, and different backgrounds
think differently and approach things differently.
So how do you manage that?
Yeah, well, so it starts with, again, knowing
which segment of users you developed this
for and you are never going to have a singular
product that everybody uniformly loves.
And so making sure that the team understands
this is the product for this type of clinician
who uses these techniques, or maybe this one
needs to bridge two or three types of clinicians
and making sure that you are bringing people
in and you know the users well enough.
I knew, and I’m not going to name names,
but I knew this is my person who is all about
feel and is an artist.
And this is my person who is all about speed
and this is my person who is all about predictability.
And they are so obviously that person.
I can bring in each of them and have them
do the evaluation.
And I know how I’m going to perform with
each of these groups.
Really targeting the right person to test
the product at the right time, that’s a
really interesting approach and one I’ve
not really heard before.
But again, I’m really trying to understand
the product development cycle.
So it’s not to say that it’s not being
done.
Yeah.
Finding the clinicians who are consistent
in what they want and who are really good
at articulating what they’re feeling, what
they need, what they like, what they don’t
like, that’s really important.
So as a product manager or a director or a
VP, anybody in med device should have that
Rolodex of the people that they know.
These are my go to people that I know.
I can call them up and have them come in and
touch my product and they’re going to give
me useful feedback in whether it’s hit the
mark and how we make it better.
There is no value in promoting a brand of
a company or a product that doesn’t actually
match what that product is delivering.
Right.
It becomes lip service, it becomes silly.
When you have a product that you say, this
is what it’s going to do, this is the role
it’s going to play in your practice, this
is how it’s going to perform, and then the
product actually does it.
It’s so powerful.
And now you have an incredible launch and
an incredible brand and something people keep
coming back to and using.
So, how do you bridge that gap?
Which part?
I mean, how do you get a product that is validated?
That It does what you say it’s going to
do.
It performs the way it’s going to perform
and then now you bring it to the end user.
So there’s one which is how do you make
sure that the product feels and performs the
way that they expect?
And that is in your design validation testing.
Again, do you have the right bench models?
Do you have the right users?
You should know your product inside out.
And better than your end users in an ideal
situation before you even bring it to them.
There’s then the piece about claims that
you’re going to make about patient outcomes,
safety and efficacy, right?
And you may need these for a number of reasons.
So that gets into your clinical evidence generation.
So when you talk about generating clinical
evidence and a strategy around that, you almost
have to start at the same place you did as
a product manager.
What are the user needs for evidence?
So why do you have clinical evidence?
You have clinical evidence to convince somebody
to make a decision.
You’re trying to convince a regulator to
let you sell this.
You’re trying to convince a payer to actually
subsidize it.
You’re trying to convince a physician to
take it off the shelf.
You’re trying to convince a hospital to
put it on the shelf.
So the first thing you have to understand
is how are each of those stakeholders making
that decision?
What is the thing that’s going to convince
my neurosurgeon to use this, my hospital administrator
to put it on the shelf, my payer to cover
it?
And then what is the evidence generation strategy
that will achieve this?
Is it a randomized prospective trial?
Is it a propensity matched analysis?
Is it anecdotal user experience And importantly,
what’s the endpoint?
Do they compare about health, economic data?
Do they care about safety data?
Do they care about clinical outcomes in terms
of ability to live your life, quality of life,
et cetera?
So you can do the exact same thing you did
in what does the product need to be, what
does the evidence need to be?
And then you don’t spend $20 million generating
clinical evidence that fails to move the needle.
Oh, that really helps clarify.
So you talked about clinical data, but what
about clinical trials.
So at what point does your role interact with
those kind of two spaces?
I can’t imagine that it’s early on, but
maybe it is.
I mean, my mantra is it’s never too early
for any of this.
So when you’re the product manager and you
write that user needs, the product needs to
do all these things, you’re also drawing
a line in the sand.
These are the claims I want to make about
my device.
So now you are already having conversations,
or you can start with your regulatory team,
your clinical team.
What is going to allow me to say that about
my device?
Is it a bench test?
Is it a clinical trial?
What does the strength of that trial need
to be?
So you likely can map out years in advance
of launching what is the trial that I’m
going to need to do?
What’s the benchtop data I’m going to
need to aggregate?
And everybody can plan that into the product
development so that you don’t have to do
it sequentially.
Now, I’ve launched the product, now I’m
going to start thinking about the claims I
want to make the claims should have been planned
at the start with the user needs, and the
evidence generation strategy should go right
along with the claims you intend to make.
So then maybe product development cycle isn’t
the right terminology, is it?
Product development spectrum?
Continuum?
I think there is a cycle.
You establish your user need, you translate
those to specifications, you verify that you
met them, you validate your manufacturing
process, you validate, you met your user needs,
you generate your evidence.
Right?
And then when the product’s in market, the
reason this becomes a cycle is inevitably
you start hearing new things about what you
need to do differently or better.
The feedback loop.
Are informing your new user needs.
So it is absolutely a cycle.
Understand your user needs, develop the product,
get it to market, prove that it’s working,
and keep feeding back on your innovation.
That’s what your FDA auditors are looking
for when they’re asking about post market
surveillance, when they’re asking about
design control.
Is this working effectively?
It’s not a cycle in terms of who’s involved
at which stage.That core team around a product,
clinical, regulatory, R&D marketing should
be a team from day one.
Once it’s to market and you’re starting
getting feedback from the users, be it clinician
or the hospitals or even what have you.
Are you involved with the new iterations of
the product or is it a new team?
Yeah, so that depends on how your company
is structured.
Some companies structure their teams around
upstream, which is developing that product,
and downstream, which is launching and sustaining
that product.
And if you’re doing that, it is important
you have really strong handoffs between those
teams because it is a cycle and people feel
ownership and passion about it.
Other companies organize around a product.
You are the product manager for this as it
goes out to market and launches and as it
comes back.
Arguably it’s a luxury to find a talented,
exceptional person who’s willing to stay
with a product for three, five, seven years
and keep doing that.
But it is possible, right?
It’s how I grew in my own career, was sticking
with products and franchises for a long time
and launching multiple products on top of
each other.
And I started out as a product manager and
then I was a group product manager, and then
I was a director.
Right.
But I did that over 15 years, eight years
really, to get to director.
And then I moved into strategic planning and
development.
You really helped connect the dots for me.
So I really appreciate your time.
Are there any last thoughts or something that
you want?
Our audience is trying to understand the medical
device product continuum.
Like I am something that you think is important
to share.
Yeah, I mean, so there’s so much that you’ll
hear in a lot of places.
I am a lover of language, and we’ve.
Talked about that I read all the time.
I love learning other languages, and I think
the greatest successes that I’ve had in
my own career in product development is not
assuming everybody is speaking the same language.
They understand what the words mean.
They understand what the attention was.
And that starts with how you talk to the clinicians
and translates into how you communicate it
to R&D and translates it in how you present
it in your collateral and materials.
But be a lover of language, right?
Explore what it means for something to be
reliable or easy or soft or flexible.
There are actually a million ways those can
be interpreted by a product team.
And so this is where sort of specificity and
intentionality serves a product manager well.
When I said this, I meant this.
This experience, this feeling, this touch.
It did not mean you need to make it nine pounds
of force and 6cm.
You as the engineer, get to figure out how
to solve this problem.
But we are all speaking the same language.
And so I guess maybe that’s my unique contribution
to all this.
And then the other one would be I think people
get very territorial.
I own the customer, I own the product, and
that’s where things break down.
So, like I was saying, when you write a market
spec, you may be responsible for authoring
it and getting it over the line.
You should be checking with my engineers.
Does this make sense to you?
Have I phrased it in a way that’s impossible?
Am I doing cross-functional reviews of this
document that’s laying the foundation of
this product in a way that everybody’s bought
into it and everybody along the way should
be doing that.
Nobody has sole ownership over any of this.
And all those perspectives on the upstream
and downstream consequences of the way you
wrote it are so powerful in getting you to
a place where you execute well.
Well, you’ve made me so incredibly happy
for sharing your time with me.
I really appreciate it.
I am a proud ambassador for lovers of language,
lovers of collaboration, and lovers of medical
technology.
Wonderful.
Thank you.
Kirsten Carroll, Kandu Health.
Thank you for joining us on MedtechWOMEN Talks.
I cannot thank you enough for your time.
Of course.
I really enjoyed it.
Thank you.
