Last week I had Chaz from Keep Labs back on the CDH Lunch and Learn for round two. He opened with something that I'm sure everyone has noticed: everyone can build fast now. Now it's about figuring out what to build.
You might've felt this. You open Claude or Codex or whatever's on your laptop, with an idea in tow, type a few lines, and twenty minutes later you've got a working product. It looks decent. It might even work. But you can usually tell within a few seconds whether something was actually thought through or just spat out. I don't know what to call it other than a "slop gauge", and everyone's got one running in the back of their head every time they open up LinkedIn.
This issue isn't unique to any vertical. It's just the new reality of building right now. A non-technical founder can ship a working prototype in an afternoon, which sounds like the dream until you realise the tools might be going too fast for you to think something through enough.
Chaz runs product at Keep Labs, which builds a platform that supports people living with rare diseases. I used his work as the case study for the session, but the process he walked us through has nothing specifically to do with healthcare. It's the same trusted three-step thinking any of us should be doing before we touch a build tool, whatever we're building.
The One-Page Brief That Replaced His PRD
First thing he told me: he doesn't write product requirements documents anymore. Not because they're outdated, but because they try to do too much in one document and end up doing none of it well.
Instead he writes what he calls a product brief, and it only has to answer three questions:
What's the problem, and why does it matter? He frames it through the user first. A patient can't easily do something, and here's why that's a problem. If he can't explain that clearly, the engineering team looks at him like he doesn't understand why they're building it either. That reaction is the real test. If you can't explain the problem fast enough for someone else to get it, not just yourself, the thinking isn't clear enough yet to be worth building.
What's the goal? Not a vague mission statement. For the feature he walked us through, called Reflections, the goal was deeper engagement and giving patients a sense that the journey is going somewhere. He said something that stuck: in healthcare, if people don't feel like there's a destination, they check out. Even a well-built conversational product will get "are we there yet" energy if nobody feels like they're moving toward anything.
What are the core capabilities? He picked this up in 2019 running product at Equinox. It's just a list: I need to be able to do A, I need to be able to do B, I need to be able to do C. The minimum the feature has to support to actually count as done.
That's it. Three things, one page. He said it takes him two to three hours. Not because he's fast, but because he's done it enough times that the thinking is second nature now. The brief isn't a build spec. It's the document that answers should we even do this, before anyone commits a single engineering hour, and it works whether you're building a health platform or a booking tool for your local gym.
If you're a solo or early-stage founder, two to three hours can feel like a lot when Claude can spit out a working prototype in ten minutes. That's the trade Chaz is making on purpose. He spends the time upfront so what he ships afterward is the right thing.
Job Stories, Not User Stories
This is the part that changed how I think about writing anything down. Most of us default to the classic user story: as a [type of person], I want to [do a thing], so that I can [get a benefit]. Chaz says it's missing two things.
First, it doesn't say when. Products show up in people's lives at specific moments, not in a vacuum. Chaz used a subway rider in New York as the example: as a transit rider, I want to receive notifications so I'm not late for work. Sounds fine, until you ask when that notification actually needs to land. Are they still at home? Walking to the station? Already on the train? Switching lines? Each of those moments calls for a different decision, and a generic user story doesn't tell you which one you're actually solving for.
Second, and this is the bigger one, a user story stops at so I can, which only tells you the next thing that becomes possible. It doesn't tell you why that thing matters to the person's life.
That's where in order that comes in. Chaz writes job stories that end with the emotional payoff, not just the functional one. He gave an example from a feature they were building called Reflections. A patient can choose to start a reflection, or put it off until tomorrow. Stop the story at "so I can start it later" and an engineer reasonably asks: does it matter if they never do it? Who cares?
Add the in order that, and it changes. If a patient skips it too often, they stop feeling like they're being led somewhere. They stop feeling the week-to-week coaching they signed up for in the first place. That's the actual thing at stake, and it's the reason the feature exists at all.
"If the in order that is missing from the story, that part of the value is missing from the product. Full stop." — Chaz, Keep Labs
Swap "patient" for whoever your user actually is and the exercise holds up. A fintech founder skipping the in order that ends up with a notification feature nobody opens. A marketplace founder skipping it ends up with a checkout flow that's functionally fine and emotionally forgettable. The functional benefit tells an engineer what to build. The emotional one tells them why anyone would bother using it.
The Prototype is a Sketch, Not a Shortcut
Then he shared his screen and showed us the thing he actually builds before any code gets written for real: a fully clickable prototype, built in Claude, loaded with real test data from their own accounts. He was clear it's not shippable and was never meant to be. He called it a live sketch.
He used to use Bolt, but switched to Claude because Bolt tends to generate a mess of components and folders he doesn't need for something that only has to be a single page. The prototype exists purely so the engineering team can click through it and go "oh, I know how to build this now." He attaches a job story to every component in the prototype, hands the whole package to engineering, and lets them figure out the best way to actually build it. If someone on the team looks at a component and realizes they can fulfil the job story better than what's in the prototype, he wants them to do it that way. The prototype isn't gospel. It's a reference point everyone can see and argue with.
The bit that got me: he said if you're vibe coding something for a personal project, go nuts, no judgment. But if people are spending money and time on what you're building, freestyling it is close to disrespectful to them. You're asking someone to make your product part of their day. That's not something you sketch out in five minutes and call finished.
The Part AI Still Can't Do For You
Chaz's whole process, from brief to prototype, takes him a few hours, not weeks, so this isn't an argument for slowing everything down. The thinking has to happen somewhere, though, and it's genuinely laborious. It's the least glamorous part of building a product, and the one part AI tools can't do for you, because it's about deciding, in detail, what you actually want and why.
I see this play out constantly with founders in this building. The barrier to shipping has basically disappeared. A non-technical founder can now build a working app, a landing page, an automation, a whole product in a weekend, without writing a line of code. That's genuinely great. It's also exactly why the founders who win from here are the ones who treat the thinking as the actual work, and the building as the easy part that comes after.
Near the end of the session, someone asked whether Chaz's approach would work for population-level interventions and not just individuals. His answer applies to every founder in the room: it depends entirely on what you build it for. The tools can build almost anything now. Whether what comes out is good or slop comes down to whether you knew precisely what you were asking for before you opened the tool.
"We're not an automation company. We're a lived experience company." — Chaz, Keep Labs
Swap the words for your own product and ask yourself the same question. The tech will build whatever you tell it to. The job is still figuring out, in enough detail, what that should be.
