Putting the Doctor on the Ambulance: Five Ideas from Innovation Talk, and the Research Behind Them
At our 3 August 2026 Innovation Talk, Labfront co-founder and CEO Christopher Peng went from ambulances in Ethiopia to Polaris Dawn. We've distilled five ideas from the evening and matched each with the public research that shows when it holds, including trauma mortality across three cities and Superhuman's product-market-fit score over time.
They set out to build an African version of a ride-hailing app. What stopped them wasn't technology. Most roads there have no names. At the Innovation Talk on 3 August, Labfront co-founder and CEO Christopher Peng started from that problem. The session was scheduled for ninety minutes, ran to a hundred and twenty, and nobody left early.
We went looking for the public research behind each of his five ideas. Every one of them has a counterpart in the literature, and the literature also marks the boundaries within which each one holds.
1. When you're stuck, ask whether that step is necessary at all
Ethiopia had no ambulance system, because until recently there had been no hospital to send people to. A friend whose family had practised medicine there for three generations opened the first emergency and emergency-surgery centre and brought him in to solve transport. A ride-hailing app's first question is "where are you?", and that question has no answer where the roads have no names.
Instead of solving "no street names", they went back and asked: does treatment have to happen in a hospital? As a private membership service they held every patient's records, so not necessarily. Specialist physicians got on the ambulance. Rather than bringing the patient to the treatment, they brought the treatment to the patient.
The research agrees, with conditions. A 1998 study in the Journal of Trauma (Mock et al.) compared deaths at the scene for the same injury severity: 51% in Kumasi, Ghana, with no pre-hospital system and an average of 102 minutes to hospital; 40% in Monterrey, Mexico, with basic ambulance care and 73 minutes; 21% in Seattle, with advanced care and 31 minutes. A registry of 12,816 patients at the ALERT trauma centre in Addis Ababa found only 10.4% arrived by ambulance, and only 31% even among the most critical patients.
But the effect depends heavily on the setting. Canada's OPALS study followed 2,867 major trauma patients: survival was 81.8% under basic life support and 81.1% after full advanced life support was introduced, and the severely comatose subgroup actually fell from 60.0% to 50.9%. Moving care forward pays off in proportion to the gap it closes. Where more than half of patients die at the scene, a doctor on the ambulance removes the deadliest wait. Where the gap was already small, it may not.
2. Hire too early and you'll be chased by your burn rate
He called this one of his big mistakes: bringing in people to take over development before the product had found its footing. He was blunt about the reason: he was afraid he couldn't carry the technical side himself. The cost is a chain. Hiring means payroll, payroll means being chased by burn rate, and being chased means you can only do whatever makes money fastest.
Sam Altman opens the hiring section of his Startup Playbook with "My first piece of advice about hiring is don't do it." Startup Genome quantified the gap: companies that scaled prematurely had three times the headcount of healthy companies at the same stage, while companies that scaled properly ended up with teams 38% larger, taking 76% longer to get there. The roles the report singled out weren't engineers but CFOs, customer service, database specialists and managers.
Data from the other direction is worth setting alongside it. Harvard Business School's Noam Wasserman tracked 212 startups: by year three, half the founders were no longer CEO, and four in five eventually handed over. In CB Insights' collection of post-mortems, one founder wrote "I wish we had a CTO from the start." The difference is timing. Before the product stands on its own, every hire is another salary. After it does, people are the only thing that scales.
He drew his own boundary, and it's worth keeping verbatim: this is the view of someone who doesn't plan to raise venture capital and wants to run the company for a very long time. If you're on the VC track, he said, don't do what I say.
3. Product-market fit: the feel camp and the score camp
Someone asked how he knew the product had found its market. His answer: if you have it, you know you have it. If you have to stop and ask, you probably don't. His signal was customers proactively bringing their friends.
That view has a pedigree. Marc Andreessen wrote in 2007 that "you can always feel when product/market fit isn't happening", and the signals he listed are all observable behaviour: customers buying faster than you can make the product, servers you can't add fast enough, reporters calling you. The point of this camp isn't that fit can't be judged. It's that the signal is too big to need measuring.
The other camp puts a scale on it. Sean Ellis's 2009 survey asks existing users how disappointed they'd be if they could no longer use the product; 40% answering "very disappointed" is the threshold. Superhuman rebuilt around that score for three quarters: 22% at the start, 33% after narrowing to the target segment, 58% three quarters later (Rahul Vohra, First Round Review, 2018). The jump from 22 to 58 wasn't waited for. It was iterated for, quarter by quarter.
The line is less scientific than it looks. Ellis himself wrote "admittedly this threshold is a bit arbitrary", based on a sample of nearly a hundred startups, and MeasuringU searched Google Scholar in 2022 and found no peer-reviewed study validating it. Feel tells you whether you have it. The score tells you which way to go. He was describing what it looks like once you're there. The ruler is for those who aren't there yet.
4. Start by solving your own problem, and don't wait for it to be perfect
A member asked where someone with a day job should start. You have the time, he said. What's stopping you is waiting for the perfect idea. The starting point isn't an idea. It's practice.
He built himself a calendar tool because nothing off the shelf solved his three annoyances: he couldn't see more than a year ahead, he wanted to pencil in trips before they were confirmed, and he wanted to know where his friends would be at the time. Whether the tool is any good is secondary. He learned by building it.
He also dismantled an idea a lot of people get stuck on: don't go looking for something everyone wants. It doesn't exist. If you genuinely need it, there's usually a group of people like you who need it too, and you're the only one who can spell out the spec for them. For most people there's an even more direct version: even if you never start a company, building things to practise working with AI is valuable for your career on its own. You learn what can and can't be built, and that judgement can't be picked up from reading articles.
5. The longer the conversation, the less reliable it gets, and that's measurable
His practice: cut every task small enough to finish inside what he calls the smart zone, then have the AI write a handover document to carry into a fresh conversation. The symptom that you've left the smart zone is that you've set a rule and it starts giving you something else.
Research has measured this. "Lost in the Middle" found that information placed mid-context gets dropped, long-context models included. NoLiMa, from Adobe Research and LMU Munich in 2025, tested thirteen models claiming contexts of 128k tokens or more: at 32k tokens, eleven fell below half of their own short-context performance, with GPT-4o dropping from 99.3% to 69.7%. Thirty-two thousand tokens is roughly the full transcript of a two-hour meeting. Anthropic's engineering guidance cites the same "context rot" and recommends compressing old conversations into new windows and keeping notes outside the chat. That is his handover document.
He added that an AI system shouldn't be one long conversation but a knowledge base that accumulates: dropping data in is only step one, it has to be read and organised into a form that can be cited later, and recurring judgements shouldn't be re-explained each time but distilled into rules. The details are his own method and we won't reproduce them here. His boundary is worth remembering: AI surfaces the information. People make the decisions.
The conditions under which each of these holds
The ambulance move works where there is no pre-hospital system yet. The lesson about hiring too early hinges on when you hand over the core. Feeling product-market fit describes a state you've already reached. Keeping conversations short works because a model's attention budget gets diluted. Experience gives you the conclusion. Research gives you the boundary. Knowing the boundary is knowing when a piece of experience needs a different approach.
He chose a hard problem and has spent more than a decade on it, partly because the problem is complex and interesting enough to hold him. A simple one, he said, he couldn't have stuck with for ten years. And money can't buy him into doing what he doesn't want to do.
Sources: Mock CN et al., Journal of Trauma 1998; Starr N et al., Trauma Surgery & Acute Care Open 2024 (ALERT registry); Stiell IG et al., OPALS Study Group, CMAJ 2008; Startup Genome Report Extra on Premature Scaling; Wasserman N, "The Founder's Dilemma", Harvard Business Review 2008; Altman S, Startup Playbook; Andreessen M, "The Pmarca Guide to Startups, part 4", 2007; Ellis S, "The Startup Pyramid", 2009; Vohra R, First Round Review, 2018; Lewis J and Sauro J, MeasuringU, 2022; Liu NF et al., "Lost in the Middle", 2023; Modarressi A et al., NoLiMa, 2025; Anthropic, "Effective context engineering for AI agents", 2025.
This recap of the 3 August 2026 Innovation Talk was compiled by the Innovation & Entrepreneurship Committee of Taipei Fusion Rotary Club. The cited research and commentary are the club's, not the speaker's. For sharing only; not medical, investment or business advice.