AI 产品打造的灵魂：用户洞察、迭代循环与价值共鸣
EO
2026-01-14
用户反馈：产品成功的生命线与迭代循环
构建成功产品的核心在于与用户建立深刻的连接，并将其视为产品开发的生命线。正如 Granola 的联合创始人兼 CEO Chris Pedrick 所强调的，“与用户交流是产品生命力的源泉。” 这不仅仅是收集意见，而是建立一个持续的反馈闭环，为产品开发的每一个阶段提供指引。一个常见的误区是，内部团队认为自己创造了绝佳的产品，但当它真正面向用户时，却发现用户难以理解或无法有效使用。产品设计师的用户测试视频生动地展示了这一点：用户可能无法掌握基本操作，即使产品设计初衷是简单易用。
这种反馈循环的速度至关重要。如果收集反馈耗时过长，最初的决策背景和思考过程就会被遗忘，从而削弱了反馈的价值。这凸显了快速迭代的重要性。Pedrick 提出了“探索（explore）与利用（exploit）”的理念。在 Granola 公开上线前的一年“探索”期内，团队拥有极大的自由度来大幅度地改变产品，添加或移除功能，而无需担心引起现有用户的强烈不满。这段时间让他们得以发现真正重要且有用的东西，甚至砍掉了约 50% 的初始开发成果——这是产品上线并积累用户后几乎不可能做到的壮举。这种从最小可行性产品（MVP）开始，根据用户互动不断打磨的迭代方法，是优化产品形态的关键。
识别产品市场契合度（Product-Market Fit，指产品在多大程度上满足了强烈的市场需求）是另一项重大挑战。Pedrick 坦承，Granola 在上线第一天就具备了产品市场契合度，但他们花了六个月才意识到这一点。将此比作探索电子游戏新关卡，地图在开始时是模糊的，只有当你实际移动时才会逐渐清晰，这恰当地描述了最优解决方案往往需要与现实世界互动后才能显现。你无法孤立地设计出完美的产品；必须主动探索系统并观察其反应。正是通过将想法置于用户面前并快速获取反馈，才能建立直觉，避免构建出“错误形状”的解决方案。
产品灵魂：一致性、价值观与人本设计
除了功能性的迭代，一款卓越的产品还应具备独特的“灵魂”。Pedrick 所说的“灵魂”象征着产品的连贯性、一致性以及源自设计和交互的统一价值观。当一个产品拥有灵魂时，它会让人感觉是出自一个单一、有意识的源头，如同与一个熟悉的人互动。这与那些设计中暴露了其底层组织结构的产品形成鲜明对比——这是缺乏统一愿景的明显迹象。将产品比作“最好的朋友”，其行为模式可预测，因为你理解其价值观，这恰恰说明了这一点。我们为他人构建心智模型；同样，一个拥有灵魂的产品能提供一致的体验，而非因不同团队孤立工作而产生的、令人不适的界面或行为转变。
人机交互（Human-Computer Interaction, HCI）领域是实现这一目标的基础。HCI 探索人们如何使用技术以及如何为人们设计技术。它认识到，即使是像密码学这样高度技术化的领域，也容易受到人为错误和设计缺陷的影响。这种理解对于构建出色的产品至关重要，因为它要求深入理解用户在互动瞬间的语境和心态。Pedrick 的个人经历，从对 Google 崛起的着迷，到学习计算机科学，再到深入 HCI，清晰地展现了他对技术中“人”的要素的关注。
Granola 本身就体现了这种理念，它旨在增强而非取代人类的能力。虽然 AI 可以自动化任务，但 Pedrick 认为最有价值的产品是那些能提升人类现有能力的产品。Granola 作为一款 AI 笔记助手，能够记录会议内容并将其转化为精炼的摘要。其未来的发展方向将包括协助用户处理会后工作，如撰写跟进邮件、起草备忘录、准备过往会议内容、进行跨会议分析等，从而切实地改善用户的生活。这种方法优先考虑赋能用户并优化其工作流程，而非试图使人类变得多余。
用户反馈的精妙之处：探询、量化与直觉培养
尽管用户互动至关重要，但互动的性质及其反馈的解读方式同样关键。Pedrick 告诫不要仅仅询问用户想要什么，然后直接照做。用户表达的往往是他们“认为”自己想要的，这可能与他们实际的需求不同，而且他们的反馈可能自相矛盾。一种关键策略是从“负面视角”去探询用户——提出质疑性的问题，如“这是真的吗？”或“你不觉得你会感到疲倦吗？”。这种方法虽然反直觉，但有助于揭示更深层次的真相，更快地触及现实，因为人们在访谈中自然倾向于给出礼貌或赞同的回答。
为了避免自我欺骗，尤其是在大型组织中，Pedrick 提倡使用保守的参与度指标。在 Granola，一个“用户”的定义非常严格：必须是在给定日期内完成至少一次新会议，且会议转录时长超过 5 分钟。这种严谨的定义防止公司“自欺欺人”。诸如“这是因为 X 原因”或“产品已经足够好了”之类的借口，会被这些保守的指标所抵消。这种纪律确保团队保持务实，并批判性地评估产品是否真正有价值且被使用。
归根结底，对用户和产品方向的直觉并非固定不变，而是通过持续、快速的反馈循环磨练出来的技能。Pedrick 警告说，初期的成功可能导致自满情绪的产生；如果停止与用户的互动，对用户的理解能力可能会逐渐减弱。能够可视化用户反应的能力（Granola 通过将数百名用户“铭记于心”来实现）是这种持续参与的直接结果。挑战在于判断何时应从“探索”阶段转向“利用”阶段进行打磨。这个决策点——是继续寻找新的产品形态，还是优化当前形态——本质上是困难的，它依赖于通过持续、批判性地与用户和市场互动而获得的宝贵直觉。
Original English
We had product market fit and we had it on day one of launch. I think the first lesson is like talking to users is the lifeblood of the built-in product. This happens all the time. You're building something, you're like, "This is great." And then you put it in front of users and then they don't understand it. For example, there's this amazing video on YouTube, a product designer doing a user test and you see the user grab the square and put it into the square hole. The designer's like, "Yes." And then you see the user grab the circle and put it in the square hole and the user's like, "What?" And then you just see like basically completely misunderstanding the product in front of them. If it takes a month to to get feedback on it, it almost not worth doing because the thinking you had when you made the original decisions, you don't even remember. So I think the short cycle there is super important. My whole philosophy is that there's a explore and exploit. I think a huge advantage for us when we started building Granola is that we didn't launch it for a year. And what that meant is that during that year as we were exploring things and trying new things, we had a lot more freedom to change the product drastically. I'd say for the first 9 months, 10 months, we were mostly adding things, adding new features, trying to improve them, adding new like screens, what have you. And then at one point, we kind of realized, okay, here's the thing that's going to be most important, most useful to users. And we went and we cut about 50% of what we had built. That would have been really hard to do if we had been launched and we had lots of users. Like, it'd be very hard for us today in one fell swoop cut half of the product. I think our users would really yell at us. That's a big part of the the way we build. So for any product that you're building, first you have to go through this explore phase where you're figuring out what's the shape of the solution. And there you want to try as many different things as possible. And once you kind of know what the shape is, then you go into a different mode. We call it exploit internally where you just polish, right? You take the rough shape and you polish, polish, polish, polish. And here's where the details matter. But you need to make sure you're polishing the right shape because if you're polishing the wrong shape, then all of that is throwing. The question is kind of like do we hit something that's valuable and now it's time to polish or do we should we still be looking for a new shape, right? The answer is like it is really hard to know if you have the right shape of a product. It's really hard. When we launched Granola, I didn't think we had it at that point. I was like, I think this is good enough where we'll learn more by giving it to more people. That's why we decided to launch when we did cuz we said like, are we going to learn faster by continuing to do this? are going to learn faster by launching it and getting feedback from lots of users. And up until that point, it was really clear to me that we would learn faster by just onboarding two, three people every day and getting feedback. And at some point once we started doing that and we started hearing the same things over and over and we kind of understood those users, we said, "Okay, now let's give it to lots of people because maybe there are people who want to use it for use case we've never thought of." And the fact is we had product market fit on day one and we didn't realize it. And one of my biggest mistakes was not noticing it. It took me six months to realize that we had product market fit and we had it on day one of launch. The first lesson is like it is really hard to know when you have it. I heard the story that the Facebook team they had this other idea which is kind of like Dropbox for music some kind of file sharing thing and they worked on it I think for the first 6 months or 9 months after they launched Facebook because they were like oh I don't know if there's a there there you know we might want to work on this other thing more and that's Facebook right that's like the generational company of the decade and they still didn't know necessarily if they were on to something huge so what I got wrong I think a lot of early founders get wrong a lot of people will sit down and say I'm going to build a product here's the painoint I'm going to solve. I want to build a great solution and it's all about can I execute on that. Have you ever played those video games where you land on a new level and there's like a little map in the corner and it's all gray and then you need to kind of go and walk around and then the map kind of unblur. But when you start off basically you have no idea of what the terrain around you looks like. I think that's the right metaphor. The right solution is unknowable until you go out and you try it and it gets contact with the world. You can't sit and design the perfect thing. You need to like put stuff out there, probe the system, and see how the system probes back. I very much believe that talking to users is the lifeblood of building product. I think if you're not constantly talking to users, not constantly getting feedback, you're just not going to build something really good. You need to systematize your ability to talk to users. If the activation energy for you to go and talk to your user is high, then you're just not going to do it very often. And if you can lower that activation energy necessary to go talk to a user, and if you can do that for your whole company, great things are going to happen. So this was 2013. I started edtech company, an AI tutor for high school kids called Socratic in New York City. And I uh I ran that for 5 years. And then Google acquired that company. It was really hard for us to actually go and talk to high school students. I remember we'd know that there were a few colleges and a few high schools around our office in New York and I would sometimes go after school and be like, "Hey, do you want to answer some questions?" And it felt super creepy. Eventually, it took us a while to get there, but we figured out this system where on every Tuesday and Thursday, we would have I think it was like five to eight high school students come into the Socratic office and spend the afternoon. We didn't have anything to talk to them about. that's fine. They would just sit there, do their homework, and leave, and they would get paid for it, and they were super happy. But if we were working on a new feature or if we were working on messaging or whatever it was, they would be there, and we could show them whatever we were doing. And the moment we had that, our ability to improve our product and make it better sped up dramatically. A big difference at Granola versus Socratic is that um we can talk to users remotely, like over Zoom. And that actually makes a lot of sense because our product's meant to be used during meetings, right? So we'll do a lot of video calls with with users. So we we usually have standing user interviews 4 days a week that anybody at the company can join and whoever is working on stuff can ask for information. So that's something that I've taken away from the Socratic experience and have kind of carried with me since. The second thing is in my opinion like the secret with user interviews is you don't need to hear the same thing from 10 people. If I put a prototype in front of you and you say this button's super confusing and I look at it and I'm like oh I totally understand why you're confused. I don't need 10 other people to tell me that. I should go and I should change that button immediately so that next time I show it to somebody I learn what the next problem is. And I think this is something that especially in big companies that's unheard of. It's very easy to delude yourself. Be very very skeptical and critical and honest about if what you've built is actually something people want and they're actually going to use. So like in a user interview, never ever ask someone if they would use something. Or you can ask it but then completely ignore the answer. If you're putting them in front of a prototype, ask them like what would you do next? And then if they say something, say, "Is that true?" Or like, "Don't you think you'd be tired?" Or, you know, like really probe on it from a negative perspective because that'll I think get you to the reality faster. That's just human nature. In a user interview, you're going to try to say nice things. So I categorically ignore all positive things that people say and use really conservative metrics of engagement. Internally, when we say a user, it's only a user who's done at least one meeting, new meeting on this day, and that meeting has to have over 5 minutes of transcription. Otherwise, we don't count you as a user. So, if you use Granola yesterday, we don't count you as a user today. If you open up Granola and looked at 10 meetings, but you didn't do a new meeting, we don't count you as a user. And we basically from the get-go, we've always had very conservative metrics for what's activity, so that we kind of we don't kid ourselves. It's so so easy to come up with excuses or say like, "Oh, you know, it's actually because of this other thing that we're going to fix. It'll be fine. Like, the product's actually good enough." What I don't believe is that you should talk to users and then just do whatever they ask you to do. Because users are going to say a whole lot of things and sometimes they'll contradict. Sometimes what users think they want and what they actually want or what they actually need are different. So, my philosophy is to talk to users so you can really get their context. you can hold that in your brain, but then use your intuition and your vision of what the product should do. So, from the get- go, I think we've always known that we wanted Granola to be a very simple, minimal design product where it feels nice to spend time in. It's not distracting. It's not vying for your attention. That's been rooted on what we wanted in a product, right? Cuz we use Granola and we've always wanted to use Granola. But as we try to build that out, we have hundreds and hundreds of users kind of in our heads that we can kind of close our eyes and be like, "Oh, what would Nancy think of this?" We can kind of visualize the response pretty well. And I think that's super important. I think if you just make a prioritized list of user needs and build those, that doesn't work very well. Like whenever we've done that, users never ended up using those features very much. Like this happens all the time where you're building something, you're like, "This is great." And then you put it in front of users and then they don't understand it, they hate it, they don't get it. There's this amazing video on YouTube, a product designer doing a user test, and you see the user grab the square and put it into the square hole. The designer's like, "Yes." And then you see the user grab the circle and put it in the square hole, and the user's like, "What?" And then you just see like basically completely misunderstanding the product in front of them. I think the only way you can build an intuition is by putting stuff in front of people and getting feedback on it quickly. If it takes a month to to get feedback on it, it almost not worth doing because the thinking you had when you made the original decisions, you don't even remember. So I think the short cycle there is super important. When we started building Granola, we took a very very iterative approach. Like we built the bare minimum thing and then we tried to get people to use it and see all the reasons why it didn't work and then we try to fix those and then we try to change it. And I think your intuitions do get better but you can never stop doing it. That's the other It's like their intuitions get better and then you stop talking to users and your confidence level still stays high. So you're like, "Oh, I understand users. I know what I can what what I need to build." And then when you start user testing again, you realize you're totally off pieced. And I think two different paths you can take when you're building products on top of AI. You can build a product that will basically replace the human or you can try to build a product that's going to augment or enhance what the human does.