How to Use AI to Survive (and Even Enjoy) Meetings | Sam Stephenson

Sam Stephenson describes Granola’s intended emotional effect as calm. The setting he designs for is the gap between consecutive meetings: someone is late, rearranging windows and trying to remember whom they are about to meet.

That setting explains the restrained surface and the decision to keep the transcript out of the way. He also admits the cost: some people cannot find it. The handrail metaphor captures the tradeoff. The product should support the person doing the work, rather than become the main thing demanding attention. The language about lowering blood pressure is a metaphor for that experience, not a measured health claim.

Stephenson says a pre-meeting brief is especially useful when meeting someone new without enough preparation. The aim is a small amount of relevant context at the moment it is needed, rather than an exhaustive profile.

After a meeting, recipes can ask what was missed, which question could have gone deeper or how a sales conversation might improve. Structured meetings can use a rubric or template to organize notes. These are reflection aids described by the speakers, not evidence that an AI opinion should decide a hiring outcome or that automatic notes are accurate at a universal percentage.

Repeated use accumulates detailed project context: who is involved, what was decided and how a discussion developed. Stephenson demonstrates using that context to begin an internal presentation outline, a role description or a feature announcement, instead of facing a blank page.

The important mechanism is reuse of the conversation’s substance, sometimes through a saved recipe. A draft still needs review for meaning and audience. The interview does not establish that a generated announcement is automatically complete, approved or suitable for public release merely because it draws on meeting history.

The host asks whether a manager could assess how other team members behave in meetings. Stephenson responds that Granola cannot simply inspect a report’s private meetings. He contrasts that with notes people proactively put into shared team folders.

That distinction shapes the examples of looking across sales calls or design discussions. The useful corpus is the material shared into the relevant space, not every conversation in the company. This is the founder’s description of the intended boundary in the recorded product; the interview is not an independent security audit or permission to inspect private user data.

The discussion separates native scheduled automation, which Stephenson says has been prototyped, from users already composing their own reports through API or MCP access. The host describes combining Granola information with other sources for a recurring email summary.

Stephenson says enterprise customers made it clear that the product must work with internal tools, even when its own interface is not the final destination. That is a workflow decision, not an assertion that every connector or schedule was already a finished native feature. More context and more generated briefs can also become more noise.

The idea of sending personal agents to meet first is a feature wish in the conversation, not a demonstrated product. A more immediate problem is the pile of tasks created by several meetings in one day.

Stephenson links that problem back to calm: an assistant should help a person get through the work rather than merely enumerate more obligations. The speakers also describe the exhaustion of switching among coding-agent threads. Their enthusiasm for building is balanced by a stated need for life outside work and room to think.

Stephenson describes design tokens, components and agent-readable instructions as infrastructure that helps more colleagues build consistent features. Ordinary settings pages can reuse known patterns instead of rediscovering the product’s visual language each time.

He does not treat that foundation as a substitute for difficult design decisions. Interactive core experiences still need exploration. Nor does the account of broad internal contribution establish that every contributor can bypass release checks. The distinction is between reducing repetitive implementation work and removing the judgment required for a meaningful experience.

The team moves between whiteboards, Figma and code. Stephenson says a mostly linear subscription flow may be easier to inspect as copy and screens on a canvas, while a brief integrated into a meeting requires interactive trials in realistic locations.

The demonstrated variations place the same brief in a notification, near the notes or beside a floating indicator. These are explorations, not all final shipped interfaces. He argues that a meaningful judgment also requires relevant personal context: whether a brief helps when late and stressed depends on its content as well as its placement.

23:55View full image

Stephenson describes getting an ugly end-to-end version into the app quickly, so colleagues feel its limitations repeatedly and have a reason to improve them. The public quality bar remains different from the first internal build.

The internal assistant provides another loop: combine logs, code, analytics and conversation context to investigate a question, then potentially create a coding-agent task or pull request. The demo is not evidence of infallible SQL or automatic safe production release. Shared contribution makes the tool useful, but does not eliminate the need to check its conclusions.

The interview ends with a distinction between shipping something and making it genuinely useful every day. Early internal releases, friends and beta users provide feedback, while details continue to be refined before a wider release.

Stephenson argues that when building becomes easier, deciding what to make and persisting through the details matter more. Time away from constant execution can help that judgment. The calm product and the balanced working culture are linked by the same test: does the system actually make the person’s day better?