疯狂时代里的平静 AI：Granola 设计哲学内幕，与联合创始人 Sam Stephenson

Sam Stephenson, co-founder and designer at Granola, welcome to The Cognitive Revolution.

Hey, thank you very much for having me on. It's fun to be here. I'm excited for the conversation.

I have been using the product a bit over the last few months, and then, scrolling Twitter as I am constantly doing, something popped up not too long ago that really caught my attention. It was a report from Ramp, which said that, I believe it was in the month of January, Granola was the number-two company out of every company tracked by Ramp—which I assume is pretty much everybody—in terms of the number of new customers added, trailing only Anthropic that month.

I thought that was an incredible feather in your cap. And so, I wanted to start there and just say: How are you doing it? That's a lot of new customers to be adding, and clearly something is really clicking. What would you say is really clicking and driving that growth for Granola?

Yeah, I was taken aback when I saw that too. I guess we know what's happening to us internally, but to see us among that company is a great feeling and it's very validating.

I feel like Granola's growing fast, and it's almost entirely through word of mouth—people recommending it to each other or sharing notes with each other. When we were starting, we thought we could build a thing good enough that people would talk about it with their friends, and that hopefully had some built-in product virality.

It took us a while to unlock some of those viral loops and to get that to start happening, but I feel like the thing's really starting to snowball at the moment. We're growing a lot month over month.

I definitely want to get back to the viral loops and get into more detail on that. Maybe just start with: Who are your customers? How do you understand them? How do you go out to meet them? How do you think about how they understand AI, how they relate to it, and what they want from it? What's the sort of character sketch of your ICP?

I think this is interesting because the character that we hold in our heads is probably more extreme than the average actual Granola user. When we set out to build Granola, I think we were most interested not in meeting notes. We were really just interested in playing in the space of inventing what are going to be the UIs and interfaces that let ordinary people who are using computers to do their work see the computer as a means to an end, not as this thing to geek out on and spend all their time fiddling with.

How do we help those people access the power of this new technology? Notes were a way of getting our foot in the door into their lives and starting to build a product that could be habitual and could let us do more over time.

We spoke to a lot of people in the early days in a very open-ended, very exploratory way, with no real agenda, just trying to learn about their work lives. I think the archetypal person that emerged as a good target user for us over time was somebody who's in back-to-back meetings all day.

That could be many kinds of jobs. That could be a salesperson, an account manager, a recruiter, an investor, or a founder of a company. It could be anyone in client services who is doing calls all day long, talking with clients and things like that.

And I think they appealed because not because we want to build a product that's only for them, but there's a great analogy my co-founder Chris brought, and I really like it. There's this kitchen utensils brand, OXO—I'm going to mess it up.

I think it was OXO, but I might be wrong. They had this thing where they would deliberately design products for people with disabilities—people who struggled to grip utensils, had only one arm, or had some other kind of disability. They deliberately designed products for those people, not because they just wanted them to be used by those people, but because if you succeeded at designing a product for the most extreme kind of user, you ended up creating a very friendly, easy-to-use product for the rest of us, too.

I think if you work in accessibility in UI design, this is a common thing people talk about, too. Our version of that was somebody who is running from back-to-back meetings all day, frazzled by the context switching, barely having time to go to the bathroom between meetings. Their calendar is just a constant block of stuff all the way through the day.

These people exist in real life, but they’re also the most extreme portrayal of a reality that all of us have to deal with pretty often in our lives. We felt that if we set our sights on building a great product for a person like that, then hopefully we would achieve it, but hopefully we would also just create a really simple, easy-to-use thing for the rest of us who still have those moments of frantically jumping between things.

Yeah, I like that. I’ve had a little bit of experience in my day as a product designer. Usually, I’ve been so frantic and hustling to try to get to some level of product-market fit that I’m not yet thinking of the extreme long-tail user, and maybe that’s a mistake. Maybe I should be reversing the order in which I’m thinking about it.

It’s an interesting flip from the way I usually have approached things, which is to hit the center of the distribution first and then work out from there. Could you give me a little bit more—I’ve seen some comments from other places around System 1 and System 2 thinking—but how could you describe a little bit more what that is? Obviously, people are busy. Everybody’s short on time. But what does that translate to in terms of what they are unable to do that you are specifically trying to design around?

Yeah, yeah. I think us software builders, myself included, fall into this trap way too often of assuming that the user of your software is coming to your software in this calm state of mind where they’re going to give it their full attention, think through their actions, and be capable of stringing together quite complicated sequences of maneuvers in the software to do what they want to do.

Because of that, we feel like we can get away with pretty sophisticated, complicated bits of software that people have to learn and develop mastery in over time. Sometimes that’s the case, but I think it’s probably way less often than we would like to think.

The reality of work for most people who work on a computer is way more reactive and chaotic. So much of the time, people are not operating with their rational, methodical parts of their brain. They’re in a reactive, System 1 kind of brain, if you’re familiar with that.

You wake up in the morning, check your inbox, and think, “There are 3 things there that are burning fires and I have to deal with them right now. But I also have a meeting starting in 20 minutes. How am I going to juggle all of this?”

Then they’re just in a constant state of feeling behind, feeling overwhelmed, and never quite getting on top of things. I think that’s the reality for a lot of people at work. As software designers, we need to assume that reality and design our software to fit into it.

Yeah, that immediately calls into question the way that most people do user testing. It’s been a while since I’ve done this, but when you sit down with somebody and say, “I would just like to watch you use my software, and I’m not going to interfere at all,” you are immediately putting them in a state of full focus on this because they don’t want to look stupid to you, if nothing else.

That, I think, is immediately insightful. Do you have a tip for how to user-test in a way that captures that real-world, frazzled state of mind, as opposed to the kind of best self that you don’t actually expect to get from new users most of the time?

Yeah, it’s a great point. I feel like I’m guilty of the same thing all the time, too. You want to watch someone use your thing and get validated that they understand it.

One thing we found incredibly helpful is, whenever possible, when we’re talking to a user, I’ll try to get as grounded as possible in the reality of their working day and how Granola is going to fit into it.

This is hard when you’re watching them use the product live, but, for example, when we were thinking about introducing folders in Granola or some kind of organizational principle, the way we started interviewing people about it was that we would ask them to share their screen and bring up Granola. Then we’d go to their Granola home screen, where they had a list of all the meetings they’d done.

We’d go meeting by meeting and I’d click on one and ask them, “What was this meeting about? Who was there? If you could share these notes with someone, who should see them? What would you think about organizing this in your head?”

They’re still in an interview and in a rational state of mind, but they also can’t lie about the facts of what’s on the screen in front of them, what notes they took, and what meeting actually happened.

I think the trap I’m constantly trying to fight when I’m talking with a user is that as soon as you get into layers of abstraction, when they’re talking about theoretically or generally what they do, then you can’t trust any of that. You’re getting the imagined view that person has of themselves, which is often so different from how they actually behave in the real world.

We did a similar thing with people’s calendars, getting people to pull up their calendars and using that as a forcing function to talk about the reality of their day and what’s happened in their day. It was really helpful for the same reason.

Yeah. And then I guess that’s helpful for discovery, talking to people and learning about their work and how Granola might fit into it. In terms of evaluating stuff we’ve built, I think we’re very dependent on how it feels for us to use it ourselves.

Now the team’s a little bigger, so we can observe people on the team using it in the wild. I find that’s maybe more useful and telling than getting somebody to talk about their experience, because you can literally sit in on a sales call and quietly watch somebody on our team using Granola on the call. I get a much less filtered version of what they’re actually doing with the product.

That’s interesting and helpful. I’m imagining an even more comical version: you sit down with somebody, immediately a fake fire alarm goes off in the background, and then you spill your coffee. You might have to get through the institutional review board before you can do something like that.

I want to get into how this is all translating into the actual form-factor design decisions of the product, but before we go there, just on a philosophy level, one of the big tensions—“tension” might be a little bit of an overstatement—is that we hear a lot in the AI space about how AI is going to do the routine work, the stuff we don’t want to do. It’s going to take care of the drudgery, and the upside of that is going to be that we get to be our better, more System 2, more strategic, higher-level-thinking best selves.

Okay, that’s great. But then the other reality of product design, which I think you’re embracing, is: meet people where they are. So I’m wondering, in the fullness of time, or in the most successful form of the product, are you still meeting people with a jam-packed calendar who are stuck in System 1 and helping them manage that reality? Or do you think you are ultimately helping them get into that System 2 state, which they’re not in today?

If so, that would maybe imply a different regime of product design in the future. Do you come down on one side of that debate, or do you manage to find a balance between those two competing kinds of thought?

It’s a good question. I think both. I feel like we’ll be able to make progress in some areas faster, and in other areas, we’re not there yet.

There are so many tools out there trying to be a work assistant, an executive assistant for you, or an agent helper that understands what’s going on and helps you do your knowledge work. I’ve tried a lot of them, and I think the thing that they struggle with every time is that knowledge work is just so messy and nuanced. I think we’re still a long way off from AI having access to all of the information about a person’s life and understanding all of the social nuance: What’s my relationship with this person? How should I write when I write to that person? How should I rank the importance of what they’re asking for versus the importance of the other things I’m being asked for?

The to-do lists that these things create for you, or the drafted emails that they go and write for you, can look like they’re really going to help when you look at a screenshot. But when you actually engage with the content, so often, if they miss the mark even slightly, they’re useless. They’re almost there, but I’m just not quite comfortable using them. But they fail. I think we’ll get there. I think models will get better, and it’ll get easier to connect all the tools you need to connect, but I think it might take a surprisingly long time before we get there.

We want to be playing in that space, too. The game for us is figuring out how to be surprisingly unambitious in the kinds of tasks we promise to help you with. I think it’ll be a while before Granola can help you with the thorny, top-of-mind, most intense, burning fires going on in your work life. But I could definitely see Granola helping you with the menial stuff that you keep putting off because it’s not that important, there’s a lot of it, and it’s boring. I think just being very deliberate about where we focus our attention there will mean we can help and be more effective in helping you more quickly.

In terms of helping people get into System 2 mode, I definitely see that as the lens we have to take, and that’s how we have to approach it. I think there’ll be surfaces in the product that are designed for you to spend more time in them and to do more thinking work there. The full-screen chat interface we have in Granola now, which has access to all of your meetings and all of your company’s meetings, is designed to be sat with and used in long-form conversation. I’ll use that to write posts or job descriptions, or I’ll use it to analyze what’s going on in a certain part of the company.

It’s a very different mode from the meeting notepad, back-to-back-meeting moment, and that means we can do different things design-wise.

Yeah, I like the multi-meeting feature a lot. That was one of the biggest things that I found particularly cool about using the product.

Let’s talk about the actual design a little bit. Actually, let me take one more beat on what you think the barriers are to that kind of deep context.

Personally, I’ve made progress, and I’m obviously an early adopter and willing to put in the work. Regular listeners have heard me talk about this a little bit, so I’ll keep it brief. Over the last couple of months, I’ve been really investing in making sure that whatever agent I’m using has enough context, so that it’s not failing for lack of context.

That has involved a pretty tedious process of exporting everything from the systems where it lives: all my emails from the last 5 years, all my Slack messages from the last 5 years, DMs across all these different channels, all the calls that I’ve transcribed over time, and even all the podcasts with all the speaker-recognition diarization. All that now lives in a single database on my computer, and the agent can query it.

So it’s not for lack of access at this point to my general circumstances that it fails. I’d say it has definitely moved the needle in terms of how often I can actually say, “Hey, can you write an intro to this person? Look up my history with each one and my pattern of intros,” and actually get something out that I’m, if not immediately ready to send, at least able to use. With a little tweak, it’ll get there. I feel like I’m starting to see the promised land. I wouldn’t say I’ve entered it, but I can see over the hill at least a bit.

What do you think is going to make that so slow for most people? Is it going to be trust? I guess we could also imagine that the systems themselves are going to try to hoard their data and prevent people from exporting it all and doing that. Exports from Slack are not a ton of fun, to pick out one particular platform. What do you see as the fundamental barriers that keep that from happening in the next quarter or two?

Everything you said makes me feel like it’s the things that you’re doing. The machine is only as good as the context you’ve given it, as you’re saying.

A lot is possible nowadays on a personal level, getting all your stuff into one place. It’s much tougher if you work at a company, where a lot of the context that needs to be connected is inside a company with all of the complicated permissions. You’ve got to get security to sign off on connecting all the tools together and things like that. Things are still way more fragmented there for most people.

A lot of Granola customers are surprisingly progressive, I think, in how much they’re willing to let employees explore this stuff and figure out good workflows. I think everyone realizes that we’re in a moment where, if you don’t, you’re going to get left behind really quickly.

I think context is a big one. Then there’s just the level of personalization and memory that’s necessary for the agent to do a good job, which I think is maybe underestimated by a lot of software. The agent has to know a lot about you, the people you work with, the projects you’re working on, and the priority level of things.

It’s possible, with OpenClaw or any of the general-purpose agents, to teach them those things if you’re extremely proactive today. But the average computer user is not extremely proactive in setting these things up. I think the job for us is to make as much of that happen in the background as possible.

So that you don't have to think, and you just get useful stuff put in front of you every time you turn on Granola.

The point about permissions is funny: how simple that point is, and how, in theory, easy to resolve it would be, but also how fundamental it really might be for a while yet. Notably, I am an admin on all of the systems that I was using. And I do think the ability, at least for me, to get that unified view that crosses personal and professional and just puts all of me into one database has been huge. I just wouldn't have it if I weren't the admin on all of the systems.

And I think it probably would be pretty hard to talk the admins into allowing me to do it if I wasn't myself the admin. So I definitely see that as a real challenge. Presumably, you could get around it in the not-too-distant future with computer use. You don't necessarily need the Slack API if your computer-use agent can just go trawl through it. But still, you're probably going to be told explicitly you're not allowed to do that. So that'll be another barrier: just outright rules.

Yeah, that's really interesting. It makes me think of a context-as-a-service startup as an interesting opportunity.

Yeah, I feel like innovation in this area would unlock so much for so many companies and all of us at the moment. How do you make the agents understand what's okay to be shared versus not okay to be shared, and who should know what kinds of information and things like that?

Granola defaults to private for everything. Every note you start is only visible to you unless you take an action to put it in a shared space, because conversations are potentially really personal. You only have to say one personal or dodgy thing to pollute a transcript and make it not okay to share with the wider organization.

But that gives us a really tricky design problem. So much of the value of transcripts in Granola is them being in a shared space where the company can collectively access them. How do you help those end up in the right places while also not putting information that shouldn't be shared into public places? It's a tricky one. We haven't nailed it yet. We're trying stuff, and it's getting better, but we could do a lot better still.

Yeah, that's interesting. This is an obviously AI-pilled take on the question, but my first instinct would be to run the transcripts through the AI. I actually do this sometimes with the podcast. Especially if we get into politics or whatever, I'll sometimes run the transcript through the AI and say, “Is there anything in this episode of this podcast that the guest might regret having said publicly?” or something like that.

I would say they're pretty good at coming back with sensitive things. These are meant to be public conversations, so it's probably a little bit more obvious in general what is going on and what would be sensitive or not. In the context of private company internal conversations, you've got a lot that the AI doesn't have background knowledge on. But is that kind of the direction that you're headed? Try to use the AI to help surface these potentially sensitive things for people?

No, we're tinkering with this a bunch at the moment, yeah. I feel like there probably is a world where we could automatically put stuff in the right places 99.98% of the time. And the jury's out as to whether that's enough for people. If there's even a tiny risk that something sensitive goes into a public place, then that's not okay for a lot of people.

But we have, I guess, a basic version of this at the moment. When you finish a note, Granola will auto-suggest the folder it should go into. And that's an LLM on the back end. It's looking at the call, looking at the list of folders you have, and the characteristics of things that usually end up in that folder, and suggesting the one that it should go in.

I think it's not accurate enough for us to turn that on automatically at the moment, but there's a world where it could be with more work and better models.

Yeah, I hear better models are coming soon, so that trend doesn't seem to be stopping anytime in the immediate future.

Okay, let's talk about inference budget, because some of the things you're saying there are really interesting. They very much feel like the future, and also I'm not sure how you're going to make it work at the current price point. So I'm wondering how you're thinking about that.

It's my full-time job to be a student of AI, and it's a very justifiable business expense for me to pay whatever my inference bill ends up being, and it's just me. When you are a company, you've got to be a little more disciplined about that. And when you are offering a product at a fixed monthly per-seat price point, that is another level of that problem.

Maybe I've missed it, or maybe I haven't hit certain limits or warnings or whatever, but one thing that jumped out at me as I was reflecting on my use of the product is I've never seen a message saying, “You have this many credits this month,” or, “You're approaching that limit,” or, “This action is going to use this many things.” As far as I have experienced, it's always been just use it, and it feels like it's unlimited.

So maybe tell me if I haven't hit certain limits or I'm missing things, but that's an interesting design choice. It also has me thinking: are you guys in the Uber phase of, “Who cares what it costs? Let's just make it great, and we'll worry about our margins later”? Or are there tricks, or maybe usage patterns are such that it actually is working economically? And how much does that matter, especially when you want to go into these really deep contexts? When you're getting into it, easily now, it can be a dollar-plus for a single API call.

If you throw 10 different meeting transcripts into Claude Sonnet alone, you're getting to a dollar. So, if you're going to then say, “Okay, I'm going to try to organize your folders with this really full contextual awareness,” you're starting to spend real money, right? You're starting to see why Intercom's revenue is going the way it is. So, I guess there are a lot of directions to go there, but broadly, how are you thinking about inference budget and how it relates to driving the futuristic value that you're describing?

Yeah. I think where we're at today is really a function of where we're at as a company and how we've prioritized things over the last couple of years. When we were tiny—pre-launch and around launch—I think we explicitly told ourselves, “There is no budget. Whatever makes us create the best product, we should work on that.” Just creating a good product is hard enough. When the user numbers are small enough, it's a waste of time to focus on optimizing cost.

Granola was actually really expensive when we launched because so much of the cost was in transcription APIs, and the cost of that has gone down a lot as we scale and as the technology has gotten more commoditized and cheaper. So, that was the early days.

I think today, most usage of the product is the notes, and that's a pretty predictable cost. The number of meetings someone does has physical limits to it, it averages out over the course of a month, and you can figure out what margins you're comfortable living with there. I do think, as Granola has sophisticated users who have lots of meetings and want to be able to chat and do stuff with it—do stuff with large amounts of meetings—they rack up pretty big bills, which we swallow at the moment.

Over time, as Granola transitions to more directly doing work for you, rather than just being a kind of companion or aid or whatever, I think we'll have to look at the pricing plans. Usage-based pricing, like Cursor or a model, makes a lot of sense. But I think there is something very nice and transparent about paying a price and getting a thing. Especially while people think of us as a meeting-notes app, where you bring it to your meetings and get meeting notes out, and that's the core of it, people really like the simple seat-based thing.

Yeah, that echoes a lot of my experience and general advice I've given over time, although you've taken it to quite a bit larger scale than I ever have, that's for sure. But I do think people in general shouldn't optimize too soon on cost. Then the question just becomes: can you get all the way to a unicorn valuation before you really have to get serious about that? I guess the answer is yes, you can.

Yeah, I kind of agree on that. We have a burn-rate line that we keep up to date, showing what happens if user growth keeps going at the rate it's going and depending on how much the product costs. There was a point about a year ago, or about 6 months after we launched, where, from where we were then, with what Granola cost, if you plotted it out a year from then, it got terrifyingly expensive. It was distressing to look at, but the transcription costs have gone down a lot for us. I think there was a time when half of our burn rate as a company was going toward transcription. That's a lot better and more under control now.

I think the pendulum might actually swing back again as we do more LLM stuff and work-assistant-type stuff over the coming months. It'll probably get more expensive for us, and I think at some point that's going to trigger a, “We need to think about usage-based pricing.” But for now, we're comfortable with where we're at.

Yeah. And then there could be countervailing forces there, too, in the same way there have been with transcription. Obviously, there's been a lot of downward price trend in model costs, which are dramatically down for a given level of capability, anyway. We like to tell ourselves that things are going to get cheaper, but the new good models are always so enticing that—

I think of this as an Emad Mostaque idea. He used to be the CEO of Stability AI, and now he has the Intelligent Internet Project, and he's a huge believer in satisficing. He's like, “Yes, so far every new generation of models, everybody's found new utility in it. But how much longer is that really going to go before you'll get to a point where something really will be good enough for a large majority of general knowledge-work cases, and the best models will really be kind of doing the genius-in-a-data-center thing?”

Do you really need a genius to turn your meeting notes into a follow-up email, or is there a point where you can let the cost come down again? I suspect that there probably is.

On transcription, I don't know if this is something you can share or want to share, but how does transcription work today? It's pretty fast. I noticed that in using it, and it was so fast I was like, “Is this running locally?” I think there are small models that maybe could run locally, but I wasn't sure. So what can you tell us about how transcription works, or what have you learned about transcription that you think maybe is underappreciated?

Yeah. The way it works is pretty simple. We record audio from the microphone and the system audio of your computer, and we pipe those to real-time transcription APIs from third-party providers. We work with a couple of those, and it's all cloud-based APIs.

We transcribe in real time for a bunch of reasons. It's very comforting to see the transcript come in real time. You trust that the thing is working. It means we can generate notes as soon as the meeting ends; we don't have to wait for the notes to arrive. It also means we can discard the audio. We deliberately don't hold on to any audio from the conversation. I just think it's far less creepy to only be keeping a transcript and not the full-on audio recording.

There are a lot of trade-offs there. Real-time transcription is a lot worse than if we were to send all the audio in one go and wait a minute for the transcript to come back. The quality is a bit worse. The speaker separation is a lot worse. There are a lot of trade-offs, but overall I think it's the right move for us.

We're constantly looking at transcription because it's one of the most fundamental technologies in Granola. If you improve that by 10%, there are a lot of knock-on effects to the rest of the product. I think it probably makes sense for us to move to on-device models at some point for speed and cost. Although speaker separation is something where, if we can make that better in the product, it will make everything else 10 times better.

I can also see us just chasing whatever provider or solution is going to get us to that. We have to stay nimble. We've architected the product so we can swap out transcription models fairly quickly and easily, and we're constantly trying new ones and trying to figure out what the best strategy is there.

I don't know if you want to name names, but I'll tell you on my end: I'm a pretty happy Deepgram customer. I don't do real time because I don't really need to, but I have a whole series of skills where, after we record, I'll get the audio out of Riverside and send it over to Deepgram to transcribe. Downstream of that are a bunch of other things: clip ideation, clip creation, and so on and so forth.

These days, I'm even making songs in Suno that include key phrases and fun phrases from the transcript. Is there anything else that you would suggest people try? Again, is there anything you think is underappreciated, or anybody you would want to shout out as being particularly good?

Deepgram and AssemblyAI are the 2 main providers we work with. Both are great. We've used Deepgram—I think we settled on them before launch—and every time we evaluate them, the models are good, and we can't find a better one. We've been using AssemblyAI for a while now, too.

I think we actually split traffic in the desktop app between both of them because they're comparable, and it's helpful to have redundancy since it's such a core infrastructure thing. We're already happy with that. We just keep our eyes open for how to make this faster, how to get better speaker separation, or how to improve quality all the time.

Totally makes sense, even just for API redundancy. We're definitely entering a world where uptimes ain't what they used to be. I haven't had any problems with Deepgram's API uptime, to be clear, but if it's 98.something percent, you want to have a fallback, if for no other reason than you don't want to go down just because one of your API providers goes down.

Yeah, people really screw up. When Granola goes down, you notice very quickly, and it's a very painful thing. The redundancy is important.

Okay, you mentioned this idea of not storing audio.

So that was definitely something I also wanted to dig into from a design perspective. I think there are multiple different layers here—give me all the layers—but the layers that I'm noticing immediately, as you said, are that it's less creepy if it doesn't keep the audio.

I would be really interested to hear your thoughts on the way people are thinking about AI and being surveilled, entering this realm where certain powerful entities are indicating their interest in processing large amounts of data on individual citizens. There's that out there, and then there's this idea that we're doing it to ourselves, which we obviously have the right to do, but then we're also doing it to everybody around us as we're doing it to ourselves.

This also relates, I think, to the decision to have the product work at the operating-system audio layer as opposed to joining the call. Everybody has seen—and I actually use both in today's world—a call-joiner note-taker, and then I also have Granola on my computer, and they both do their thing. Again, this is something I do because I'm weird and try to use all the AI products. I don't think most people need to have multiple note-takers on every call.

But it stands out, right, as the sort of thing that works on your computer and works at the audio level. This does mean that it can happen without people on the other end of the call knowing that it's happening. You do have guidelines and some features for how you should talk about it, including one feature that allows you to automatically put a notice on the calendar invite that says you'll be using Granola for this. I don't know how many people actually do that.

What are your thoughts on privacy, surveillance, disclosure, and consent? What really matters in this case? Is it really that big of a difference if it's audio versus the transcript? I don't have a great intuition for that, but it's not immediately obvious that I should be that much more comfortable just because it's a transcript versus the original audio. I'm sure you've come at this from every angle. Tell me everything.

This has been one of the sticky questions that I think we ended up grappling with in the very beginning, making decisions about being a desktop app and everything. It continues to be something we have to keep looking at and improving today. Now we have much bigger enterprise customers using us, and they have much harder requirements than the average person spending a lot of time on Twitter who finds us and downloads us.

I guess at the beginning there were a few things we wanted to optimize for. We wanted people to never have to think, “Can I use Granola for this meeting, or should I use Granola for this meeting?” It should just work wherever you're having a conversation.

At the beginning, we thought we were really just getting notes. That's all. We toyed a lot with whether we should even show the transcript, or whether the transcript should self-destruct after a little while, because the value we're giving to people is really just the notes. I think we learned pretty quickly that notes are good for humans, but the transcript is amazing for LLMs to do stuff with, so we keep the transcript.

But we're not interested in having a word-for-word record of the conversation that would hold up in court as, “He said this,” or, “She said this.” All Granola needs are the notes of what happened and enough detail to give the LLM the knowledge to go and do the work it needs to do. We don't need the word-for-word record.

Because of that, audio doesn't really matter. Initially, when we first started giving the product to people, we stored the audio in an S3 bucket. We said, “We're not going to use it now, but at some point in the future, there will probably be a way we can train a model on all of this audio, and it's going to make everything way better, so let's just keep it, just in case.”

We lasted about a week, and then we said, “No, this is too creepy.” It makes the product feel heavy and serious, like a thing that you're using against people, and none of that felt good, so we turned that off. That's how we got to just keeping the transcript.

On the question of consent and letting people know how to use it, Granola is a tool that you can use on your computer. If you want it to be done quietly, where nobody knows about it, then you can. Our stance is that it's a tool, like Voice Memos on your phone or a notepad, where you can record what's happening. It's on you to follow the laws wherever you are and to disclose to people that you're using it.

I think there's no reason why Granola should be hidden. It's in our interest for Granola to be out in the open and for everybody to be on the same page that it's being used. It's great for us in terms of growth and for people discovering us and learning about it. We handicap ourselves by not being a bot that joins the meeting as a huge, glowing orb with a logo on it that people can discover.

We've built some ways to help users disclose it, and we're working on a bunch more to make it more transparent that you're using it, because it's in everybody's interest for that to be out in the open. That's where we're at today.

I do think Granola is a tool for work primarily. People use it in their personal lives, but it's primarily for work. I believe that over the coming years, it's just going to become more and more normal that people transcribe conversations at work. There's so much upside to it, and I think we and others will figure out how to help mitigate the downsides so that it becomes a default.

We used to get a lot more questions about privacy and consent when we started 2 years ago, and we get much less now. People are much more comfortable with it already, and I only see that continuing.

I do think it's very different talking about a work context and a personal context. The always-on wearable thingamajigs are going to have a real hard time navigating the privacy question in people's personal lives. We have it much easier. Our meetings are a set piece where you sit down and all agree that you're going to do work together. It's a nice social moment where you can have a social contract around recording the conversation, and that doesn't exist in the rest of your life.

That's roughly how I think about it today, but we still have a lot to figure out there.

It's interesting how much you've already seen a shift, and I do feel like you're probably right that there's just going to be more and more of a shift because the value is really hard to pass up.

Your comment about potentially having 3 layers—the raw audio, which you don't even keep; the transcript, which you serve up and maybe don't need to keep but which is really valuable; and then the notes themselves—I do see in the product today that there's grounding of answers and notes to specific moments in the transcript, which I think is huge for confidence-building, if nothing else, and the ability to dive in and sanity-check.

The most superficial layer, in theory, should have full value but sometimes doesn't: the notes themselves. I wonder how you think about that in the context of the ever-more-AI-ified future.

One thing I'm doing right now is that, like many people, I've got my main personal computer, and then I've got my new Mac mini that's riding shotgun with me. On my main computer, that's where the database of all my contacts that I mentioned previously lives, and that's where Claude Code is my go-to because I trust it the most, certainly relative to God knows what open Claude model with who knows what model in there.

On this computer, I'm logged into everything, too, so there's another consideration. I basically run my agent on my computer as an extension of myself, where I'm giving it real-time instructions. It's a co-pilot model. It's agentic in the sense that it can do stuff, but it's a co-pilot in the sense that I don't have it doing super-long-running loops or waking up when I'm not around. It's taking explicit direction from me as the main mode, and because of that, and because I generally trust the provider of the model, I'm pretty comfortable with it having such deep access.

A question I'm thinking about a lot right now is: for this agent on the other computer, what sort of access should it have? What should the model be for how it gets information about me?

One of the things I'm experimenting with is basically creating summaries. Right now I'm going through these full 5 years and creating a monthly summary. Then I plan to create an annual summary, and I have a few other views that I'm thinking about, like project-level: what were the projects that were discrete things, and which of those are active?

Then relationships: across the last 5 years, what is the surface-level view of all the relationships that matter, and what is the deep context on those? I'm thinking maybe that's what I provide to the agent that I'm thinking of more as the autonomous thing.

This is the one that I do plan to let go and do work without me. It will wake up and check its inbox, and it's going to have its own email and the ability to send email, perhaps without my review. Maybe a more abstracted understanding of me is the right thing, or maybe the other option I'm toying with is that the agent should call the personal agent and they can talk to each other.

The one that represents me can ask, “What is the least information that you really need to do a good job? Maybe I'll give that to you.” But I'm still not quite sure I trust that dynamic either, right? Models are certainly very foolable. They're not adversarially robust to attacks on information extraction. I don't know—any tips for me on how you think I should be thinking about this in a more sophisticated way?

No, I don't know. I think you're already more sophisticated than me, though. I like thinking about it as humans I would be interacting with; that really helps me think about it.

We have an executive assistant on our team who helps Chris and me with a bunch of stuff. If you work with an executive assistant, they can only be as good as the context you give them and how up-to-date they are. But I wouldn't want them with me every moment of the day, or every moment that Chris and I are together. I like being able to talk with just Chris in the room and to be able to speak freely and not worry about anything outside of the relationship we have.

That comes at the cost of our executive assistant not having the full picture of everything we talked about. But we have touch points to give them enough to do their work and go do things. I'm not sure anyone's really figured this out yet, but I feel like we need to figure out those kinds of ways for agents to interact with each other.

I think forgetfulness is a thing that we don't think about very much with these things, too. It's baked into all of us as humans for the fidelity of our memories to drop off pretty quickly. I feel like there could be a lot of cases where that's a feature, not a bug, for agents, too. It's an elegant way of diffusing the dangerous stuff from the transcript, from your emails, or from anything if stuff gets fuzzy pretty quickly in the agent's memory.

Yeah, yeah, yeah. I like that a lot, actually. I've been toying with this idea of agents that—and there are a lot of open questions here, many unanswered questions—but the idea of agents that would get smaller over time, literally in terms of the weights of the model being gradually pruned down, so that the model—in theory, the agent—sort of settles into its niche and can be very good in its niche.

Over time, as it gets smaller and smaller, you get efficiency out of that, and you also get the assurance that they really can't do anything else. I do think there's a lot of design space. In general, with AI, we're doing this depth-first search on this one particular architecture with this one particular vision of the everything AI.

I really wish we were doing a lot more breadth-first search before going so deep on one particular thing, because it seems like we're baking in a lot of decisions on trade-offs just by having one main thing that everybody's chasing. There are all these different scenarios and contexts, and just different people probably want to make decisions very differently. I do wish we had a broader, wider view before we get to AGI.

It's odd that we're taking the first AI that worked straight to AGI, as opposed to exploring a bit of a wider sampling of possible AI design space. Coming back to Earth: features. I would say that, of all the AI products I've used, Granola really stands out for maybe being the most disciplined about feature bloat.

That discipline has got to be something that you are holding the line on incredibly purposefully, because obviously, in today's world, we can vibe-code our way to new features 10 times before lunch. In a world where you could code anything, you guys have made the very disciplined choice to keep the number of features to a relative minimum. How do you think about that? Why are there not more features?

Obviously, there's something to do with people being overwhelmed as they're encountering the software. But how do you think about what features actually ought to carry enough weight that they get promoted and put into the product?

It's a good question. I think you're right about us being cognizant of keeping the product feeling stress-free for people who are operating in that stressful environment. That's a lot of it, honestly.

For the core flow of the product—the thing that pops up before the meeting, where you click the button, have the notepad with you during the meeting, and then that turns into generated notes afterward—we are very, or at least I'm almost, paranoid about adding stuff to that view. It's got to pass a really high bar, and things have got to be really useful to justify the expense of making the notepad feel like less of a calm place or less of a place that you want to spend time in.

That's tricky. It means that we bury features that are actually really useful. The templates feature, which lets you structure the notes in any way you want, is something a lot of users haven't even discovered. It's way too hidden, but it's hidden because most users shouldn't have to think about it, I think. It's for people who want to go deep and really optimize their workflow.

There's a lot more features like that where we're paying a price by making them small and tucked away, but I think it's worth it in the bigger picture to have a very calm, nice-feeling app. We're more lenient in other parts of the app. If you're looking in a folder or chatting with a lot of meetings, kind of like I was talking about earlier, I think you're usually in a different frame of mind.

When you're in a meeting, we can expect to have 2% of your attention, and the other 98% is on the person you're talking to. Whereas when you're chatting with Granola, I think we can have more like 80% of your attention, and therefore we can afford to throw more stuff at you. We're a bit faster and looser with the things that we try and the things that we put in there.

Yeah, yeah. I think, honestly, I would like us to be more experimental, especially in those areas of the app. We are on the side of keeping things very calm and zen, but sometimes at the price of getting good things out quickly.

One thing you mentioned at the top was viral hooks working—or I don't know if you used the word “viral” exactly—but features that are driving growth. You also mentioned that the most obvious one, having the bot join the call in a visible way, is not one that you're using.

What I have used is the Recipes feature, which I created the Blind Spot Finder for. My personal mission for my AI study in general is to have no major blind spots in the AI landscape—an increasingly impossible mission, but nevertheless, I try. I love the fact that it can go back and grab deep context and pull all that in, and then try to take the higher-level view.

As we discussed, this is something I can mention on my own, but obviously the vast majority of people can't. That does feel very consistent with helping me with the System 2 side of my life. I guess the 2 questions are: What are some of your favorite other recipes or other use cases that you've seen people create that are cool? And is that a big driver of peer-to-peer growth? If not, what are the other things that are really helping you propagate the product through users?

Recipes have been really interesting. A lot of use cases like the one you described have come out of the woodwork and weren't really things that we were anticipating when we built the thing.

The motivation for it was pretty simple. Power users of Granola have figured out that you can chat with the body of meetings and learn some pretty profound things or get it to do some very interesting things. We just wanted a way to make that repeatable and very easy to trigger, so we built Recipes, which are essentially prompts that you can run at the click of a button.

The use cases that have surprised me or seem interesting are the cases where it's hard to sit down and write something, but it's very easy to just get in a room with people and shoot the shit about it. With Granola's help, you can corral that messy transcript into something useful.

Our CX team, who are fielding bug reports and customer issues all day long, will pretty regularly do a meeting where they just bring up the main issues that people have talked about or the things people are getting confused by. After the meeting, one of them will hit the Recipe that converts that transcript into a bunch of suggested updates for our documentation, for example. It can take the transcript, go look at our documentation, figure out where the holes are, and then suggest a bunch of edits.

We do similar things with our job descriptions on the website. If we're looking to hire for a new role, it's often easier to just talk about it with the people involved in that role. Then we have enough examples on our website that you can usually point Granola at those examples, along with the transcripts of the conversations, and it'll do a pretty great first draft of a job description.

Those are, in terms of frequency of use, at least for us internally, the biggest ones and the most time-saving. The other one that really came to mind was personal coaching-type stuff, where Granola can look across the history of conversations you've had and pick out patterns about how you are as a person and how you could be better.

I've never worked on anything that I think has had such a strong emotional reaction as those things. When we were doing user interviews for the recipes feature, we'd use the “Coach Me, Matt” recipe, which is written by Matt Mochary, a famous CEO coach. We'd ask someone to get on a call with us, go to their recipes page, and click this recipe. Then we'd watch them react to the result of it.

I don't think anyone quite got moved to tears, but there were real, profound emotional reactions to this thing, which was incredibly validating and satisfying as a product builder. I think people get real, deep value from that. Granola really understands a surprising amount about you just by being with you in all the conversations, and I'm continually surprised by the depth of its understanding there.

That reminds me of another one that I thought was really cool, which was from Dan Shipper, who created—I forget exactly what he called it—but it was basically the implicit company culture recipe. It looks at calls across your business and tries to say, “What is the culture of this business in practice?” as opposed to what you may have put on your website or in your handbook or whatever.

I suspect that for a lot of leaders, that would be an incredible source of a reality check in some cases, and ideas and who knows what else.

One quick double-click on how you're using it: Are you guys an in-person company? When you talk about getting people together, are you putting a laptop on a table in a conference room and hitting record, with everybody in the same space along with the recording? Or are you—you’re nodding, I guess that is it.

Yeah, pretty much. We're 100% in person, which is ironic for a company where we built a thing that's designed to be used on video calls mostly. But now we have the mobile app, and the mobile app is the main thing we use in person.

Someone will put Granola—the phone—on the table, and then we talk about it for half an hour. You don't have to be super structured. People can just air their thoughts, debate things, and leave it up to the robots to figure out the structure and how to format that information.

I love that for a job description in particular. The idea that you could go to the team and just get random, unstructured thoughts, and then make sure that is really represented—I think that could take the level of job descriptions that most companies put out up quite significantly.

Our design and product team is growing at the moment, and I'm going through a process of trying to write down some of our design and product principles for everyone internally. For the next designer that joins, how do they ramp up quickly on how we think about product?

It's been super helpful for that because you want those principles to be written in the language that our team understands. I want them to feel like they're going to come from us as a collective. Just being able to get in the room and talk about them, and then as a group—but also 1-on-1 with each other—and amalgamate all that together has been super helpful.

You can get the AI to come up with pretty punchy principles that are worded in a more interesting, different way than me trying to capture the average of everything everyone was saying.

So are these recipes the thing that's driving the growth, or are there other viral product design principles you could share?

These do well on social media and in all public sharing because people create a recipe, and they want to show it off to the world and talk about it with people. That's been pretty good for us. Most of our virality is either just people recommending it to each other or people sharing notes with each other. We try to make sharing notes as quick and seamless as possible.

So often I'll be talking to a user and ask how they found out about Granola, and they'll say, “I was in this meeting, and then 30 seconds after the meeting these beautiful notes just popped up in Slack. I was like, ‘How did you do that? There's no way you could have written those in that amount of time, and how did they end up in Slack so quickly?’” Then they dig and find out that it's Granola, and they want to try it for themselves.

Those are honestly the main ones. As we've worked on building more team functionality into Granola, we're starting to unlock a benefit to having all of your team using Granola—not just each individual making themselves more productive. You can pull stuff together and use that shared context.

We have a bunch of teams now actively encouraging each other to use the thing, or procurement teams buying a license for everyone in the company so that everyone's on it. But most of it is pretty basic: People like the product, and they tell each other about it.

You only need 1 viral growth mechanism if it really works. That's one of the most profound lessons of growth in general. It usually doesn't come from that many different hooks. One hook really works, and then that drives it.

Okay, let's talk about design. You said your team is growing. It strikes me that there's a lot of good candidates, but I would say product design and product building, and the relationship between design and building, is a pretty good candidate for one of the jobs that has changed the most over the last year or so.

What does that look like for you? How big is the team? Do you still have traditional design, product manager, and separate engineering roles? How much have those blurred together? How helpful are AIs when it comes to going from an idea to a candidate design in your design system? How well do those things work for you?

What have you learned about actually making the AIs useful as a sort of designer assistant? In short, how has AI transformed your product creation practice at Granola?

It feels like a slowish change on the day-to-day, but if I compare what we're doing today to what we were doing last year, it's completely different.

As a company, we're 60 people now, I think. If I break that down, that's 25 to 30 engineers, 3 product people, 3 designers plus me, a couple of design engineers, and then everyone else who's not on the product, engineering, and design side.

As I've been hiring designers especially, I guess I'm closest to design and lead the hiring for that. I think it's a prerequisite, or at least a necessary thing, that you're curious and actively playing with Claude Code, or using AI to help you build stuff. I think that's important in some areas more than others.

Granola's core interfaces, like the notepad, are really hard to evaluate with Figma mocks. It's really hard to evaluate whether a thing is good by looking at a mock-up in Figma of the Granola notepad, because so much of what matters is how it feels with your real content in it, and how it feels ergonomically to have it open in a meeting and be glancing at it out of the side of your eye while you're also trying to talk to somebody.

There's no substitute for just building a prototype version of a feature in the real app and using it for real in the meeting. We really bias toward using AI coding tools to hack stuff together in the real app, and all of our designers are doing that at this point.

I think there are other parts where more traditional approaches—mocking up a flow in Figma and evaluating it that way—still make sense. The stuff around our paywall, like how you sign up to Granola, what's the sequence of screens we show you, and what information or ideas you need to understand as you do that, is just really useful to see in its entirety.

The design problems there are all around copywriting: Are we putting the right ideas in your head at the right moments? That's just a much easier thing to evaluate and move quickly on on a canvas where you're not having to put everything into the product.

It's a mixed bag, but the lines are really blurry these days. Designers are submitting code and building prototypes in code. Engineers are doing design as you would have thought of it a few years ago. It's a real hot spot, in a good way. I'm having more fun than I ever have as a designer-builder person.

Yeah, I'm right with you on that. It's unbelievably empowering and unbelievably fun. How would you say it has impacted—I don't know if you have metrics on this sort of thing, or you could just give me a finger-to-the-wind estimate—but what's the before and after when it comes to idea to ship, and whatever intermediate milestones you think are most important between those starting and ending points?

I think it's been immensely helpful in evaluating whether a thing is worth pursuing or worth building.

What’s an example?

The Granola notepad—the chat that floats at the bottom of the app—is basically everywhere in the app now, right? That wasn’t always the case. I think we introduced that in September last year, and before that it was only in some parts of the app, mostly in a sidebar view. We debated whether we should change the chat, make it bigger, make it more prominent, make it more globally accessible, and so on, for a long time. I’d been mocking up versions of it for a while in different places and different parts of the app.

The trigger point for thinking, “Oh yeah, this is obvious; we should do this,” was that I was able to prototype putting it in live code, moving from a sidebar chat to a floating chat in the app that we could all live with internally. Within a day of everybody having it internally, it was obvious that it was just way better and we should move to it. It really sped up the time from an idea to a thing that we could start using and feeling in the app for ourselves.

There are still lots of pieces of UI and lots of flows that need a lot of thinking through—all of the states, edge cases, and things like that. Some of the old ways are still very useful. Figma’s great for laying everything out and being able to see all the options and states. But yeah, the time from idea to evaluation is so much faster.

So the death of Figma is perhaps exaggerated in your mind?

I think they’ve got their work cut out. At least for me, Figma’s just become a more specialist tool. I use Figma now for ideating. Whereas Figma used to be the start, middle, and end of my design process, it’s now something I pick up and use every now and again.

I’ll often start by building the first thing that’s in my head in the product. I’ll get it working, but then I’m like, “Ah, this bit doesn’t feel good.” It’s faster to jump into Figma and try 10 different versions of it side by side, figure out which one feels good, and then jump back into code and implement that. Then you rinse and repeat until you have something feeling good overall.

So yeah, I think the days of having full app schematics of everything—all of the screens and all of the flows—laid out in Figma are totally gone for us. It’s way more of an ad hoc thing that you pick up and put down.

Okay, I’m not sure where that bottoms out for me in terms of the future of Figma, but yeah, I don’t know. If I’m Figma, it makes me a little nervous.

I’d be nervous too. The question is, can they hold on to that? I don’t think that need is going to go away. If they can cement themselves as the best place for that kind of work—for ideating—then great. But other people are going to come at it. I presume Claude Code is going to run at it from that direction, and other people are going to come at it, too.

Yeah, there are a lot of candidates trying to be the everything app these days, so it’s going to be very interesting to watch those dynamics.

In terms of the team dynamic that you have, I was sort of guessing coming in that it would be a challenge to manage product discipline and also to manage people’s feelings about their product ideas, because the ratio of random ideas that people have and vibe-coded things that actually get launched has got to be—I mean, correct me if I’m wrong—but it feels like it’s got to be 100 to 1.

Which, in a sense, is maybe good. I can certainly see the argument that’s what users ultimately benefit from and deserve. From the individual engineer’s standpoint, or the individual person who came up with the idea’s standpoint, I could also imagine it being frustrating.

You also said that when something really hits, if you can get it into the internal version of the app quickly, it can become obvious whether it’s working or not. What would create frustration in a lot of cases is, “I have this idea, and we’re not even trying it,” whereas if I had this idea and we tried it and nobody really cared, then that’s at least closure.

So how is the team dynamic there? The other question you’ve got to keep in mind, too, is: How do I make sure people keep actually trying? If their ideas are only getting through to product at less than 1%, how do I avoid people getting discouraged and feeling, “Why even bother? It’s probably not going to work”?

I see a bunch of competing challenges there. I’m wondering how you’re dealing with that from a team culture and management perspective.

Yeah, it’s definitely a thing. I think, first, we’re very mindful that Granola, as a company, is a company of people who like to build great product experiences. We’re not an exceptionally technically deep company, and we’re not exceptionally sales-driven. Building good experiences is the thing that we like to focus on.

We look for people who feel like they fit that mold when we’re hiring. Humility and open-mindedness are 2 huge characteristics that we really look for in people who join. You should be curious, think freely, and come up with good ideas, but also have the humility to assume that 9 times out of 10, your idea is not going to work when it hits the ground and is put in front of real people.

That’s not, I think, because Chris or I say it won’t work, but because it just doesn’t land with the end users. So we try to get the right people in the door—people who think and feel like us and approach building software like us.

Then I think the next thing is that, if you have smart people, they’ll make good decisions a lot of the time if they have good information about what’s happening: what’s the state of the product and the thing they’re working on. Every engineer is involved in talking to users, as much as anyone in product or design is. There’s no waterfall effect or anything going on.

A lot of the time, that leads to engineers being the ones who have the ideas that end up being the right thing to put into production and solve the user’s problem. So we try to give people good information and get them close to the users.

We try to encourage this nature all the time: everyone should, if they have an idea, try it and put it out in the company to see what people think. We do demos every Friday, which is one of the highlights of my week. Sometimes it’s stuff that’s on the roadmap and people are working toward, but sometimes it’s a completely left-field idea: What if we just got rid of the Granola sidebar and had it be the one interface? What if transcription worked in this relatively different way?

People are trying stuff like that all the time, and we try to cultivate the idea that the trying is good. It’s okay to build a thing, see if it works, show everybody so they can learn from it, and then put it to rest. You take what you learned from that and move on.

I try to exhibit those qualities too. If I have an idea about how the app should be, I’ll try to make time to flesh it out and share it on Slack. Usually it doesn’t go anywhere. Usually my ideas are terrible too, and that’s okay. Hopefully, collectively, we all inspire each other and move our thinking forward, and that ends up putting us in a good place.

As we’re talking, I just went back to the Labs tab in Granola and joined the beta. I wonder what you could tell me about what I should expect as a beta user. This seems like something that might—especially if you have any real scale, if you can get to the point where you’ve got some critical mass of people who want to be beta users—really grease a lot of the friction away in terms of everything we’ve just been talking about.

How do you get real responses? How do people feel like their ideas got a fair shot? How are you using the beta program?

Yeah. Not enough, honestly. It’s probably a bit disappointing, but I think we have 10,000-ish people on it. We make product decisions almost exclusively qualitatively. We do some measurement, especially in the growth work—we’ll measure things and A/B test—but a lot of the core product stuff is decided purely based on gut feel and observing users using the thing.

All of those decisions about what we’re building, and whether something is a core feature, tend to happen either from us using it and talking about it internally or from us working with very specific people. When we were pre-launch, we deliberately didn’t try to go out and get users. We just iterated and iterated with a handful of people and tried to be as close to them as we could, observing them using it in the wild.

The high-fidelity feedback you get from being really close to someone outweighs the quantity of talking with a lot of people really quickly. We still try to follow that mandate today, so for any feature—most features—we’re working very directly with a small number of people to iterate on.

By the time things go to beta, they’re usually pretty well baked already. It’s bug-catching, stability testing, and just sense-checking that we didn’t screw up some obvious thing.

Yeah. That’s interesting. I do wonder if we’re soon going to get to the point where AIs will be able to make enough sense of usage logs that you could potentially accelerate that process, and potentially even raise the quality of the decisions you could make by launching a ton of stuff to a small number of users and seeing what happens. Then you get a real ground-truth measurement there, right?

I think everything you’re saying there sounds enlightened, in the sense that I’ve encountered this many times with successful product builders: conceptually, what you need to do isn’t really that complicated, but it’s still something a lot of people don’t want to do, don’t find intuitive to do, or don’t have the disposition to do. Being really focused on who the users are and what they want, listening to them, and spending a lot of time with them—those things just come up over and over again.

And can AI do it? Maybe soon. I don’t know. Maybe. It’ll be interesting to see if we can cross that threshold in the not-too-distant future. Any thoughts on that? Are you holding your breath for it, or maybe dreading that day if it comes?

Definitely. I’d rather it be AI that takes my job.

But I don’t know. If humans are still the ones making the decisions, I feel like they’re going to want pretty raw input to feel good about making those decisions. Who knows? That might be very outdated thinking very quickly, but that’s where I’m at today.

I could see that for features where usage is really disparate and people use them for many different things—chat, for example, like OpenAI ChatGPT. I think that’s one where you go to beta earlier because you learn from having a volume of people using it in different ways, and you learn what the patterns are and stuff like that. I could see that feeling like an area where, if an AI understood the themes of what people are asking and could therefore bias the interface toward being good at those things, that would be interesting.

What scares you the most in terms of Granola’s future? I’ll give you one candidate: my friend Andrew Critch coined the term “the big tech singularity,” which in his mind is this future state where, because a few companies have such powerful AIs, they can turn their focus to any particular niche or even industry. He’s thinking about pharma and materials science; he’s thinking at the macro scale, but it applies to big and small. If they have such a dominant AI advantage, they can potentially turn their focus to any particular area, steal what you’ve learned, clone what you’ve built, and even potentially offer it at subsidized prices or whatever.

This is not a Granola-specific risk, but I do worry about that a lot myself. Do you worry about that, and what else keeps you up at night as you think about Granola’s future?

That’s the main one. I feel like I’ve always worried about this since day 1. The moment ChatGPT came out, you could plot some hand-wavy line into the future where just this one tool does everything and no startup or specialized service ever needs to exist again.

It’s a depressing version of the future. It feels like a version of the future that could pan out, but I certainly hope it’s not, and I don’t have great answers as to why. I do what I do because I enjoy it, and even if we are marching toward the tech singularity, I’d be much happier building Granola in the meantime until that singularity.

I also think that, especially in tech, we love to assume that the next big thing that comes along is going to swallow everything and take over. I’m really feeling this about Alexa. I think Facebook Messenger had a chatbot in 2013, or back in the day, and I remember thinking, “Damn, interfaces are cooked. We’re just going to be chatting with these bots back and forth.” Maybe that technology was too early and it really is coming through now, but I don’t know.

I feel like we over-index on one solution being the be-all and end-all, and in reality, life is messy and complicated. There’s still a lot of merit in having specialized tools for different things.

I think all we can do at Granola is be really good at the stuff we’re really good at, and then architect the products and everything in a way where we get to stand on the shoulders of the giants building the big models. If Granola doesn’t get better when the next version of Claude or GPT comes out, then over time we’re cooked. We have to go with the rising tide, be just a little bit better than them in our particular area, and trust that people will pay for that, which I think back-to-back meetings are painful enough for enough people that they will pay for that.

That, plus maybe a little bit more vigorous antitrust enforcement, and you’ll have a place in the future. How about your general positive vision for the AI future? One of my common refrains is that the scarcest resource is a positive vision for the future, so I’d love to hear yours.

When you sit down and study somebody’s day—their work life as a laptop-and-email knowledge worker—so much of it is you being a slave to your computer. You’re reduced to a machine that needs to move the mouse around, click buttons, and move information from one place to the next.

I think we’re going to a world where we’re going to have help with so much of that. So much of that menial, mindless work is going to be taken care of, or we’re all just going to have help with it. I think that sounds like it could move work toward being a much more interesting place for a lot of people.

In meetings, the number-one piece of positive feedback we get about Granola is, “It helps me feel more present in the meeting and more engaged. I’m able to have my brain firing on all cylinders because I’m not caught up frantically trying to write down everything that I need to remember.” I feel really proud to have created that for some people, and I think that analogy playing out across a bunch of other parts of our work life is quite an exciting future.

I just asked Granola how I should bring this conversation to a close, and it said to thank you for the specifics. I do think that’s a great suggestion. You’ve definitely shared a lot of really interesting details.

The second point was to call back to the positive vision, and on that point I’m definitely with you: if we can be less like slaves to our computers. I’m trying to measure myself by whether I’m getting outside more this year, and if I’m not, is AI really serving me? I wouldn’t say I’ve moved the needle on that yet, but I do love the vision of untethering ourselves from our computers.

Thank you. This has been an excellent conversation. I really appreciate it, and it’s been a great window into the thinking behind how to make a viral-hit AI product that everyone can use and enjoy. Sam Stephenson, co-founder and designer at Granola. Thank you for being part of The Cognitive Revolution.

Thanks so much, Nathan.