Nan Yu (2:39)

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 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, they're going to 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, no one's 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 want to 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 them altogether and then it falls on us to have to fill in those blanks.

Interviewer / Podcast Host (3:43)

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 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 are, how they're doing product development too.

Nan Yu (4:10)

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 a problem that someone has in the abstract, right?

Interviewer / Podcast Host (4:22)

It's not.

Nan Yu (4:22)

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 get feature X, then we'll dig in and we'll say, okay, tell me about the last like, moment in time where you really felt like the need for vtrex, right? 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. And often you discover all sorts of interesting stuff, right? Usually they, 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, it was just solve my problem. They move on, right? But then they go, oh yeah, maybe I shouldn't, maybe I shouldn't even be doing this at all. Is like one, one question, is this really worth it? Or they unpack their problem. They could understand the problem to be like more specific. So I'll give you 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, you 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 changed certain to begin with. So they're just going to be wobbling all over the place. So if you just take that at face value, right, and they use it exactly as they hope, what will happen is the data will just jump back and forth all over the place. People are going to get spammed with notifications and they're going to stop paying attention. So 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 system has like, date. And then you have to be like, okay, 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 those shoes before. We're a pm. We're like, look, it's going to ship in the first quarter. Maybe I'm going to try to ship it in January. So what date do I put? And then you put something in there and then everyone takes it 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 notifications. 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 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.

Melissa Perry (6:34)

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 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.

Interviewer / Podcast Host (7:10)

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.

Andrew Davidson (7:26)

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, there are people who, if you filter through, there are people who will jump through hoops, figure out puzzles, move mountains to figure out how to get something done. Because anyone who's tried to write code knows you just constantly run into issues and you have to 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 give them. But on the flip side, they're 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 can 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.

Interviewer / Podcast Host (8:53)

Yeah, my experiences with developers are they will definitely try to solve problems, but they will not be quiet about it if it's frustrating. And I find they actually appreciate probably, you know, user experience and their tools more than anybody. Right.

Melissa Perry (9:08)

They're. They're in them 24. 7.

Interviewer / Podcast Host (9:10)

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, and start to build things. So I think that's a great parallel.

Melissa Perry (9:38)

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. Finally, we'll hear from Jody Bailey, chief product and Technology Officer at Stack Overflow. I'm on what happened when companies rushed to adopt AI, and why focusing on the technology instead of the problem led many teams astray.

Interviewer / Podcast Host (10:12)

I don't recommend tools unless I actually use them.

Melissa Perry (10:15)

So when I tell you granola has become a daily essential for me and most of my team, that means something.

Interviewer / Podcast Host (10:20)

We're all in a lot of meetings.

Melissa Perry (10:22)

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.

Interviewer / Podcast Host (10:31)

It's the rare tool that gives you time back instead of asking for more of it.

Melissa Perry (10:35)

You can try it yourself with 3 months free on any paid plan at Granola AI ProductInstitute.

Interviewer / Podcast Host (10:42)

When Generative AI first came out and you saw people turning to Claude and to ChatGPT 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?

Jody Bailey (10:56)

I'd be lying if I said no. I think many people in many different industries had that oh crap moment. And I think you saw a lot of people and businesses, you think SaaS, think other community sites, you know, had this oh crap moments. Oh, we've got to release something, we've got to have an AI solution.

Interviewer / Podcast Host (11:17)

Yeah.

Jody Bailey (11:17)

And you saw this proliferation of AI tools and talking with other CTOs, CIOs, etc. 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 reminders to always focus on solving problems for your users or customers and not to just focus on the shiny object.

Interviewer / Podcast Host (12:08)

If I could go back and just replace the word agile and escaping the bill trap with AI, it'd probably be the same exact books. 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 were looking at how do we position ourselves in this AI world.

Melissa Perry (12:25)

Right.

Interviewer / Podcast Host (12:25)

Like we see this user behavior where it's turning now to LLMs to ask easy questions, where are we strong?

Melissa Perry (12:31)

Right.

Interviewer / Podcast Host (12:32)

What's our unique value proposition? Like, where do we shine? And you mentioned that there's a part two with Stack Overflow where you're looking at data licensing too. How do you think about that with the AI tools?

Nan Yu (12:41)

Yeah.

Jody Bailey (12:42)

So it's one of those double edged swords, Right. 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 we're focused on. Like you said, from a strategic perspective, you 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. 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 them. 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 Stack Overflow can be beneficial to them as well. Right. So for 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 want to 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? 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 want to do anything to break that. At the same time, oftentimes people have other questions. Maybe it's a derivative of one of those. 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 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 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 evolved strategy on the public site.

Melissa Perry (15:36)

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 want to hear the full conversations, check out episodes 233, 209 and 239. And if you want to level up

Interviewer / Podcast Host (15:54)

your product skills or grow your career.

Melissa Perry (15:56)

Head over to Product Institute. One last thing before we go. I want to 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 3 months free on any paid plan at Granola AI ProductInstitute. 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.