.bh__table, .bh__table_header, .bh__table_cell { border: 1px solid #C0C0C0; }
.bh__table_cell { padding: 5px; background-color: #FFFFFF; }
.bh__table_cell p { color: #2D2D2D; font-family: 'Arial',Helvetica,sans-serif !important; overflow-wrap: break-word; }
.bh__table_header { padding: 5px; background-color:#F1F1F1; }
.bh__table_header p { color: #2A2A2A; font-family:'Montserrat','DejaVu Sans',Verdana,sans-serif !important; overflow-wrap: break-word; }
Solving hard problems often requires new ways of working.
In 1939, Howard Florey was trying to figure out how to produce enough Penicillin to run a trial in humans. It was a scientific and manufacturing question. But Florey’s genius lay in realising he needed to innovate in how he was approaching finding an answer. He recruited an interdisciplinary team to his lab at Oxford and had them work simultaneously on their respective areas of expertise — something that wasn’t really done at the time. This process soon provided an answer to their Penicillin production problem allowing them to make enough of the substance to test it in a human.
A few decades later, NASA were trying to put a man on the moon. To do so, they had to invent modern project management just to coordinate the 400,000 people working on the problem.
In 2026, the field of mental health faces another hard question: Can we use Artificial Intelligence to improve people’s mental health?
There are many technical and clinical aspects to this question that we still don’t understand. Teams are building on a rapidly changing frontier technology, the evidence base is still emerging, the stakes are high and there are multiple success criteria to consider. Because of this, the old product playbook no longer works. Leaders realise they need to redefine how their teams tackle this question.
Over the last few weeks I’ve been speaking with product and clinical leaders from organisations like Spring Health, Headspace, Grow Therapy and Slingshot to understand more about how they approach this problem.
In this edition of The Hemingway Report, I share seven insights into how these leading organisations are redesigning their teams and processes to build mental health AI.
Let’s get into it.
Many thanks to the contributors to this article:
- Gijo Mathew, CPO @ Spring Health
- Jenna Glover, CCO @ Headspace
- Fay Kallel, CPO @ Headspace
- Bre Vergess, VP, Head of Product @ Grow Therapy
- Kevin Ramotar, Director of Clinical Product & AI @ Grow Therapy
- Matt Sculpt, Principal, Clinical AI @ Grow Therapy
- Derrick Hull, Clinical R&D Lead @ Slingshot
- Dana Udall, Healthtech Executive, Psychologist and Former CCO @ Nourish and Headspace
Building Mental Health AI poses a new set of challenges for product teams. As Gijo Mathew, CPO at Spring Health puts it:
“
The biggest learning is that building AI for mental health is not just a technical challenge. It's a product, clinical, safety, and trust challenge all at once.
Gijo Mathew, CPO at Spring Health
Leading organisations are therefore writing a new playbook for building mental health AI products. From organisational structure, to hiring, to governance and building trust, here are seven lessons for building a high-performing mental health AI team.
1. Build AI-native, cross-functional teams, with clinicians embedded from day one
Every leader emphasises the importance of including clinicians from day one.
In mental health AI, product decisions are clinical decisions. Tone, timing, response length, how validation is delivered are all aspects that shape a person's psychological experience. A product team making these choices without clinical expertise in the room may build something that feels polished but has no therapeutic grounding. In the worst cases, it could even be harmful.
As Jenna Glover, Chief Clinical Officer at Headspace says: "Remember that every design choice is an intervention. There has to be intentionality about why each choice was made and whether it leads to the intended outcome.”
Glover continues: “It's not enough to layer clinical expertise on after the tool is built. It has to be there from the start”.
Glover’s colleague Fay Kallel, who is the Chief Product Officer at Headspace, emphasises the importance of embedding these clinicians into cross functional teams to building mental health AI teams and aligning these teams behind shared customer outcomes: "The strongest teams are organized around customer outcomes, not functions or feature areas. When product, engineering, design, data, content, and AI are aligned around a shared problem, decision-making is faster and accountability is clearer."
Contrary to what some may believe, including clinicians early can actually speed up product development. Kallel argues that when organisations treat clinical review as a final approval step, it can create friction, lead to worse products, wasted work and slower product development. "When clinical expertise is present during problem definition, design, and experimentation, you catch the right issues earlier and build experiences that are safer by design, not just safer by review."
“
Safer by design, not just safer by review.
Fay Kallel, CPO at Headspace
While clinician involvement and cross functional teams are consistent traits across all the organisations I spoke to, they have taken different approaches to implementing these principles in their orgs.
Spring built an AI-native team from the ground up. This included recruiting AI specific roles like AI Product Managers, Prompt Engineers, ML Engineers, ML Operations, AI Trust and Safety Engineers, and AI UX Researchers who evaluate whether designs are fit for human use.
Clinicians sit directly inside this team, integrated as collaborators from day one. As Mathew says: “We bring product thinkers, clinicians, engineers, researchers, and operators together around one question: how do we use AI to remove barriers to care without ever losing sight of the person who needs help?”
Grow Therapy took a different route. They created a dedicated Clinical Product function that sits within their broader product org. Bre Vergess, Grow's Head of Product speaks about when she realised they needed to move beyond consultative involvement and to build out this Clinical Product team. "…as AI became a bigger part of what we do, the stakes for getting it right only went up. Having clinicians available to consult wasn't enough, they needed to be full-time builders, sitting side by side with PMs, designers, and engineers, with all the context and the right level of influence to shape what we create."
“
Having clinicians available to consult wasn't enough, they needed to be full-time builders.
Bre Vergess, Head of Product at Grow
Grow’s Clinical Product team is staffed entirely with licensed clinicians and is responsible for ensuring that product development is grounded in clinical best practices, enhances patient safety, and supports evidence-based care at scale. The head of this team reports directly to the VP of Product and each Clinical Product team member serves as a designated point of contact for specific product work-streams across Grow.
Headspace include clinicians in their cross functional teams and embed them across their product org. Glover says that the team building their AI companion, Ebb, is roughly 50/50 clinical to product/engineering, with clinical expertise woven throughout the team.
2. Hire solutions-oriented clinicians with product sense — and product people with clinical curiosity
What types of people do leaders look for when building their mental health AI teams? Clinical expertise and technical skill matter, but they aren't sufficient. The best teams hire people that combine domain knowledge with a unique set of traits that allow them to work effectively in this emerging, high-stakes field.
What to look for in clinicians.
Vergess looks for solution oriented clinicians. "The archetype we were looking for wasn't just clinical expertise, it was clinical expertise combined with a solution orientation and real product sense…”
Vergess notes the importance of having genuine 'product sense' alongside clinical expertise: knowing how to identify priorities, communicate crisply across disciplines, and show up as a clinical voice that product and engineering actively seek out at key moments.
Dana Udall, a healthtech Executive, Psychologist and Former CCO @ Nourish and Headspace, recommends screening clinical hires for risk tolerance, cross-functional willingness, and flexibility. She prioritises candidates who have a strong clinical point of view and who know how to have their concerns understood and accepted by the wider organisation. She also looks for people who are flexible and open to having their mind changed.
Grow deliberately recruit clinicians with different therapeutic orientations to make sure they have scientific breadth and avoid tunnel vision from a single clinical perspective.
What to look for across the broader product team.
Kallel reflects Udall’s desire for open-mindedness in her teams. "The strongest team members are curious, collaborative, data-informed, and comfortable operating in ambiguity."
"
The strongest team members are curious, collaborative, data-informed, and comfortable operating in ambiguity.
Fay Kallel, CPO at Headspace
AI fluency is also important for Kallel — not just for engineers, but for clinicians, product managers, and designers working on these products. The field is moving so fast that people who can't engage with the technical realities of how AI systems work will struggle to contribute meaningfully to product decisions. As Kallel describes: "AI fluency, adaptability, and a continuous learning mindset are becoming foundational traits across every discipline."
Deep technical expertise matters too.
While all leaders recognise the importance of these softer character traits, Derrick Hull, Clinical R&D Lead at Slingshot reminds us of the importance of hard skills in this domain. Building purpose-built mental health AI requires a specific set of technical skills, especially in machine learning. Hull’s belief is that teams that underinvest in technical expertise and rely on prompting alone will hit a ceiling in what their products can do.
Join the Hemingway Community
If you’re enjoying this article it’s probably because you want tactical information on building a successful mental health organisation. If you’d like more of that, and to meet peers building similar businesses, consider joining the Hemingway Community.
As a member of the community, you’ll join over 450 other mental health leaders and get access to exclusive content, events and resources.
3. Empower clinicians to build, not just review
Embedding clinicians is important. But top teams have moved past using clinicians solely for product reviews or requirement generation. Their clinicians do actual product work.
At Grow, the Clinical Product team is hands on. The team writes prompts, runs evaluations, creates prototypes, designs QA architecture, and analyses data. They operate much closer to engineering than a traditional subject matter expert function, bringing clinical expertise directly into the technical work rather than handing off recommendations for others to execute.
While Grow’s Clinical Product team is somewhat unique in how hands-on they are, Kallel thinks similarly about empowering clinicians at Headspace: "Clinical partners aren't reviewers of finished work, and product teams aren't simply executors of clinical requirements. Both are involved early in defining problems, evaluating opportunities, and shaping solutions."
“
Clinical partners aren't reviewers of finished work, and product teams aren't simply executors of clinical requirements.
Fay Kallel, CPO at Headspace
Spring take a similar approach with clinicians shaping evaluations, safety prompts, and feature prompts directly alongside product and engineering partners.
4. Build trust through shared work, not review gates
Building innovative products requires a high degree of trust within teams and across the organisation. This trust is best built when clinical and product teams actually work together on the same problems.
Mathew describes how this happens at Spring: "Trust is built through shared work — reviewing real member conversations together, writing prompts and evaluation criteria jointly, being in the same room for the difficult discussions. When both sides are looking at the same outputs and accountable to the same quality bar, the division stops being meaningful."
“
Trust is built through shared work.
Gijo Mathew, CPO at Spring Health
Kallel at Headspace takes a similar approach. "One of the biggest lessons I've learned is that trust between clinical and product teams doesn't only come from governance structures, it comes from how people work together every day. We've been very intentional about establishing workflows where neither group is brought in at the end of the process."
Grow describe building a culture where Clinical Product isn't a separate conscience sitting outside the rest of the organisation. They've found that the best work happens when clinicians feel empowered to flag a genuine clinical concern and equally empowered to find a creative solution — rather than defaulting to a hard no. Trust at Grow builds in both directions: when Clinical Product flags something early and it turns out to matter, that earns confidence with the broader product team. When Clinical Product enables other teams to meet their timelines while maintaining conviction on safety and quality, product managers gain confidence in what they're shipping (and in the value of the Clinical Product team).
Aligning around a shared metric also helps improve collaboration and trust. At Headspace, that metric is member trust. As Kallel explains: "When trust becomes a shared goal, many of the hardest tradeoffs become clearer. The conversation shifts from 'Can we ship this?' to 'Will this strengthen or weaken the trust our members place in us?'"
Shadowing and rituals can also be helpful. Udall warns that when escalations are the primary mode of contact between clinical and product, the relationship can turn adversarial. "If that is the bulk of the interaction, you are going to obliterate trust." Her advice is to shadow each other, build shared failure reviews, and approach the other team with curiosity.
As an example, Headspace run a “Trust Tuesday” session where product, clinical, operations, and legal discuss priorities and emerging issues. Spaces like this where teams can openly share what’s on their mind and also be transparent about their concerns and mistakes are critical to building trust.
5. Create clinician buy-in by leading with clinical reality
Getting clinician buy-in is critical to product adoption. Clinicians outside the core AI team are evaluating your product through the lens of patient safety, clinical quality, and whether it makes their work easier or harder. The teams that get buy-in from their broader clinical network realise this and address these topics directly in their communications. They don’t lead with AI hype.
Spring Health found that conversations with clinicians work better when they start with the clinical problem, the workflow reality, and the guardrails — not with just pure excitement about the technology. They recommend approaching conversations by sharing the clinical problem the product is meant to address and exactly how the product is meant to do that. Spring also found that transparency about limitations builds more credibility than polish. Being direct about uncertainty and failure modes earns more trust than presenting the technology as fully solved. Hype-driven messaging and framing AI adoption as inevitable causes clinicians to disengage quickly.
Grow emphasise the importance of meeting providers where they are on their own journey with AI. Some providers are early adopters, others are cautious, some are vehemently opposed to AI. Grow compares it to telehealth adoption, which was slow before the pandemic. Some providers have now fully transitioned while others still prefer in-person work. Grow lead with clinical credibility, acknowledge concerns openly, and respect different practice philosophies. What doesn't work is dismissing concerns, over-explaining, or moving too fast.
Udall recommends making the co-creation process visible. Involve clinicians in development from the start, then have those clinicians present to the wider organisation about what they contributed and what changed as a result.
6. Formalise your safety governance before you need it
Every team we spoke to has built formal governance structures for safety and quality decisions. The structures differ but the underlying principle is the same: don't leave safety to informal judgment, and agree on how decisions get made before a crisis forces you to improvise.
Headspace created a Clinical Safety and Experience Council (CSEC), a governance body that brings together clinical, safety, research, and product perspectives to make decisions about Ebb's safety and quality. As Glover describes: "When we started Ebb, we had different groups working together, but there's so much happening in the space that we decided we needed to bring a council together that could put all these inputs together and make decisions. That became our Clinical Safety and Experience Council." The council discusses both micro-level aspects of Ebb's behaviour (how the AI responds in specific conversation types) and macro-level changes happening in the field (new research, regulatory developments, strategic questions, etc.). Glover gives an example of a recent CSEC discussion: "A topic that came up recently was global expansion. When is it okay for us to release Ebb in different countries? How does safety vary by culture? And how does motivational interviewing, in terms of how Ebb is currently trained, fall flat within different cultural contexts?"
“
There's so much happening in the space that we decided we needed to bring a council together that could put all these inputs together and make decisions.
Jenna Glover, CCO at Headspace
Spring Health created an AI Governance Board that brings together security, clinical, legal, AI safety, and compliance perspectives. It sits independent of the product org. This body defines what "safe to deploy" means, and that definition cascades into everything across the org. Mathew explains why their AI Governance Board is independent of the product org: "Feature teams move fast — that's their job. Safety sets constraints they operate within. When safety is owned by the feature team, it tends to bend to shipping pressure. When it's independent, it doesn't.”
“
When safety is owned by the feature team, it tends to bend to shipping pressure. When it's independent, it doesn't.
Gijo Mathew, CPO at Spring Health
At Grow, readiness to ship is determined by predefined success criteria, including benchmarking tests, internal review, and red-teaming by an outside organisation. Decisions are made jointly between product management and clinical product leadership.
Udall warns against any governance structure that concentrates clinical sign-off in one person — what she calls the sole expert trap. "It puts the onus totally on that clinician, and if they're not in the room the day the decision is made, they are often left out of the discussion. We really need to have this kind of distributed critical layer of thinking that lives across the organization." This is particularly relevant for smaller businesses who may not have large clinical teams. Her recommendation is to develop a culture where everyone has the duty to raise safety concerns.
“
We really need to have this kind of distributed critical layer of thinking that lives across the organization.
Dana Udall
Governance doesn’t have to mean added bureaucracy and slowness. As Kallel puts it: "Don't confuse governance with bureaucracy. If you've designed the system well, governance should accelerate good decisions, not slow them down." She also argues that safety decisions are rarely binary: "It's rarely a simple 'ship or don't ship' conversation. More often it's about determining the appropriate level of intervention, oversight, transparency, and monitoring for a given experience."
“
It's rarely a simple 'ship or don't ship' conversation.
Fay Kallel, CPO at Headspace
7. Build processes to move fast without sacrificing clinical rigour or safety
Good governance can speed up good decision making. So can good process.
The teams I spoke to all run tight, recurring processes for reviewing AI quality, managing safety, and iterating on the product. Predictable, recurring systems are how these teams continuously improve quality over time.
In terms of ongoing quality processes, Grow runs weekly clinical reviews of AI outputs, with a triage hierarchy that prioritises the most important conversations. Between review cycles, they run automated evaluation monitoring which maintains coverage at scale. The team also conducts table reads where they walk through real AI interactions. This helps to surface issues that they might miss otherwise. Weekly team meetings focus on quality, safety, and prompt improvement, with QA patterns feeding directly into product iteration. An example of this is when their QA team identified a pattern where panic symptoms were being routed through medical emergency guardrails, triggering unnecessary escalations. With that finding, they could change their prompting which then improved performance.
Headspace run a structured operating rhythm too. As Kallel describes: "On a weekly basis, we review customer experience, experiment performance, product quality, technical architecture, and emerging risks. On a monthly basis, we review progress against strategic priorities. On a quarterly basis, we go deeper, assessing outcomes, reallocating investments, and refining strategy and execution. What makes this work is predictability. What tends to break things is ad hoc communication, unclear ownership, and relying on heroics rather than systems."
“
What tends to break things is ad hoc communication, unclear ownership, and relying on heroics rather than systems.
Fay Kallel, CPO at Headspace
One important aspect of process and team design is decision rights. Udall recommends defining decision rights in advance. Spring Health does this through a set of quantitative exit criteria, with every feature evaluated across multiple safety dimensions before it can move forward.
Staying current with new research, regulation, and developments in the field is also a team responsibility. At Headspace “staying current on research, regulation, and industry developments is a shared responsibility” as Kallel describes. Each individual is responsible for staying up to date with developments in their own field. Grow takes a similar approach. They also highlight the benefit of actively contributing to the field. They see forming external research partnerships, standing up an external AI advisory board, and collaborating with academic institutions as a good way to improve their ability to remain at the forefront of technology and research.
That’s all for this edition of The Hemingway Report. Many thanks again to all of the contributors to this article.
If you found this valuable, consider supporting our work by becoming a Hemingway Pro Member. As a member you will get access to exclusive content and be invited to join our community of mental health innovators.
Keep fighting the good fight!
Steve
Founder of Hemingway
