Episode 266: Building for builders
What does it take to keep product teams focused on meaningful work? In this compilation episode, Melissa Perri brings together three product leaders to explore how to cut through overhead, dig into real problems, and resist the pull of shiny technology.
Nan Yu, Head of Product at Linear, shares how clunky tools burden PMs with admin work and how his team uncovers real problems behind feature requests. Andrew Davidson, SVP of Product at MongoDB, explains what makes developers a uniquely demanding audience to build for.
Jody Bailey, CPTO at Stack Overflow, reflects on what went wrong when companies rushed to ship AI without solving real user problems. Together, these leaders show that great product work starts with understanding real people in real moments.
You'll hear us talk about:
Reducing PM administrative overhead
Nan Yu explains how poorly designed tools push admin work onto PMs. When engineering tools are too clunky, developers disengage and PMs end up doing data entry instead of talking to customers. Speed and directness in tooling keep teams focused on real value.
Uncovering real problems behind feature requests
Nan shares Linear's approach: anchor every request in a specific moment. His team asks customers when they last felt the need for a feature and what actually happened. This often reveals that the real problem differs from the original ask.
Staying problem-focused in the rush to adopt AI
Jody Bailey describes the rush companies felt when generative AI emerged and the mistake of shipping AI solutions before identifying real problems. He shares how Stack Overflow is refocusing on core strengths and expanding who it serves.
Episode resources:
Try Granola today: http://granola.ai/productinstitute
(Use the code PRODUCTINSTITUTE to get 3 months free)
Check our courses: https://productinstitute.com/
Episode 233: How Linear Builds Tools Developers Actually Want with Nan Yu
https://www.produxlabs.com/product-thinking-blog/episode-233-linear-ai-nan-yu
Episode 209: From Databases to Developer Platforms: The MongoDB Story with Andrew Davidson
https://www.produxlabs.com/product-thinking-blog/episode-209-andrew-davidson-databases-platforms
Episode 239: Navigating the AI Shift at Stack Overflow with Jody Bailey
https://www.produxlabs.com/product-thinking-blog/episode-239-stack-overflow-ai
Jody Bailey on LinkedIn:
https://www.linkedin.com/in/jodybailey/
Nan Yu on LinkedIn:
https://www.linkedin.com/in/thenanyu/
Andrew Davidson on LinkedIn:
https://www.linkedin.com/in/andrewad/
Follow/Subscribe Now:
Facebook | Instagram | LinkedIn
Episode Transcript:
[00:00:00] Melissa Perri: [00:00:00] Creating great products isn't just about features or roadmaps, it's about how organizations think, decide and operate around products. Product thinking explores the systems, leadership and culture behind successful product organizations.
We're bringing together insights from multiple product leaders, pulled from past conversations to explore one shared topic, offering different perspectives and lessons from real world experience.
I'm Melissa Perri, and you're listening to the Product Thinking Podcast, by Product Institute.
Today we're looking at what it takes to keep product teams focused on meaningful work. Cutting through administrative overhead, getting to the root of real customer problems, and resisting the pull of shiny new technology.
We'll start with Nan Yu, the head of product at Linear, who shares how too much process and clunky tooling can pull product managers away from the work that actually creates value and why speed and directness matter more than we think. He also explains how great teams go [00:01:00] beyond feature requests. Digging into real moments and real problems to uncover what actually needs to be solved.
After that, we'll hear from Andrew Davidson, SVP of Product at MongoDB on what makes developers such a unique and demanding customer, and why building for them requires both power and simplicity.
We'll wrap with Jody Bailey, chief Product and Technology Officer at Stack Overflow, who reflects on what happened when companies rushed into AI and why focusing on the technology instead of the problem led many teams in the wrong direction. Let's start with Nan.
[00:01:33] Cutting PM admin work
---
[00:01:33] Nan Yu: Speed is everything from I engage with CTA I click on a button, or something like that, and it should just respond immediately. Just, not have to wait a few hundred milliseconds, it should just respond. But also it's about getting to your goal faster so you don't have to traverse a whole bunch of screens or do stuff like, really indirectly. We really focus on directness so that even things like look, projects are called projects, they're self-explanatory what they are. We really encourage in the app to [00:02:00] write like tasks in a way that just says what needs to be done, as opposed to doing like a roundabout, indirect sort of user story and obliquely describing what's going on.
So I think a lot of this stuff is designed to get you to your goal faster because the real, the real value, right? That, that people, bring to the table when they're working in software development, is actually making the software or making the designs or, talking to customers or whatever it happens to be.
That's the real value. Your delivery. You're not, here for data entry. You're not here to do administrative work or anything like that. Like we're trying to get that off of your plate.
[00:02:30] Melissa Perri: What types of things are you putting in to, to help get people away from that stigma of we're just here to write stuff into this project tool and actually concentrate on the work?
[00:02:39] Nan Yu: I think a lot of times, PMs get saddled. With a lot of this work frankly, because the tools that are given to engineers are just too clunky for them to engage with. And if you talk to an engineer, like in, in a realistic setting, right? If you talk to an engineer and they say I spent all my time in cursor or VS code or whatever it is. I just didn't touch Jira, but then I shipped a bunch of code, [00:03:00] they're gonna get a great performance review. Their incentives are to like ship working code that customers are using. And so all the wrangling and stuff like that ends up falling right on PMs by default. No one
[00:03:09] Melissa Perri: Mm-hmm.
[00:03:10] Nan Yu: signed up for this job in order to like input a bunch of data into a issue tracker, right?
That is not, no one dreams of that, right? We we wanna be, talking to customers, understanding their needs, like kind of empathizing with them and all that kind of stuff. That's why we're doing this job. Because it's what we're good at and this is what we're here for. All that administrative stuff, just comes to us by default. So I think when people complain that PMs are just like, wrangling issues and doing data entry, it's because of that dynamic that the tools themselves are too clunky for the engineers to want to use or engage with. So they just disavow 'em all together and then it falls on us to, to have to fill in those blanks.
[00:03:43] Digging into real problems behind feature requests
---
[00:03:43] Melissa Perri: I feel like a lot of new product managers make this mistake. They listen to exactly like what people want, right? And then they'll say, oh, it would be great if it could just do X, Y, and Z and I want you to build me this thing, rather than going, why? What's behind there? How do we actually uncover those motivations. So what do you do [00:04:00] to get your product managers into the mindset as well of, teams that might work differently outside of Linear the company and see how that they're, how they're doing product development too.
[00:04:10] Nan Yu: I think one of the things that we talk about internally a lot is we have to solve real problems for real people. And a real problem is not that someone has in the abstract. It's not like a class of problems, it's an actual specific instance of a problem.
So when someone comes to us saying " Hey we'd love it if you have feature X". We'll dig in and we'll say okay tell me about the last moment in time where you really felt like the need for feature X. Was it last Tuesday? Was it this morning? Like, when was it? It's okay, like what was the situation like? Tell me about what actually happened in reality in that moment. Often you discover all sorts of interesting stuff, right? Usually they learn a lot more about their problem in those moments as much as you do, because they like didn't think of it.
They thought, ah if I had feature X, which just solve my problem, they move on, right? But then they go oh yeah, maybe I shouldn't, maybe I shouldn't even be [00:05:00] doing this at all. It's like one, one question. Is this really worth it? Yeah. Or they unpack their problem. They understand their problem to be like more specific. So I'll give you a, like a very specific example here, right? Which is a lot of times people say like well you know I really want to like notify my my um know my marketing stakeholders when like dates change. And that's good, right?
We want people to be kept up to date about that. But if you dig into that further what that really is the dates were never certain to begin with, so they're just gonna be wobbling all over the place. So if you just take that at face value. And they use it exactly as they hope will happen, as the dates will just jump back and forth. All the place, people are gonna get spammed with notifications and they're gonna stop paying attention. That's not the, that's, that might be a useful feature, but that doesn't actually solve their problem.
Their problem was they had to be overly specific when they were defining their dates in their system. Like the, the system has like date and then you have to be like, oh yeah, it's January 1st, but you didn't you don't think it's January 1st. Like we're all, we've all been in, in those shoes before.
We're a pm. We're like, look, it's gonna ship in the first [00:06:00] quarter, maybe? I'm gonna try to ship it in January, so what date do I put? And then you put something in there, then everyone takes it like very literally, and all of a sudden you're like getting held accountable to that date, but you didn't mean it in the first place, right?
So that's the real problem. The problem was not notification. So the feature we ended up building was letting you specify dates at different levels of granularity. You can say first quarter, you can say January. You can say January 1st, like whatever. Whatever you actually know, you can specify at that level of of certainty. And then all of a sudden you're not changing the dates a million times and people are actually getting communicated the right information. You're not like, you don't feel like you're lying to people every single time you write a date.
[00:06:35] Melissa Perri: What Nan showed is a core product skill. Don't just take requests at face value anchor in real moments, real constraints and what actually happened. Because when you do that, you often realize the solution people asked for isn't the one they actually need. But even when you deeply understand the problem, the type of customer you're building for changes, how you approach the product entirely.
Next we'll hear from Andrew [00:07:00] Davidson, SVP of products at MongoDB on what makes developers such a unique and demanding customer, and why building for them requires both power and simplicity.
[00:07:10] Developers expect power And simplicity
---
[00:07:10] Melissa Perri: Tell me about what's different or what's similar when it comes to doing product management and thinking about your customers, your user experience, in a technical product like this versus something that might be more, what an everyday consumer would use.
[00:07:26] Andrew Davidson: When we think about developers, for example, as a customer and thinking about product management for them. It is quite different, I would say, than like a typical consumer use case, in that you're dealing with Developers are a really unique persona. They're extremely sophisticated on the one hand.
There's a sort of they are people who have figured out how to make things work. In a way, a developer, if you filter they are people who, if you filter through, they are people who will jump through hoops, figure out puzzles, move mountains to figure out how to get something done. [00:08:00] Because anyone who's tried to write code knows you just constantly run into issues and you have to get overcome them. So they're like people who love overcoming issues.
So on the one hand that sounds amazing You could think to yourself they therefore don't care about experience because they'll just get over whatever experience I'd give them. But on the flip side, they're the, some of the most sort of love, hate, fickle. If they feel like you're wasting their time or they're not treating them with respect, or you're not empowering them to really fly.
They could be completely the opposite and be like, get out of here. I don't want to use this at all. So it's this unique tension. You want to empower them to feel the full power and then they'll run with it. And you can expect them to become an expert. You can expect a lot from them. But at the same time, it needs to just fly and it needs to be able to be something they could run locally.
And it needs to be able to be something that they can easily weave into their CICD pipelines and run with infrastructure as code at scale and, all of the many things that you just have to think about when you're in this type of product.
[00:08:53] Melissa Perri: Yeah, I, my experiences with developers are, they will definitely try to solve problems, but they will not be quiet [00:09:00] about it if it's like frustrating. And I find they actually appreciate probably, you know, user experience and their tools more than anybody, right? They're, they're in them 24/7. like, we may open an app for banking once a day and be annoyed by it, but like, they're literally using those tools 24/7.
So if you think about, what other people use, I know, like, you know, salespeople are in Salesforce all the time. That is like what we're talking about when we're talking about platforms, APIs, like all these components, databases and stuff to developers. It's like their Salesforce, what they use every day.
And if you're mad at Salesforce, imagine what they're like, if they can't get those components and start to build things. So I think that's a great parallel.
Andrew showed how demanding developers can be as users. They'll figure things out, but they have very little patience for tools that waste their time or don't work the way they expect. So you have to balance giving them power with making things feel simple and fast. But when teams start focusing more on the technology than the actual problem, that's where things can go wrong.
[00:10:00] Finally we'll hear from Jody Bailey, chief Product and Technology Officer at Stack Overflow on what happened when companies rushed to adopt AI and why focusing on the technology instead of the problem led many teams astray.
[00:10:12] Melissa: I don't recommend tools unless I actually use them. So when I tell you, granola has become a daily essential for me and most of my team, that means something.
We're all in a lot of meetings. Granola is an AI notepad that quietly enhances your notes in the background. No bots joining your call. No awkward recordings. Just cleaner thinking after every meeting. It's the rare tool that gives you time back instead of asking for more of it. You can try it yourself with three months free on any paid plan at granola.ai/productinstitute.
[00:10:42] Chasing AI instead of solving problems
---
[00:10:42] Melissa Perri: When generative AI first came out and you saw people turning to Claude and to chat GPT to ask their questions, was there ever like a oh crap moment? Like, what are we gonna do? How do we think about positioning ourselves here? Mm-hmm.
[00:10:56] Jody Bailey: I'd be lying if I said no. I think many [00:11:00] people in many different industries had that, oh, crap moment. And I think you saw a lot of people and businesses, you think SaaS, you think other community sites, had this oh, crap moment. It's oh, we've gotta release something, we've gotta have an AI solution. And you saw this proliferation of AI tools. And, talking with other CTOs, CIOs, et cetera. One of the mistakes I think almost everybody made, which is so fundamental, is we focused on delivering AI solutions. Not solving user problems or customer problems.
We were solving for, we have to have AI. And I think a lot of different companies did that and we had an experiment with that and some good things came from it. But we also spent a lot of time doing things that really didn't bear fruit. And I think it's just one of those [00:12:00] reminders to always focus on solving problems for your users or customers and, not to just focus on the shiny object.
[00:12:08] Redefining Stack Overflow’s strategy for the AI era
---
[00:12:08] Melissa Perri: If I could go back and just replace the word Agile and escaping the build trap with AI, it'd probably be the same exact book. The one thing that is interesting to me about the business model that you're talking about with Stack Overflow and going forward, is it sounds like you are looking at how do we position ourselves in this AI world, right?
Like we see this user behavior. Where it's turning now to LLMs to ask easy questions. Where are we strong, right? What's our unique value proposition? Like, where do we shine? And you mentioned that there's a part to a stack overflow where you're looking at data licensing too. How do you think about that with the AI tools?
[00:12:41] Jody Bailey: Yeah. So it's one of those double-edged swords, right? The obviously, from a revenue perspective, it's been really fruitful. At the same time, we're also fueling the engines that reduce the traffic to our site. The things that, that we're focused on, like you said, from a strategic perspective.
[00:13:00] Always go back to what are your core strengths, right? What can you do to leverage those, what are the things within an order of magnitude or so, innovation wise, that leverage those core strengths and allow you to win. The thing that, we believe we're good at is that human connection.
It's, getting information, technical information, and so we're really focused on how do we be the vital source for technologists and with ai, I think the definition of technologist expands. So really we're thinking technology enthusiast, it's naming's hard, but if you think about any business or organization with the tools that are out there for vibe coding, anybody can build something, right? And they don't consider themselves technologists, many of 'em, right? You think about your CFO who's building an app, right? Or your HR person, they don't necessarily think of themselves as a technologist.
But we believe that stacked [00:14:00] overflow can be beneficial to them as well, right? So we're trying to think, okay, what are our core strengths? Who are the core personas? How's that expanding? So we're looking at that, and then, what we wanna do is we want to make sure that we create a space where people feel comfortable, where they can interact, and they can interact in different ways.
Stack Overflow has always been focused on these canonical answers, right? The, they're questions that stand the test of time. They're unique and they've got detailed answers and they work or they don't. And that is so valuable and so important and we don't wanna do anything to break that.
At the same time, oftentimes people have other questions. Maybe it's a derivative of one of those that, and we would historically close it as a duplicate. Maybe it's a homework question, maybe it's just an opinion and those things historically haven't really had a place on Stack Overflow, and we believe that there's [00:15:00] a way to protect what we've always done while creating safe spaces for some of those other conversations that are important to technologists and technology enthusiasts. So as we've evolved our strategy, that's really how we're looking at it, is how do we have that walled garden, if you will? Or maybe if you think of the library, the place with all the information and the research and all that. But it's really, very tightly held, and then you have different spaces for different types of interactions and knowledge, et cetera. So that's how we're thinking about the evolve strategy on the public side.
[00:15:36] Melissa Perri: That's it for today. I hope you got something useful from these clips, whether you're thinking about how to reduce friction in your teams, better understand customer problems, or stay focused in the middle of fast moving trends.
If you wanna hear the full conversations, check out episodes 233, 209 and 239. And if you wanna level up your product skills or grow your career, head over to Product Institute.
One last thing before we go. [00:16:00] I wanna recommend a tool I use every day called granola. It's an AI powered notepad for meetings that helps capture notes and decisions automatically without interrupting your flow.
You can get three months free on any paid plan at granola.ai/product Institute. Thank you so much for listening to the Product Thinking Podcast. Make sure you like and subscribe so you never miss an episode. We'll see you next time.