Product Teardown · Writing
Granola
Background
Granola launched into one of the most crowded markets – meeting notes – and still found a way to stand out. Founded in 2024 with a team of 4, it scaled to a $1.5 billion valuation with around 50 people and grew largely through word of mouth rather than distribution. Granola feels like a product built with a clear vision and a strong product sense – reflected in its design decisions, restraint, and deliberate use of AI.
What's behind an exceptional product experience?
- 1.Have a thoughtful vision for what humans do vs what AI does. Granola's vision was a contextually aware, AI-powered workspace that augments memory rather than replacing thinking. It brings you relevant context at the right time, rather than being a meeting repository.
This means returning control to humans: users can edit notes, inspect transcripts, and review sources for outputs. AI handles recall; people retain judgement.
- 2.Choose a narrow use case to feel magical. Granola had many potential use cases since the product is horizontal, but it chose to build for VCs first, then founders. Narrow scope let the team cater to reliability and edge cases. Details like echo cancellation for users with and without headphones made the experience feel reliable despite being unrelated to meeting notes.
- 3.Protect the feeling of the product. Prior to launch, the team cut 50% of features. Listening to every user request risked cluttering the app and converging to a local maximum, diluting the experience.
The team talks about whether the product has a soul: a sense of cohesiveness. Great products feel like they have an essence, rather than becoming a collection of requests. The role of the product team is not always to add more, but to protect simplicity and quality.
- 4.Stay in private beta to launch a more polished product. Granola stayed in private with 150 users for about a year. This constraint let the team test different interaction paradigms, ship multiple versions, and remove features without creating churn or frustrating a broad user base. Granola found product-market fit nearly instantly when it launched.
- 5.Embed into users' lives via things people do already. Meetings are perfect for building habits because they're already a part of people's days. Notifications at the right moment are welcomed rather than seen as spam because they remind you of something you already need. Habit loop = useful product + notifications at the right time.
- 6.Track whether users genuinely need the product. The team kept a dot plot chart to measure whether users depended on Granola day-to-day, not just merely whether they used it. This created discipline around keeping features that built dependence vs removing those that only generated activity.
- 7.Use scale asymmetries to your advantage. As a small startup with a few users, you can afford cutting-edge models that large companies cannot justify deploying at scale. This creates an opportunity to differentiate through quality per interaction.
Granola in action
Interaction patterns
- Enhanced notes after the meeting vs in real-time reduces cognitive load on the user
- Shimmer load while answers generate reduces perceived waiting time
- Templates followed by a '/' guides users to the next action
- Community templates lets users build on proven workflows
- Notifications only appear 5 minutes prior to a meeting
- Notepad feels lightweight – like Apple Notes or pen and paper
What I'd add to the product
Failure modes currently feel too invisible. I've had meetings fail to record and only realised afterwards. For high-stakes meetings, clearer real-time alerts could help improve trust and recovery.
Hypothesis: If Granola can identify common recording failure states and proactively guide users to recover before information is lost, users will perceive the product as more reliable and rely on it in higher-stakes situations.
Validate severity
- Quantify how often recording failures occur and identify common triggers (e.g. no detectable audio, audio routing issues)
- Measure % of meetings with recording health warnings, % that produced no transcript when there was an intent to record, support ticket themes, and user behaviour/trust following a failed recording
One possible direction
- Preserve Granola's lightweight feel while making failure states visible
- Build a failure state taxonomy, then map each cause to the right recovery path. For example, if background noise is high, recommend repositioning the device or changing recording mode
- Surface notifications when users can meaningfully recover – explain the likely cause and suggest the next action. The interaction should be near-instant and low-friction, so users can recover without breaking focus during the meeting
How I'd measure impact
Primary
- % recording failures detected and surfaced in real time
- User recovery rate (notified → action taken → recording resumed)
Secondary
- User trust / satisfaction after failures
- Reduction in "meeting didn't record" support tickets