Talk by Dan Feng (Maven Clinic) on operating an AI-native health company. He argues that as AI made building software cheap, arguing over requirements became the expensive step, so Maven shifted to long-horizon direction plus two-to-four-week commitments, treating three-to-six-month plans as effectively unplannable. He covers code review adaptation (self-certified reviews, capped pull request size, stacked changes, avoiding rubber-stamp reviews), risk-tiered reliability (tolerating rare scheduling failures but requiring multiple models to agree on reimbursement claims), and repeated integration testing for nondeterministic systems. Also discussed: internal AI adoption, why senior engineers stopped delegating implementation, blurring of product and engineering roles, and rewarding AI fluency in performance reviews. # Channel Presentation Observations — "How to build an AI-Native Health Company — Dan Feng, Maven Clinic" ## Speaker & Platform Context - The speaker self-identifies as **Dan, from Maven Clinic**, presenting a talk: > "I'm Dan. I'm from Maven Clinic. Today we'll share the experience how we transition from a traditional technology company to AI native company." - The setting is a **live conference presentation** with audience interaction (hand-raising exercise) and closing applause, suggesting the channel hosts or shares event talks. ## Intended Audience - **Business and technology leaders mid-way through AI adoption**: > "Raise your hand if you thought about it, but haven't started the journey yet... That means most of us is in between. Hopefully this talk can help you with that one." - Audience is assumed to include **engineers, PMs, and engineering leaders** — the talk covers hiring, code review practices, sprint planning, and PRD/TDD writing. - Assumes familiarity with AI tooling (Cursor, Claude Code, Jira) without introduction. ## Claimed Scope / Self-Description - **Maven Clinic self-described as**: > "the largest digital health platform. We are focused on women and their families" — specializing in "maternity, fertility, parenting, menopause." - Claims a proprietary AI layer: > "we built something called a Maven Intelligence. It's a orchestration layer across all our product to enable AI for everybody in this company and for our clients." - Positions adoption as urgent: > "adopting it is not an optional. Even you choose not to, your competitors will do." ## Demonstrated Presentation Patterns (Observable) - **Practitioner case-study format**: concrete internal examples cited throughout, e.g., leaders using AI instead of delegating, the Cursor → Claude Code tool migration, reimbursement-claim reliability handling, self-identified code review merges. - **Opinionated frameworks**: three-part definition of AI-native (internal tooling, product AI, culture/process); three adopter groups (early adopters, majority, slow adopters); sprint-length planning over quarterly planning. - **Honest framing of limits**: acknowledges unfinished work — > "That's what we are still working on, and we're not there yet" (on end-to-end automation); AI code review tools only "helps a little bit." - **Aphoristic, memorable style**: e.g., the tractor/farmer analogy and the "rubber stamp" code review warning. ## Claims vs. Demonstrated Evidence - **Creator claims about the company** (largest digital health platform, Maven Intelligence scope) are stated but not independently verified in the material. - **Demonstrated expertise** appears via detailed operational specifics: 500-line PR limit, stacked PRs, 90% integration-test pass rate across repeated runs, 20% conversation review on new feature launches, dual-model agreement for claim processing. ## Notable Absences - No channel-level self-description (e.g., "about this channel"), no curated metadata was supplied, and no other videos or series framing are referenced — the talk is presented standalone. # Delivery Observations — Dan Feng, "How to build an AI-Native Health Company" ## Tone & Register - **Conversational, pragmatic, informal.** The talk reads as an experience-sharing session rather than a polished keynote: > "So, first of all, I don't think there's a one single definition what it means by AI native." - **Non-native-English speech patterns throughout**, including occasional article/preposition slips and self-corrections: > "adopting it is not an optional." / > "The boundaries between PM and engineers is getting blur- blurry." - **Direct address to the audience** and second-person framing keeps it advisory: > "Hopefully everybody here will become farmers who can operate your tractors." ## Audience Interaction - Opens with a **live show-of-hands exercise** before any content: > "Raise your hand if you think you are already an AI native company… Raise your hand if you thought about it, but haven't started the journey yet. Okay, we saw a few." - Uses the result to frame the talk: > "That means most of us is in between. Hopefully this talk can help you with that one." ## Recurring Phrases & Verbal Habits - **"meet where they are"** appears repeatedly when discussing tool adoption and process change: > "We need to meet where they are, just make feel they comfortable to use it." > "For them, we just shouldn't meet where they are, understand what their concern is." - Frequent discourse markers **"So," "Okay," "Like,"** often starting sentences: > "So, Maven Clinic is the largest digital health platform." / > "Okay, tell me what I need to deliver in this sprint." - Habit of **restating a past pattern as "the way we used to work is…"** before contrasting with the new AI-era approach (appears in the hiring section and the delivery-process section). ## Teaching Structure & Habits - **Numbered/list framing**: > "For us, it is really come down to three parts." followed by internally, externally, and culture/process — each explicitly cued ("That's for internally. Externally…Thirdly"). - **Three-group segmentation** of adopters: > "there's always like screw three groups of users" — early adopters, the middle majority, slow adopters. - **Concrete before abstract**: each principle is followed by a specific example (e.g., AI chatbots for cost, cursor vs. cloud codes tool migration, 500-line PR limit, reimbursement-claim failure tolerance). - **Illustrative quoted dialogue** to model desired behaviors: > "we start ask, 'Okay, what do you have done for AI side?'" / > "Hey, I have trouble to process your stuff. Do you want us to get you connect to a human agent?" - **Borrowed aphorism** reused as a takeaway: > "Like a tractors aren't to replace farmers, but the farmers who can operate the tractor will replace the ones who cannot." ## Framing & Hedging Patterns - **Explicit prioritization language**: > "Thirdly, I think is more important…" / > "More importantly, we should really listen to them…" / > "And the more important…" — a consistent habit of flagging significance. - **Honest limitation statements**; admits unfinished work rather than overclaiming: > "That's what we are still working on, and we're not there yet." / > "we don't feel comfortable 100% reliable on them yet." - **Tolerant, non-dogmatic stance**: > "If they feel comfortable do that, it's totally okay. But you don't have to." ## Uncertainty Notes - The transcript contains apparent ASR errors (e.g., "screw three groups," "NASA and NASA engineers," "Genex solutions," "auto evolve system"), so word-level habits beyond the clear repeated patterns above cannot be verified with confidence. - Audience reactions are audible ([snorts], [applause]) but their cause cannot be determined from the transcript alone. # Observation Record: "How to build an AI-Native Health Company — Dan Feng, Maven Clinic" ## Speaker - **Dan Feng**, Maven Clinic (identified via title and self-introduction: "I'm Dan. I'm from Maven Clinic.") ## Company Context (as stated) - Maven Clinic is described as **the largest digital health platform**, focused on women and their families: maternity, fertility, parenting, menopause. - AI journey began **two years ago**; they built **"Maven Intelligence"**, an orchestration layer across all products enabling AI for everyone in the company and clients. ## Core Claims ### On AI Adoption Generally - **"Adopting it is not optional"** — even if you choose not to adopt AI, competitors will. - Quoted analogy (heard "a couple years back," not his own): **"Tractors aren't to replace farmers, but the farmers who can operate the tractor will replace the ones who cannot."** - **No single definition** of "AI native" exists, and **no predefined playbook** to follow. ### Maven's Three-Part Definition of AI Native 1. **Internal adoption** — use AI tools whenever possible (daily summaries, meeting management, Jira tasks). When you want to delegate a task to someone, first ask whether AI can do it. Feng states many Maven leaders, including sales, now solve such tasks themselves with AI rather than delegating. 2. **External/product AI** — two goals: **improve user experience** and **reduce operational cost**. Example: AI chatbot is "24/7, always available... way better and cheaper compared to human agents." 3. **Culture and process change** — rework how the organization works to maximize what AI offers. ### Managing Three Groups of Adopters - **Early adopters**: just enable tools and encourage sharing learnings. - **Majority (middle)**: build shared AI infrastructure, easy-to-use tools, seamless adoption; listen and iterate. Example: last year most used Cursor; this year many switched to "cloud codes" (transcript term; likely Claude Code) — Maven supports both, "meet them where they are." - **Slow adopters**: understand their concerns but be "crystal clear" about where the company is heading. ### Hiring and Rewards - **Changed delegation patterns**: previously senior engineers sensed problems and delegated implementation; now senior engineers solve problems directly with AI because delegating adds overhead and inefficiency. - **New hires must work independently** in the traditional technical-lead mode. - Hiring criteria: genuine interest in AI and continuous learning; engineers who understand the product (PM/engineer boundary blurring); deep system understanding; ability to handle complicated, ambiguous problems — "This is where AI land[s] off." - **Performance reviews now include** "What have you done for AI side?" — rewarding those who leverage AI to multiply impact. ### Planning Horizons - Old model: weeks/months on requirements and design before expensive implementation; but **"we never get it right in the beginning anyway."** - With AI, **building is cheap; iteration/rework is expensive**. - One-year visions are fine as **inspiration only**, assuming AI models can do anything in a year. - Real focus: **two-to-four week sprints**; PMs flesh out next requirements while engineers deliver current sprint. If last sprint's decisions were wrong, "totally okay" to switch gears. - **Documents shortened**: prefer one-to-two page PRD/TDD over long documents; documents serve as communication to iterate on. - **Explicit tension**: mid-term goals (3–6 months) are "very hard to plan" because model capabilities are unknown; he acknowledges this is uncomfortable for people used to quarterly planning — "it's our job to get used to the new AI era." ### Coding and Software Development - **AI coding tools are "probably the most successful AI application."** On claims that people can build software from their phones: "If they feel comfortable doing that, it's totally okay. But you don't have to." - **Adoption journey**: start with lowest-risk tasks (unit tests, documentation) → build confidence, rules, skills, guardrails → push to all tasks; when engineers opt out, investigate why. - Current state: AI tools do **all implementation**; engineers focus on **reviewing, architecturing, and evaluation**. ### Code Review (stated as "really challenging") - Engineers now write thousands of lines/day vs. hundreds previously; traditional review cannot keep up. - **AI code review tools tried**: "helps a little bit, but we don't feel comfortable 100% rel[iant] on them yet"; human feedback remains "very, very valuable." - Changes made: - Engineers may **self-identify** that a PR doesn't need review; can merge but remain accountable. - If reviewed: **PRs capped at ~500 lines** ("nobody can do a meaningful code review" on thousands of lines). - **Stacked PRs** for large features. - **Avoid "rubber stamp"** approval — "the worst case" because it gives false confidence. - **Future goal**: automate the full lifecycle end-to-end, including monitoring live traffic, catching issues early, and automatically fixing them. Explicit qualification: **"we're not there yet."** ### Reliability and Hallucination - Traditional software "does what we implement... no more, no less"; GenAI systems hallucinate. - **Complete elimination of hallucination "can be very costly. Sometimes is not necessary, either."** Recommended approach: holistic, classifying which failures are acceptable. - **Acceptable example**: appointment scheduling failing 1 in 1,000 — user can retry. - **Unacceptable example**: reimbursement claim processing — paying $200 instead of $50 (or vice versa) causes immediate escalation. Mitigation: **multiple models review the same receipt; proceed only on agreement**; if unresolved, escalate to a human agent — "That's acceptable solutions." - **Release rigor**: - Hundreds of integration tests, continuously expanded. - Each test run **many times** with a required pass rate (e.g., **~90%**) because LLM behavior varies. - Post-launch: automated evaluation system scores each conversation against predefined **rubrics**; plus a **dedicated human group** spot-checking conversations to tune the system or the rubrics (checking if rubrics are too strict or too loose). - **New feature launches**: review ~20% of conversations rather than spot checks. ## Preserved Qualifications and Tensions - No single definition/playbook for "AI native" — Feng's three parts are his framing, not a universal standard. - AI code review tools: helpful but not yet fully trusted; human review still valued. - Full lifecycle automation: aspirational, explicitly "not there yet." - Mid-term planning difficulty acknowledged as unresolved and uncomfortable for veterans. - Hallucination elimination: costly and sometimes unnecessary — acceptable-failure tradeoffs are judgment calls, illustrated with specific Maven examples. # Observation Document: Speaker Roles & Provenance ## Video Metadata - **Title:** How to build an AI-Native Health Company — Dan Feng, Maven Clinic - **Video ID:** `01a15ca7-cddb-78bc-923f-fb4ceb7891e3` - **Format:** Single-speaker presentation/talk, apparently live (audience interaction and applause present) ## Speaker Inventory | Speaker | Role | Evidence | |---|---|---| | Dan (Dan Feng, per title) | **Presenter / sole identified speaker**; introduces himself as affiliated with **Maven Clinic** | "I'm Dan. I'm from Maven Clinic." | | Unnamed audience | **Audience** (non-speaking; participates via raised hands and applause) | Hand-raising exercise at open; "[applause]" at close | No **narrator**, **guest**, **host**, or other identified roles appear in the transcript. ## Referenced Sources & Third-Party Claims - **Unattributed quote (secondhand):** "tractors aren't to replace farmers, but the farmers who can operate the tractor will replace the ones who cannot" — explicitly flagged by the speaker as *"a quote I heard like a couple years back"* with no named origin. - **Named products/tools (mentioned, not endorsed formally):** - Cursor (AI coding tool, cited as widely used "last year") - Cloud Codes (transcribed name of tool staff switched to "this year"; transcription uncertainty exists) - Jira (task management) - **Company-internal systems described by speaker:** "Maven Intelligence" (AI orchestration layer), auto-evolve evaluation system, integration test suite. ## Promotional Segments - No explicit **promotional segments** (no sponsor mentions, product pitches, or calls to purchase) are present. The talk is a first-person experience-sharing presentation about the speaker's own company. ## Comment Availability - **No metadata supplied** regarding comments; availability is **unknown/unrecorded**. ## Provenance Notes & Uncertainties - Transcript is auto-generated quality; contains transcription artifacts, filler, and non-verbal annotations ([snorts], [clears throat], [applause]). - All claims about Maven Clinic practices are **self-reported by the speaker**; no independent verification is available in the source material. - Speaker name "Dan Feng" is established via the video title, not stated in the transcript itself (transcript says only "I'm Dan"). \>\> It's time. We can get it started. I'm Dan. I'm from Maven Clinic. Today we'll share the experience how we transition from a traditional technology company to AI native company. Before I started, I would like to do a little exercise. Raise your hand if you think you are already an AI native company. Okay, we saw a few. Raise your hand if you thought about it, but haven't started the journey yet. Okay, we saw a few. That means most of us is in between. Hopefully this talk can help you with that one. So, Maven Clinic is the largest digital health platform. We are focused on women and their families. So, we specialize in like maternity, fertility, parenting, menopause. We started our AI journey just 2 years back. At this moment, we built something called a Maven Intelligence. It's a orchestration layer across all our product to enable AI for everybody in this company and for our clients. So, AI is here and improving every day. I think adopting it is not an optional. Even you choose not to, your competitors will do. This is a quote I heard like a couple years back. I would like to share here again. Like a tractors aren't to replace farmers, but the farmers who can operate the tractor will replace the ones who cannot. Hopefully everybody here will become farmers who can operate your tractors. That's the goal. So, first of all, I don't think there's a one single definition what it means by AI native. And more importantly, there's no predefined playbook you can just follow and bingo, you become AI native. For us, it is really come down to three parts. One is internally with our AI tools, whenever it's possible. It can be as simple as like generating your daily summary, managing your meeting, create a Jira task, anything you need to do today manually, you should think about to see if you can use AI to do it. Whenever you want to ask other people to do something for you, you should be saying with yourself, I can use AI to do it. A lot of leaders in fact today at the Maven include our sales, sales, they use AI tool to solve those tasks by themselves now instead delegate to other people. That's for internally. Externally, we want to build AIs into our product, which achieve two goals there. One is really focused on improve our user experience. Second maybe help us reduce our operational cost. Like a like AI based like chatbot is really good example. It's 24/7, always available, can help our address issues, help our customer instantly. It's way better and cheaper compared to human agents. Thirdly, I think is more important, we need to think about our culture, process, the way we work, how we can change it so we can maximize what AI offers for us. I will touch it more on the following slides. So, when we come to adopting new technologies, there's always like screw three groups of users. One, there's some early adopters, right? For them, we don't need to do too much. Only thing we need to do is enable the tools for them and encourage them to share what they learn with the company. And what we need to really focus on is the one in the middle. That's a majority. We should build a shared AI infrastructure for them, build easy-to-use tools for them, just make the adoption as seamlessly as possible. More importantly, we should really listen to them, get feedback, consistently inputting. For example, last year, most of folks and Maven they're using cursor. This year, a lot of them switch to cloud codes. For us, we need to support the both. We need to meet where they are, just make feel they comfortable to use it. And for an older places, you always have a few slow adopters. They always have concerns, worries for the new technologies. For them, we just shouldn't meet where they are, understand what their concern is. But more important, we should be crystal clear with them where the company is heading to. So, AI is really good and execution if we know what we want to do. So, this is change how we should hire new people and how should we reward them. We used to the way we used to work is we have a senior engineer who sense the problem, come up with solution, and delegate to other engineers for implementation. So, we can work on it in parallel and be faster. But these days, we found the NASA and NASA engineers wouldn't like to delegate the implementation work to other people because these they already figure out how to solve the problem. They just use AI to solve it instantly. Delegating to other people means more overheads and less efficient. And also means like when you have a new people, you want to make sure they can solve the problem independently. They pretty much has to work on the traditional technical lead memo. We can We cannot afford other people delegating implementation task for them. Also, when we hire new people, we should think about what we are looking for. We definitely want to look for somebody genuinely interested in AI. The domain is moving so fast. We want them to keep learning. Also, help the team to stay on track. Secondly, is um with AI, engineers can do way more than they used to do. The boundaries between PM and engineers is getting blur- blurry. We found like a engineers who really understand the product. In fact, they can have more way more contribution than a traditional engineer who only focus on software side. And this is what we are looking for. And those deep understanding of the system, the ability to can handle complicated ambiguous problem is also very valuable. This is where AI land off. When we hire new people, this is also the people we are interested bring on board. For people we bring in, we want to reward them in the proper way. Even in our performance with review, we start ask, "Okay, what do you have done for AI side?" We definitely want to reward the people who leverage AI to multiple their impact. Although this is impactful everybody in the company. So, now we have the right tools, we get the right talent in the place. And we need to change how we work to maximize the benefit of AI. The we used the way we used to work is say, "Okay, we spend the weeks, sometimes it's the months to flash out the business requirements, finalize the design, and then do the implementation." Because implementation can be really expensive. If we didn't get the other part right in the beginning, it's it can be very costly to change it later. But in fact, we never get the sense and right in the beginning anyway for any of big projects. With AI, building is super fast. It's probably couple minutes you can get it done. Argument is really expensive one. So, we should really think about what's the best we can work, how can we deliver fast. It's still okay, you can think about what you want to deliver in one year. You can assume AI models can do anything you want in one year. Based on that one, really dream big to think what you can do in one year, but it should only serve as inspiration, inspiring, and directional. What we really need to focus on is what we want to deliver in the next two to four weeks, right? What we want to get to the PMs and designers is say, "Okay, tell me what I need to deliver in this sprint." And the engineer will focus on it and get it released if at the end of the sprint, if not sooner. Meanwhile, and the PMs, they have time to flesh out the next bunch of the requirements. If at the end of this sprint, they say, "No, what we decided two weeks ago is wrong." It's totally okay. We can switch the gear, get it fixed quickly. That also means like we prefer people not write pages or pages of PRD or TDD anymore. We prefer them to write just a short one or two pages. Everyone is really serve as communication, so we can iterate on it. The really awkward part is mid-term goals. Those like a three months, six months. It's very hard to plan these days. The reason is I don't know what AI models will be capable in three months. There may be multiple releases already. So, we prefer not focus on this one. But this one can maybe make it not very easy for most of folks who has been in this domain for a long time because traditionally we get used to have a quarterly planning or we plan it for six months. But it's our job to get used to the new AI era and learn how to work it efficiently. So, I want to talk about the coding and software development a little bit more here. AI coding tools is probably the most successful AI application. And it's really good and implementation. So, you probably heard a lot of people say, "Okay, I have this AI tools. Now I can even use my phone to implement software and automate every stage." If they feel comfortable do that, it's totally okay. But you don't have to. What I'm trying to say here is And maybe this is our journey, how we adopt those AI tools. We started with the lowest risk task, like starting with writing unit tests, documentation. Those things are very easy to verify and the risk is super low. By doing that, one we build the confidence. And we start to construct our own rules, skills, and build our barriers. And then we push to the whole engineering team say, "Now you should use these AI coding tools for all the tasks." When they choose not to do, it's the time we really want to learn say, "Why you don't do it?" And And this moment, we pretty much use the AI coding tools to do all our implementation. Engineers really focus on reviewing, architecturing, and evaluation. \>\> \[snorts\] \>\> So, and with AI coding tools, we are writing so much code these days. Code review becomes really challenging. So, for good engineer, used to they probably write hundreds of lines code every day. These days, they can easily write like thousands. If we keep do the code review as we used to do, we won't be able to keep up. We also tried the multiple like AI coding review review tools. It helps a little bit, but we don't feel comfortable 100% reliable on them yet. We still found those feedbacks from our engineers are very, very valuable. And that means we need to really change the way we are doing code review to meet where we are now. And couple things we have done. One is we allow engineers to self-identify whether they still need code review. If they think this PR is simple enough, I feel very confident, I don't need anybody take a look. We are fine with that one. We let them merge, but we still hold them accountable. And if they do want code review, we want them stay with the best practices. For example, each PR shouldn't have more than 500 lines of code because nobody can do a meaningful code review with the ones has like thousands of lines code. And we also enable the like stack the PR. What it means is that for big feature, and the engineers can bring break it into multiple PRs where people review the PRs and they can keep working on it. One thing we really want to avoid is a rubber stamp, we call it. Means like people submit the code review, you cannot really do anything to it. You just say blindly approve it. This is the worst case, we should really avoid because that's just give us false confidence. We think we reviewed it, it's good, and we release it. Meanwhile, we should keep working on our AI code review tools because we are thinking that's the future. So, at this moment, we use AI tools pretty much assist each step of our software development. Our goal is it will be automate the whole life cycle from end to end, from designing, implementation, and here is a fully release it. More important, we want the AI tools be able to monitor the live traffic and be able to catch the issue early and automatically fix it. That's what we are still working on, and we're not there yet. The last thing I want to touch a little bit for this presentation is about reliability. So, what it means is like for the traditional software, it does what we implement there, no more, no less. But for the Genex solutions, hallucination is there. We cannot ignore it. And there completely eliminating them is can be very costly. Sometimes is not necessary, either. So, the way we should do is really have a holistic solution even from the get beginning. For example, we can start with identify which failures is acceptable, which ones are not acceptable. For our AI system, for example, we have the functionality to help our customers to schedule appointment. If we fail well to 1,000, probably it's okay. I'm not saying it's a good experience, but the users really can just click the button again, we will reschedule for them. Probably it's okay. But if we help user to like submit their reimbursement claim, we cannot tolerate a failure because if people ask of $200, we issue them 50 or they ask 50, we give them 200. Each case will cause a escalation right away. For those cases, we have to put in extra stamps. For example, when we receive their receipt, we will use different models to review the same receipt. We only move forward if the results from different models agree with each other. If we really have trouble to figure it out which one is right, it's it's easy it's okay to tell the customer, say, "Hey, I have trouble to process your stuff. Do you want us to get you connect to a human agent?" We will move from there. That's acceptable solutions. And also we have should have a rigorous process to release our software. For us, we have like hundreds of integration tests, for which pretty much covered all the use cases we know, and we are keep adding to the integration test the suite. And the when we run the integration test, not only pass once is not good enough anymore, because the LLM can do different things. So, for each test case, we run it to many times. We consistently requires a high pass rate, like for example, 90% for all the time. And the more important, \[snorts\] and the after we launch the software, we have our auto evolve system evaluate carefully evaluate each conversation. We have predefined a lot of rubrics, what we think is good, what is bad. And then we will generate results, we will review the score. Besides this one, we also have dedicated a group, their job is mainly review those conversations. We will spot a check our conversations, that helps us to say whether we need to come back to improve our systems, or our rubrics is too strict or too loose, and we need consistently improve it. When we launch new features, then it's a time we say not only spot a check probably not enough. We really want to review like say 20%, and we can do it. This whole process make \[clears throat\] sure we we are really confident whenever we reach something, although we know hallucination is there. And that's pretty much all I have for today, and I can stay here to take up questions, and if you have other things, you can reach out to me. \>\> \[applause\]