Creating great products isn't just about product managers and their day -to -day interactions with developers.
It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers.
With the help of some boundary -pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
Hello, and welcome to another episode of the Product Thinking Podcast.
I'm excited for this podcast today because it is a great case study in how to launch zero -to -one products inside of a large organization.
Joining us today is Anissa Lourie, former senior director of product and head of women's health at Hinge Health, a $6 billion leading digital clinic transforming muscular skeletal care through innovative patient -centered solutions.
Anessa has been at the forefront of several zero -to -one products at Hinge Health.
She most recently helped to develop musculoskeletal care for seniors, a non -invasive pain management device that reduces pain and helped expand Hinge Health globally.
She also spearheaded, from idea to scale, Hinge Health's comprehensive women's pelvic health program, recognized as a world -changing idea by Fast Company.
With a career spanning startups, government agencies, and major corporations, Anessa has honed her expertise in zero -to -one product development, health equity, and leveraging technology to drive meaningful behavior change.
Today, she'll share her insights on creating impactful healthcare products, scaling innovation responsibly, and the future of women's health technology.
But before we talk to Anessa, it's time for Dear Melissa.
This is a section of the podcast where you can ask me any of your burning product management questions.
Go to dearmelissa .com and let me know what they are.
Here's this week's question.
Dear Melissa, most product talks focus on customer -facing products and how to deliver for business and users.
There are also internal products that companies built for employees.
Do you believe there is a difference in product management when it comes to B2C or B2B versus internal organizational products?
If so, why is it treated differently?
So this question is near and dear to my heart because I used to build internal products.
When I was a product manager at OpenSky, I was responsible for the entire backend platform that only our employees could see.
And I remember thinking when I was building this that I didn't need as much experimentation or as rigid of a design as we would do for the products that were being launched to our customers.
And I ran into a bunch of problems thinking that.
I found that because I just try to get things out there and optimize for what we already had, built from a UX perspective or design perspective, a lot of the people internally were having trouble executing on their jobs.
So I built a lot of the things where our buyers would upload the different types of products that people could buy through our front end of the site.
And by doing that poorly, having that UX be secondary, it slowed them down from being able to upload a lot of products.
It caused a lot of friction.
It caused people to consider if they wanted to leave their job because of the tools that they actually were using.
And a lot of companies think that they can get away with that.
Just making things that aren't great design for people internal, it doesn't matter.
It won't affect their brand.
It won't affect their reputation, but that's not true.
For myself, I learned this because I used to have a line of people at my desk saying, hey, can you fix this?
I don't know how to use this.
This is complicated over here.
I'm not able to do X, Y, and Z.
And that's when I started to realize that if I made fantastic products for the people inside our company, just like I was doing for the people who are outside our company, for our customers, that I was going to help the company grow and scale because it was going to make their lives easier.
We're going to be able to upload more products.
We're going to be able to get things out to our customers faster, deliver that value to customers faster.
And I was going to make the people who I was sitting next to happier.
And that way we would all get along and I wouldn't have to worry about them leaving.
And that's the mindset that you need to take too when it comes to building internal products.
That's what every company should look at.
Sure, there's a lot less risk when you're releasing things internally to people.
You don't have to worry about your brand reputation or things being absolutely crystal perfect.
You can also experiment a little more rapidly with things internally because you don't have to go through an immense amount of communication or rolling things back.
You can walk over and start to talk to people and explain the situations and have one -on -one conversations with them a little bit easier.
In large organizations, it could be hard to source out the people who are using your products.
You might have to go through similar customer research provisions that you would for external customers, but it's usually a lot easier to figure out who those people are and go visit them or get them on the phone.
We have a relationship.
You work for the company there.
So when it comes to product management, the whole philosophy and the motions that you go through should be exactly the same.
I want to make sure that I'm building great products that produce a measurable outcome for my customers and my users.
Now, my customers or users might be internal people, but it still means that they need outcomes.
And those outcomes affect our business.
It can affect the cost of our business.
It can affect employee retention.
It can affect the way that people communicate or collaborate with other departments.
All of these things go to making your company successful.
Just because it's internal doesn't mean that it doesn't contribute to the success of your company.
Now, would I go through as many, let's say, stage gates, refinement, testing, considerations around experiments that I would for an external launch?
You have a little more wiggle room here.
You should still be experimenting, but maybe you can go talk to the customers, your internal employees, right?
And talk to them about what you're going to launch, have them test it out a little more easier than it would be to go identify and find your outside customers, but you should still be following those things.
You should still be de -risking your products.
What happens is if you don't do that and you launch things that people don't want to use, you could be causing massive problems for the operations of your business.
You don't want employee churn.
You do not want to make people unhappy with their jobs.
And if they have to use your product every single day, and it sucks, they're going to be unhappy.
So we should not be saying, oh, just because they're internal, we're not going to build them great products.
So I think there are considerations that change around how you mitigate risk and how you think about the design of internal products.
But you should still be going through the same basics of product management.
When it comes to things like building a business case, launching a strategy for this, you still need that.
I see so many companies not think through the strategies of their internal tools.
They duplicate internal tools all the time.
They make them extremely hard to use.
They never follow up and iterate on them.
And it causes a lot of friction.
It causes a lot of waste.
So we should really be paying attention to the things we do internally just as much as we are for customers out there.
And just because you are installing something, let's say, that a vendor provided, like a Salesforce or some other product, doesn't mean that you don't have to go through discovery and figure out if it's solving the problems for your users.
The way you implement it or execute on it might be slightly different, but you still need to manage all of those things to make sure it's getting you the right value.
And then consider the trade -offs in those build versus buy situations, just like you would for an external facing product as well.
So I do believe that we all need to start caring a little bit more about internal tools and the way that we build them.
We might be able to take a little more risk there, that something's not perfect to put it out internally, but we should still be striving to create great experiences and great products for the people who work in our companies as well.
so I hope that helps, and again, if you have any questions for me, go to DearMelissa .com let me know what they are, now let's go talk to Anessa are you eager to dive into the world of angel investing?
I was too, but I wasn't sure how to get started, I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side, this is why I joined Hustle Fund's angel squad, they don't just bring you opportunities to invest in early stage companies, they
provide an entire education on how professional investors think about which companies to fund.
Product leaders make fantastic angel investors.
And if you're interested in joining me at Angel Squad, you can learn more at hustlefund .vc .mp.
Find the link in our show notes.
Welcome, Vanessa. It's great to have you on the podcast.
Thank you so much for having me.
So let's kick things off by exploring your professional journey.
Your career spans startups, government agencies, large corporations.
could you share a little bit about your professional journey and the experiences that have shaped your approach to product management?
My love for product and using product to solve some of the most intractable problems facing society started in a relatively ironic place.
I was working as a political appointee for the mayor of Washington, D .C.
This was a few years after college, and I was responsible for issues related to health and human services.
It's responsible for helping to house thousands of chronically homeless individuals from the street into permanent supportive housing, from improving the processes for applying and getting public assistance.
And in order to do some of these key things, what we ended up having to do was we had to build technology.
We had to build pretty simple tech, but in order to understand who was unhoused, who was the case management, what was the housing, where was the furniture, What was the state of the housing?
Where were all the pieces?
So we can coordinate with the relevant agencies in a timely manner to get the work done.
And it became really interesting to me.
So in order to do this really key work, we needed to build technology.
We needed to build technology to understand who wasn't housed and needed housing.
Who was their case manager?
What was their status of their paperwork?
Where was the housing available?
What was the status of the housing, the furniture, all of the various pieces that need to come together to create a wraparound experience?
And without that tech, it would have been impossible for us to achieve dramatic reductions in street homelessness.
And I became so interested in how do you use this tech to solve problems that you couldn't solve without it.
That led me to graduate school.
I went to business school at Harvard Business School and Kennedy School for Public Policy, and I was really looking at these problems from two lenses.
What is the policy side of healthcare and big issues facing our society, and how do you apply business innovation, design thinking, to these problems?
And I put on the lens of the business person in policy and the policy person in business and have then and since for the last 13 years worked as a product leader at various venture -funded tech startups, mostly at the intersection of health and wellness, using technology to solve problems that are really
hard to solve. That is quite a journey.
And I imagine working in the government agencies is nothing like working in these venture -backed industries either.
So I'm curious to dive in a little bit more there in a minute.
But first, you describe yourself as a mission -driven, particularly passionate about advancing women's health and health equity.
What's it mean to you to work in a space where your mission aligns so closely with the products you're building?
And these have a lot of gravitas to them too.
And how does that impact your day -to -day work as a product leader and the decisions you make there?
I think as a product leader, particularly someone building new product, you are the founder of a company.
I would think of yourself as a founder.
And when you are a founder out raising capital, your conviction about the problem and the problem space really matters.
It comes through. It comes through in how you can motivate the team and how you can speak to others and get them on board because generally that's driven from insight in the market and personal experience that conviction shows through.
Secondly, you can really become almost like obsessed with understanding the problem space.
So for me, women's health is something that I live and breathe both kind of personally but also academically.
Like I will read the content, I will study the landscape, I will immerse myself in the space whether I'm working in it or not.
And that understanding gives really interesting insights into the products and the work that you're building.
And finally, being immersed in a particular space gives you strong intuition on where you think the market is moving, what future should exist that doesn't yet exist.
and it allows you to push forward when you face so many walls, when you face so many hardships and you don't just say, okay, well, I have all of this setback and this other setback and this person said no and et cetera, et cetera.
And it just kind of piles up against you.
You're there to break those walls.
You use that conviction, that motivation, that passion to drive you further instead of just having the wall and the weight of that keep you stuck in a specific place.
With something like women's health that you're talking about as well, you immersed yourself, you learned everything about it.
There's a big debate in product management about domain expertise or knowing the area that you're working in.
What's your advice for product managers out there to get up to speed on the areas that they're working in?
And how did you immerse yourself in these areas and learn?
Yeah, great question.
So I think that there's, so there's the advice and how I did it.
And then there's also the cautionary bit, I'll tell you.
So one thing to be cautious about is to not let your own experience and your own perspective with a particular issue or condition near or essentially become the thing that you are uniquely or only solving.
Sometimes that intuition is right and sometimes that intuition is wrong.
And I'll give you an example.
In the women's pelvic health space and we created a program at Hinge Health focused on women's pelvic health and supporting women's pelvic health digitally.
Initially, in the early research phases, I thought that our primary user and persona was going to be a woman who was pregnant or postpartum and addressing their pelvic health needs.
I thought that because that was my community and I had also experienced pelvic health issues after my first pregnancy.
So like the people I was listening to, the people I was surrounded by who had these issues were pregnant or postpartum.
But once we launched the program at scale, actually less than 10 % of our users were women who were pregnant and postpartum.
And it was just a really interesting realization.
Yes, we created a unique program for them, but my conception of the market is going to look like this was so skewed in my own personal experience that I needed to like look at the early data to zoom out and ensure that we were actually meeting the broader and unique needs of the population that we were serving.
So that's kind of the cautionary side.
The side to really focus on it, how do you immerse yourself in this space, could be one of a few ways.
One is what is the startup or tech ecosystem in that place?
So who is building products in, say, women's health, whether it's software or hardware?
Are you following them?
Are you understanding how they're evolving, what folks are talking about?
What is the broader academic context in this space?
What is the research saying in the particular area that you're following?
And then the broader kind of political, social policy context.
So reading literally academic articles on the particular content and also following social policy is really important to understand.
And then the other piece is to look at your user and your buyer perspective.
Who is buying products in this realm and what are they thinking and what do they need to learn?
What questions are they asking?
And then what is the pain point that the users and or the people treating them, what are they feeling?
Having a really holistic, rounded perspective allows you to just kind of draw on different insights at different points of time.
I want to dive into the women's pelvic health program that you launched at Hinge Health.
I always love when we launch new products in such a regulated industry or something that's so high risk as healthcare, because I think there's a lot to learn there.
Can you walk us through a little bit about how that concept came about and what you did to test it, validate it, and then launch it?
So I would say that there were a few key phases in the development of the Pelvic Health Program at Hinge Health.
And now I think this is the largest digital pelvic health program in the country.
So it's gone through a pretty significant evolution.
The first phase I would call kind of early market discovery and validation, sort of building the business case of do we want to invest as a business in this particular area and are we well positioned to do it?
The second phase was early product build out to enable testing.
And what we did was an innovation partnership and kind of early testing in the space.
The third phase was launch nationwide to the employers and health plans and others who had approved the product.
The following phase was really innovating and iterating on the solution that was launched and obviously there's iteration in various forms and actually integrating significant innovations in this case we actually integrated a connected hardware device into the experience and then also continuous innovation in the digital
experience there's a further scaling phase throughout and then this current phase is we're actually expanding the offering to move beyond pelvic health to include menopause and treating kind of the muscular skeletal syndrome of menopause.
So a really much more scaled product and we're adding onto it.
And I can go through all of the various kind of phases, starting with the initial phase.
So initially, we were building kind of the business case of why do we want to do this?
And Hinge Health provides care for muscular skeletal, so back, pain, knee, hip kind of, and pain related to that.
And obviously your pelvic health is a unique part of your muscular skeletal health, but it requires a unique set of treatment and specific physical therapists that have experience and accreditation in pelvic healthcare, pelvic floor physical therapists.
And what we saw very clearly is, A, that we had folks coming to Hinge Health that had pelvic healthcare needs.
And this is not surprising.
The majority of women in this country have a pelvic health condition.
Higher during pregnancy, higher later in life.
But this is extremely, extremely common, whether it's pelvic pain or urinary incontinence, a variety of conditions, very, very common.
So we knew that this was quite prevalent.
We also knew just from our peers, the market, the demand was very high.
And at the same time, it was very, very clear that the supply of pelvic floor physical therapists was extremely low.
I personally live in Boston, great access to healthcare, but it took me months to be able to see a pelvic floor physical therapist and I would have to take off work early postpartum, like literally spend half a day going somewhere to get care.
And that didn't feel like it fit into my lifestyle.
And Hinge Health had what we had done is we digitized physical therapy and we thought, how could we digitize pelvic floor physical therapy?
So it was building the initial business case, we saw that big supply -demand gap and got to go ahead from the business to move forward.
Can we pause there for a minute and dive in?
I was just talking to somebody about the concept of building these business cases, right, before you go out and run a bunch of experimentation or you start building anything.
And I think there's sometimes a misconception in product management about how much research you should do or how much discovery you should do So before you dive into experimentation or building a first version and getting it out to customers, can you talk a little bit about what did you need in that business
case to say, go ahead?
Like what research did you do?
What kind of discovery work did you do early on to help build that?
And what did it contain that made you go, okay, yes, we want to invest in this or be able to make that decision?
I am a believer that this is really important and that you want to spend a good amount of time.
We spent sort of months on this business case.
one was of clarity around the problem and the unmet need.
So we spoke to individuals who had this particular need.
We spoke to physicians, a lot of physicians, OBGYNs and others in the line of care.
And they very clearly said that they did not have the skills, the time, or, you know, the capacity to treat needs of folks that they were serving.
So third, we spoke to buyers.
In was employers, self -insured employers.
And we recognize something very interesting here.
We recognize that folks, when we started talking about pelvic health, they needed to be educated on the space.
They weren't coming to us and say, hey, we need you to build a pelvic health program as part of our MSK offering.
But when you started talking to them about it, they were like, oh, yes, yeah.
Oh, I definitely cross my legs when I sneeze.
Oh, my mom told me about this.
And all of those conversations came out It was a really just interesting blossoming of the conversation where, no, they weren't coming to us, but once we brought up the topic, a lot of the buyers deeply resonated with the topic.
So buyer kind of user understanding and various aspects of the user, then you also need to look internally within your organization and have very strong understanding of what capacities, capabilities and differentiators do you uniquely have that are going to make it easier for you to build this or partner or whatever
approach that someone else may not have.
That's critical, right?
Because someone could start this business from zero to one, separately, what's going to make you uniquely capable of doing this, doing this well?
And then how does this align with a broader organizational strategy?
Does this help the business drive outcomes, revenue, whatever your specific goals are?
And is there a strong alignment?
And then you want to really estimate the revenue implications, the growth, the cost, all of the various pieces, its impact on ROI, to be able to bring that business case and business plan together.
That's really helpful.
So when you are looking at the capabilities and solutions, right?
When you're moving into this phase, here's the business case, here's the investment.
How deep are you going into solutioning at this phase versus the next phase?
Were you just in a conceptual, here's ways we could solve this problem?
Did you even get into that?
Or was it like we have some of these pieces, but we're still figuring it out?
At the early stage, we did not do an architectural plan of how we would technically solve it, but we had the tenets of the product solution.
We knew that we wanted to have, use our customized exercise therapy experience and customize it to the unique needs.
We knew that we wanted to have pelvic floor physical therapists across the country.
We knew that We were going to use education in this really critical way.
We had a sense of the clinical conditions that we wanted to cover.
We had a lot of those pieces that we were testing and validating in the early stages, but it wasn't that we weren't coding it at this point.
We didn't have engineering resources.
Okay. So then you validated this business case in a way where the, you know, leadership team's like, yep, let's go after it.
What did you do next?
What we did next is we broadened our cross -functional team to ensure that we had the right set of folks early.
And I think this is super important.
We had a urogynecologist working with us.
We had a dedicated pelvic floor physical therapist that wasn't just administering care.
They were working side and side with the product team to design and develop the product solution.
We had a small engineering team that was working on this product design, business operations and strategy, product marketing, and a little bit later, kind of growth marketing, and also coaching leadership.
The solution includes behavior change, so we had some health coaches with specialty in women's health.
So we had a core early team that was collaboratively, really collaboratively working to design the product.
And we decided we wanted to go out early to a subset of users so that we can, we have our hypothesis of what the solution was going to look like, what we want to test.
So we designed an innovation partnership.
We identified 10 employers who said, hey, they wanted this.
And we created an early solution for them.
It did not have all the bells and whistles.
and did not have key things that we had during launch.
But we had several hundred members that went through the early experience after we created that early experience.
And what was so critical is in that stage is that we had dedicated UXR when we were talking to these members and surveying them essentially every week of the program at every phase of the development from early onboarding experience to first week experience to meeting with your physical therapist.
But we were getting really, really deep insights from each cohort of members at every stage.
And between each cohort, we would continue to iterate and learn from the product.
So at the end of several hundred people going through that experience for four to five months, we had so much data and insights that we were already able to implement and make some pretty significant changes to the product before we were then, you know, had the data around outcomes for them and then
we're ready to kind of launch it more broadly.
Did you know I have a course for product managers that you could take?
It's called Product Institute.
Over the past seven years, I've been working with individuals, teams and companies to upscale their product chops through my fully online school.
We have an ever -growing list of courses to help you work through your current product dilemma.
Visit productinstitute .com and learn to think like a great product manager.
Use code thinking to save $200 at checkout on our premier course, Product Management Foundations.
When you're running these types of experiments or early concierge kind of experiments with, let's say, patients basically, right?
Like members in a healthcare setting, there's a lot of risk associated with that.
And I've heard companies get really nervous when it comes down to compliance or anything with healthcare.
And they start to go, oh, can we really experiment?
Can we not? We can't launch something that's not a full solution, right?
We need everything that'd be absolutely perfect before we show it to anybody.
How did you approach getting the buy -in to go out there and run it in the way that you did?
And then what kind of considerations did you take into account knowing that this was more like an experiment rather than the full solution that you were going to launch one day?
Yeah, it's a great question.
What you don't want to do is you don't want to skimp on the clinical aspects of the intervention that have a significant impact and outcomes.
But there's other areas that you can curtail.
So for example, our onboarding application experience was a separate app that we hadn't fully integrated.
And instead of back -end automated provisioning with all of the pieces kind of working together, we had some folks doing that manually on our end.
That wasn't a patient care experience.
It was not operationally effective.
It was not quick from an operational sense.
We weren't able to kind of curtail that.
What we didn't want to do is we didn't want to skimp on the exercise therapy experience, on the presence of the physical therapist.
So what we did is we overweighed some of the manual clinical aspects to compensate for that.
We had deeper clinical outreach.
We had fewer physical therapists for the number of individuals involved.
We had more frequent kind of clinical check -ins with folks.
And also, we were tracking clinical outcomes, not just engagement outcomes or, you know, how many times someone logged into the app, you know, all of those kind of important metrics.
Well, we're tracking clinical metrics.
We're tracking impact on the relevant clinical surveys for an individual's condition, depression, anxiety, all of these pieces so we can monitor those.
And plus, because we had a urogynecologist, we were doing individual case reviews of each individual person to look at risk and other pieces.
And then the final piece I would add is that we were more conservative with who we accepted into the program in the early phases.
So if someone had a certain level of risk where we may have accepted them into the program later on, we wouldn't accept them into the program at the early stages to ensure that we mitigated the risk in that way.
So with this approach too, first of all, it sounds very manual, which I think some people take for granted how manual some of these experiments are.
And then they go back and they say, well, it wouldn't have just been faster to build it into code.
If you reflect on your experience here, what were you able to do having that high touch 100 people, right, that you're working with?
And how were you able to mitigate risk?
And do you think that was worth it rather than just diving into building a code solution?
It's 100 ,000 % worth it, I would say, for a few reasons.
One is that we were able to learn from real users faster and get outcome data that we could then use when we were approaching health plans, employers, and others to show the efficacy of the program itself.
That was sort of like one.
Second is that we were just learning rapidly.
Like every few days we had new data from users going through the program in a way that that impacted what we were building and we recognized hey, we needed more variety in the aspects of clinical care.
We subdivided it in this way.
We needed to divide it in this different way.
And that could really rapidly go into how we designed the product solution.
Third, we didn't have to wait for dependent teams to get some of the work done, to get on their specific roadmap.
So for example, in a larger organization, a new product team isn't necessarily able to work in every single part of the platform.
And you're sometimes relying on teams that have a relatively stacked backlog and you're waiting and you can wait for six months to get, you know, that onboarding piece done or you could do it manually and learn.
And to us, this was essential.
We knew that we wanted to learn and not be on a queue waiting for a dependency that we couldn't control.
And for our listeners, I want to point this out because I feel like not everybody might be familiar with Hinge Health, but you are a B2B product.
You sell to the health plans and the employers, right?
Yes. It's sold to health plans that are kind of administrators, but it's largely sold to self -insured employers.
And then the benefit is offered as a free benefit to employees at those employers, and it's offered to over 20 million people in the U .S.
today. So Hinge Health is not a small company.
It's valued at $3 billion for people listening here.
Actually, over six.
Over six now. wow, last time I saw it was a Series D.
So over $6 billion now.
So we're not talking about experimenting with a startup that has no risk.
We're talking about launching a new program and a new product in a company of size, which I think is really interesting.
Now, where I get questions from people in this situation, especially with B2B, is how do you get the buy -in from the buyers, not necessarily the users, right?
Since you've got to sell to these administrators first, How do you get the buy -in for experimentation there?
And how do you like address with them, hey, we're running a pilot program, right?
Like what's that kind of process of curating those people, bringing them on and what should you consider there?
Not every employer is going to sign up for this.
Hinge Health has over 2 ,000 employers.
We identified 10 that were really interested.
And because their employees were really interested in solution, they had a track record with us, whatever the various kind of reasons, they were eager to offer this to their employees.
So it's identifying folks that have a desire, a willingness, a connected mission, whatever the linkage may be, who are willing to be your early customers.
But also it's important to have credibility.
Like this product was very similar in some ways than the rest of our offerings that had served hundreds of thousands of people at that point, right?
It's treating your pelvic health and is somewhat similar than treating your back.
Many times the same person is licensed in pelvic floor PT as they are in orthopedic physical therapy.
So we weren't doing something totally off left field that probably would have gotten more skepticism.
So there was some connection to the work we were doing and the foundation that we were building on.
And that allowed us to go to market much quicker.
That allowed us to leverage a lot of the tech, the operational capabilities.
and de -risked the clinical risk in this instance.
So thinking about kind of what you're de -risking is important there as well.
And for you, who did you work with inside of Hinge Health to identify who those 10 companies should be?
Yeah, so we worked with both product marketing and sales.
And frequently, you know, sales had a point of view on when I'm talking to this employer, usually employer, sometimes it was a health plan that it was really eager and they wanted a particular employer, who really cares about women's health or who's asking about this or where the champion is somehow
connected or more willing to integrate.
So we got a list of those and then we pitched them.
And I would actually go on those pitches and I would share the vision for the product, the PRFAQ, and ask them if they wanted to participate in a formal innovation partnership with us.
So you went through these pilot programs.
You worked very closely with these 100 patients, and then you decided that it was time to scale it.
What type of information and what type of validation did you need from that pilot program to say, yes, okay, let's invest in the solution?
And then what kind of considerations did you think about when you were thinking about scale here?
Yeah. So the first, say, like 300 or so individuals, what we looked at is, A, we looked at their clinical outcomes.
We looked at, is this working?
Because foundational, if it's not working, then we have concerns.
And we saw that their clinical outcomes were at, or in many times, better than the clinical outcome our members were getting through our traditional MSK program for other areas of the body.
So that was great. Then we looked at their level of engagement with the program in terms of how frequently they were using it and their satisfaction.
That was really high as well.
So from a member perspective, we had areas to improve, but we were like, this is a clear product market fit.
The other thing we could see is that we had designated a certain amount of capacity per employer.
And at some employers, that capacity filled up instantly.
So, and we said, hey, you have 50 employees you can put into this.
Two hours after the post goes out in Slack, we're at capacity.
So that told us something about the demand side of this that was really interesting to know, like the demand for this is actually quite high.
And then we looked at the employer perspective as well, the buyer.
And those conversations, as they matured, there was an education component, but they became very interested in how this offering helps complement their broader healthcare offering and their broader DEI offering and their unique differentiation for what they want to offer in terms of benefits for women.
So that was kind of an interesting component.
And then there was a macroeconomic just or policy point where pelvic health was just gaining so much more women's health, pelvic health specifically, so much more traction in the broader community.
There was more competitors, there was more companies in this piece.
There was a real interest and a peaking interest in this space.
So it felt like the time was really right to enter that particular market.
When we get to this stage, there's always a question of how much is it going to cost to actually solve this problem?
What do we think we're going to invest into this solution?
And how do we weigh it with those opportunities?
This is where we start to get into wars about estimation, right?
Like how long is it going to be?
And how do we actually put a cost on it?
What's your philosophy?
And how did you approach trying to get an understanding of that cost in that timeline without going so overboard to commit to like super specific dates?
So we estimated the revenue impact of the business of this offering, including net new revenue and cannibalization of existing and of existing revenue with some set of assumptions based on early data.
And we worked really closely with finance and business operations to do that.
We, to some degree, said we want a team on this of a particular kind of size, but at one pod, pretty agile, working at this stage And at different phases and different stage dates, we can decide if we want to put more or less folks into that particular team.
And so we had a relatively finite, you know, this is the cost of one team at this company.
And then we'll evaluate.
Eventually kind of it needed to become two teams and it changed over time.
But we evaluated that based on the trajectory, outcomes, revenue, and traction of the business.
So the idea here was start small with this team.
We know how much that's going to cost.
Let's see how far they can get as they dive into it, and then we'll reevaluate and decide if we should dedicate more teams to it.
Exactly. And start small, but with the resources that you need, just the team and then also the cross -functional resources, and then ensure that there was a critical, dedicated commitment from dependent teams for particular aspects of resourcing.
So we wanted to launch nationally at X point in time at a particular date.
And so we did need pretty hard commitments, from a number of dependent teams, and the whole organization, especially if you're going to announce a particular launch, it needs to be moving in one direction, right?
And that was really clear to everyone involved, that X team that was responsible for care team tooling or Y team that was responsible for this aspect of growth were all working together on a very finite project plan to be able to launch nationally on a particular timeline?
So on the aspect of getting the team to do this, I see a lot of product leaders struggle, especially the ones who are going from like project to product management mode.
They're trying to figure out how to do this.
They're trying to figure out how do I keep mostly stable product teams, budget for those product teams.
But then what do I do when I do launch a new product, right?
I've got this whole portfolio of products and I'm sure Hinge Health has that too.
And we've got stable product teams working on them.
How do I allocate people to something?
What was your philosophy for that and how should product leaders think about growing those teams, especially if those products become valuable and stable over time?
I think that you need a dedicated product team and both within the product org, but also cross -functional org for a net new product.
And for a big product, I also recommend someone playing the role of a GM, whether that's formally or informally.
If this isn't a feature, this is a holistic product with a go -to -market, with pricing, all of the various pieces that are involved to make something pretty significant and successful.
I would say that if you have a dedicated team that has that particular product mission, they are living and breathing that problem, the buyer problem, the user problem, and the market traction, and they're ultimately accountable for the outcomes.
They're accountable for the revenue that this product's generating.
They're not just building features, they're driving the business and the member experience forward in a holistic way.
Whether that team is the team three years down the road that's still working on that problem, they may not be, right?
The product may mature enough to be able to be transitioned to a different phase, but having a team that's separate is important.
The other piece that's important is that the team that does zero to one products and the mindset of the engineers, PMs, and designers is actually quite different than folks that are working on sustaining innovation.
You cannot use the same processes, right?
You cannot use the same methodologies.
You're not building in the early stage to ensure that your infrastructure is stable for the next five years.
You don't even know if you're going to have great product market fit.
So you have to be able to cut corners.
You have to be able to advocate for the product.
You have to be scrappy.
You have to be agile.
You have to learn really quickly.
The people who love that and who do that well are not necessarily and frequently the same people that would work on other types of products.
So are you getting these people from inside the organization?
Are you hiring net new for them?
Is there like just this zero to one team that's hanging out, waiting for opportunities, what's the best way of trying to form that team?
So I managed at different levels, probably five or so of these teams that were working, all working on different stages of zero to one product.
And that means, you know, PMs and then you have the designers and engineers and frequently hardware folks, depending on the nature of the product.
I think that there's a zero to one type of PM, either this is the type of thing that they do or they just gravitate towards working in this way.
They are by nature have to be more cross -functional.
They spend more time with sales.
They spend more time externally and market facing than on a kind of a sustaining product.
They have to be really good at storytelling.
Like you are continuously telling the story of your user, telling the story of your product and continue to generate and create and sustain momentum.
And you have to be really agile to be able to, you know, quick change, move things around, streamline something that could take a really long time into what kind of a minimal thing that focuses on the risk -based assumption.
So when you get the product out there, you know, let's say it's live many years down the We talked a little bit about different mindsets for PMs who are in startup for sustaining innovation.
Are you changing up the team?
Are they like handing that product off to somebody in a different organization?
Are we growing and sustaining that team to stay around that product?
What's the right way to manage that?
I think it really depends on how much innovation you're doing within a particular product.
I think if you take the women's health solution, we launched an offering and we were iterating on the core offering, but then we wanted to integrate a hardware device into the experience, right?
That was a whole new set of capabilities.
And now we wanted to, we added a new menopause offering.
We created content around mindfulness and meditation.
So lots of really significant phases of innovation.
So that product still stayed within the zero to one new area because of the rapid rate of net new product innovation.
If we had kind of plateaued and were kind of sustaining and making more small improvements, quality improvements, but not brand new areas of care, I think that then it probably makes sense to move that into a more sustaining aspect of the business.
So with the women's pelvic floor program that you're doing and the product with it, looking back on it, how would you advise people who are working on things that are so, let's say, there's a lot of risk on it, right?
Like when it comes to this stuff, we don't want to kill the clinical outcomes.
We don't want to do that.
How does that differ, I guess, as well, building something like that inside an organization versus having this be a separate startup?
How did you approach this coming from a zero to one inside a large organization?
And how is that different than somebody spinning up a company that, let's say, has no customers yet?
So the benefits of spinning this up within a larger organization are that you have a lot of unique strengths that you can leverage, right?
We had a tech platform and a tech experience that we could leverage with education, exercise, therapy.
We had a lot of pieces there.
We had a clinical team and a clinical operations team coaching physical therapy that we could leverage and scale so I could get, within a very short period of time, pelvic floor PTs across every single state in the U .S., right?
That is very hard to do when you are a small company just starting out.
Same with women's health coaches, right, getting that kind of capability.
And we had a strong channel, which I think is essential.
We had the sales channel, but we also said we have a program for muscular skeletal care and pelvic health is a foundational component of muscular skeletal care.
So now, in addition to treating your hip and back, we're able to address the various different conditions and needs within the umbrella of pelvic health.
So we had a channel to sell into.
So this wasn't, I'm going to an employer and say, hey, just buy this particular program.
This is now offered to all of our employers as part of our offering.
So that was really differentiated and a few other pieces, but it just allowed us to use the really differentiated aspects of our business to be able to gain tremendous traction and scale as well as the kind of a reputation that we had at the beginning.
The downsides of being able to doing this within the context of a larger company is that this isn't the only thing that your company is doing.
And at the early stages, the number of users, you know, a few hundred users relative to hundreds of thousands of users is just kind of a rounding error.
This isn't driving revenue.
This isn't driving business outcomes in the very early stages, later stages, absolutely, if it's successful.
But early it's not.
So you have to be able to get resources, whether they're resources that are autonomous to the team so you could run forward and or designated aspects of supporting teams, whether it's marketing or growth or sales, to help you and help allow this to be successful.
Plus, you need to have commitment at the leadership level of the organization so that you can continue to move forward.
And so this doesn't become just like the next shiny object that then becomes forgotten about because there's bigger issues, there's larger revenue opportunities, a small change in onboarding gives you a ton more revenue than a net new product that you're just intubating.
This is one of the challenges I find in the larger companies, trying to get that early buy -in for something that you know will grow over time, but is probably not producing those outcomes today.
What's your advice for product managers that are trying to tell their stories and help show that this could potentially be a big opportunity, but it's going to be a while before we realize the effects?
I just took a great course in Maven by Mejika Kapoor, I think is her last name.
She's a PM at Figma who talks about kind of storytelling for zero to one product.
I think it's really very important that you are kind of the keeper of the flame of this vision and that you talk about the vision and the product opportunity and then enlist so many other people within the organization to continue to drive that momentum and that story.
So you're not the only voice in the conversation as the PM, but you have your folks in sales and you have your folks in CS and clinical and, you know, whatever the aspects of the organization, they can speak about the value of the product and the member stories and the outcomes.
And every time you have strong traction, whether it's UXR findings, whether it's market traction, whether it's data around engagement, you use those as opportunities to share traction and momentum within the organization so that, say, you've got an investment from a particular product that there is clarity
of how the product is moving forward.
And if it's not moving forward well and you have a particular learning or you've pivoted or you cut something, they are also sharing those stories.
And it's not forgotten after someone says, yep, go ahead, let's launch it.
But it's this continuous living, breathing thing.
All of the phases, even before it becomes meaningful from a revenue or business perspective.
Anessa, I've learned so much from you about building zero to one products and the different healthcare industries you've worked in.
For our listeners, too, what are you excited about looking at the trends in femtech and in healthcare tech going forward?
What's getting you motivated these days?
So, I have a few hypotheses.
One is that I think that companies, healthcare companies, that don't particularly address women's health, but say focus on mental health or cardiometabolic health have a really strong opportunity to create unique and personalized solutions within the spectrum, within the area of women's health.
Because, you know, in mental health, there's unique aspects of women's health, pregnancy and postpartum, or mental health that's impacted by where you are in your menstrual cycle.
And the ability to personalize care with clinicians and different care approaches to the unique needs of women within the umbrella of these broader areas of care, I think will, A, improve member care, but also drive growth within these businesses.
And so much of general healthcare has been built around data based on men, so it's really interesting to see kind of these bigger companies do that.
Secondly, I think that there's a real opportunity related to wearables and wearable data and integrating wearable data into the healthcare experience and healthcare outcomes.
Whether it's like a Whoop or an Oura Ring or wearables for glucose monitoring, how do we use that particular data to drive specific insights that are unique to women's health?
Third, I think there's a lot of very interesting biomarkers that are specific to women's health that have not been studied, such as period blood, the vaginal microbiome, sweat, things that everyone has, but because of the nature of research, haven't been studied and are now being studied in a way that are going
to yield really interesting new clinical devices, interventions, ways of care, and approaches to care within this kind of span of women's health.
And then finally, as this broader discussion of topics that are somewhat taboo has increased, so topics around menopause, you know, five years ago, this wasn't the center of conversation.
Now it's a really important and pretty vocal conversation.
I'm really hopeful that we will have this integration of high quality specialized clinical care, sometimes virtual, in conjunction with, you know, in -needed, in -person care, AI -enabled knowledge and education, and ideally wearables to create a comprehensive data -driven ecosystem that helps to elevate the quality
and outcomes within the women's health space.
I am certainly looking forward to that and to seeing where this is going.
And I'm happy to hear that you're talking about it and pushing these boundaries forward.
Thank you so much for joining us today.
If people want to learn more about you and connect.
Where can they go? Yeah, you can follow me or connect with me on LinkedIn and Nestle Lurie.
That would be the best place.
Okay. And we will definitely put your LinkedIn profile and all this information in our show notes at productthinkingpodcast .com.
Thank you so much for listening to the Product Thinking Podcast.
We'll be back next Wednesday with another amazing guest.
And in the meantime, if you have any questions for me around product management or any topics like that, go to dearmelissa .com and let me know what they are.
We'll see you next time.
