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 Perry, 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 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.
And 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.
Speed is everything from I engage with a 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 like kind of 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 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 value right 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 you're delivering.
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.
What types of things are you putting in 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?
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 ship working code that customers are using.
And so all the wrangling and stuff like that ends up falling on PMs by default.
No one signed up for this job in order to input a bunch of data into an issue tracker.
No one dreams of that, right?
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.
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 when you're the company and see how they're doing product development too?
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?
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 moment in time where you really felt like the need for feature X.
Was it last Tuesday?
Was it this morning?
When was it?
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 didn't think about it.
If I had feature X, it was just all 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.
It's like one question, is this really worth it?
Or they unpack their problem, they kind of 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 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 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 will happen is the dates 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.
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.
The system has a date, and then you have to be like, oh, it's January 1st.
But you don't think it's January 1st.
We've all been in those shoes before.
We're 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 like very literally.
And all of a sudden you're like getting health 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 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 don't feel like you're lying to people every single time you write a date.
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.
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.
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.
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.
All of the many things that you just have to think about when you're in this type of product.
Yeah, I.
My experiences with developers are they will definitely try to solve problems, but they will not be quiet about it if it's like frustrated.
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.
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.
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 granolaai slash product institute.
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 going to do?
How do we think about positioning ourselves here?
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 in businesses.
You think SaaS, think other community sites had this oh crap moment.
Oh, we've got to release something.
We've got to have an AI solution.
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.
If I could go back and just replace the word agile and escaping the build trap with AI, it'd probably be the same effect.
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, right?
Like we see this user behavior where it's turning now to LLM staff, 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 too with Stack Overflow where you're looking at data licensing too.
How do you think about that with the AI tools?
Yeah, 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 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 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 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?
That 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 that 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 that plays 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.
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 your product skills or grow your career, 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 three months free on any paid plan at granola.ai slash 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.
