We really focus on directness.
We really encourage in the app to write tasks in a way that just says what needs to be done as opposed to doing like a roundabout kind of 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 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.
that we're trying to get that off of your plate.
All the wrangling and stuff like that ends up falling, right, on PMs kind of by default.
No one signed up for this job in order to like input a bunch of data into a issue tracker, right?
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 themselves are too clunky for the engineers to want to use or engage with.
So they just disavow them all together.
And then it falls on us to have to fill in those blanks.
Creating great products isn't just about product managers and their day -to -day interactions with developers.
It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers.
With the help of some boundary -pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast. Here's your host, Melissa Perry.
Hello, and welcome to another episode of the Product Thinking Podcast. Our special guest today is Nan Yu, the head of product at Linear, a cutting -edge tool designed to enhance product planning and development with elegance and efficiency.
We'll be talking about how Linear has managed to crack the code on project management for software development by focusing on great user experience, as well as how product management is changing in the age of AI.
But before we talk to Nan, it's time for Dear Melissa.
This is the part of the show where you can ask me any of your burning product management questions.
Go to dearmelissa .com and let me know what they are.
Hey, product people, I have some very exciting news.
Our new mastering product strategy course is now live on Product Institute.
I've been working on this course for years to help product leaders tackle one of the biggest challenges I see every day, creating product strategies that drive real business results.
If you're ready to level up your strategy skills, head over to productinstitute .com and use code LAUNCH for $200 off at checkout.
Here's this week's question.
Dear Melissa, my CEO read about OKRs and now wants the product team to set quarterly objectives, perspectives, but our development cycles are longer and market feedback takes time to materialize.
I feel like we're optimizing for the wrong metrics just to show progress.
How do you make goal setting frameworks actually work for product development instead of just creating busy work?
So everybody gets really excited about OKRs, but a lot of people don't figure out how to deploy them before they start everybody getting out there to make a bunch of goals and put them on a piece of paper.
And that's just busy work.
Like you said, when you're talking about OKRs, what we're we're really trying to do is help us set goals to measure our strategy against. And they have to tie back to your strategic layers.
So for instance, an OKR, objective and key result, will fall at different time spans depending on what level of strategy you are tying it back to.
So for instance, if you're setting this product initiative that might take a year or two years to reach, you have one OKR for that year to two years.
It's something that you want to achieve over that time, right?
It's not something that you are going to be able to ship something and hit tomorrow.
But if you're shipping things on a quarterly basis with a team, you can set an OKR to measure the results of what that is and see if it ties back to your strategy.
What people do typically is they set OKRs independent of these strategy levels, and that's not correct.
So you want to think about what are our big company OKRs.
And our big company OKRs are things like I call strategic intents.
You can write it as an OKR.
It doesn't really matter.
It's what's my objective?
what are the key results we want to hit?
Those usually take a very long time to manifest. They could be a year and a half to two years, sometimes three years as a strategic intent, because they're very big pushes forward with our company.
They could be to expand into new markets, and you would measure that by the number of customers that you'd acquire in those markets, how much revenue you'd actually put back into the company for those specific markets.
That takes time to develop.
Again, retention metrics might also be up here as well.
Well, measuring retention takes time.
What you want to do on a product level, and if you're looking at a quarterly OKR, is looking at back at that company OKR and saying, what can my product contribute to this goal in the next quarter?
And that's going to form your product level OKR, which should be a leading indicator.
So for example, if you're trying to increase retention, maybe you go out, you pull a bunch of data, you do a bunch of analysis, and you find out that some people who are retained more than others in this cohort are doing X, Y, and Z with your product.
They have adopted a new feature or they engage with it more and you want to put out there a change that encourages people to engage.
Your OKR is going to be related to engagement.
So if you ship that thing in your change, you want to measure your key results to see if it increased the engagement.
Now here's where the quarterly part gets very difficult.
If you can't ship quarterly, then you're not going going to be able to measure things on a quarterly basis, right?
You're not going to be able to tie back the changes that you made to an OKR on a quarterly basis.
You'd just be making up new goals, but you wouldn't be shipping anything towards it.
So you want to tie your OKRs back to what those leading indicators are to show that you're reaching more value for the company and for your customers.
And it has to be tied to what you're able to actually achieve.
So if you can only release once a year, you're going to have yearly OKRs.
Why would you have more OKRs if you You can't put more things out there.
It should be tied to that.
So that's the argument that you want to go back there with is that when we're looking at what we release, we do want to set metrics around it to measure the results of the release.
Those metrics, though, should be leading indicators and they should be goals that help reach a bigger goal at a middle level of strategy.
That's where your product initiatives come in.
That's where the longer term product strategy is.
And that should all roll up to a company level goal, which is part of the company strategy.
strategy and if you are missing those middle bands you won't know how to set your goal so that's where leaders have to come in and really make sure that they set up great product strategy so that you are able to break down your goals and whether they're quarterly or they're weekly or they're monthly it should be matching how fast you can ship and how fast you can actually achieve that so I hope that helps thanks for your question and again if anybody has questions for me go to dearmelissa .com let me know what they are now let's talk to none welcome to the podcast Non, it's great to have you.
It's great to be here.
Thanks, Melissa. So Linear has been taking, I feel like the whole development world by storm.
I hear so many good things from people.
Can you tell us a little bit about how you became the head of product at Linear and what your career journey was?
Yeah, I think my first touch with the Linear founders was when they were doing some extensive like research very early.
I think it might even have been like pre -launch. I was running an engineering team back then and like we got put in touch and they were interviewing me about our development process and all the of different things that I had to deal with our existing issue trackers and things like that.
So I think that was the first time I talked to Kari and Jory in a real way.
Yeah. And we kept in touch throughout the years.
And at some point I was in the market to like look for something new and I was doing some consulting work and I started working with these guys and we hit it off.
And that's how we decided to get in cahoots.
That's really cool.
And a little bit of trying before you jumped in.
So when you were working with them, you've been on this mission of trying to to bring magic back to software.
Can you tell us a little bit about how Linear got started and what that actually means at Linear?
Yeah. I think we are, all of us, like people who got into software because it was really fun.
If you ask a lot of people on the team, what was your first experience in software?
It wasn't doing something commercial.
It wasn't like at a job.
We were hacking video games or building maps in Starcraft or something like that, right?
Where we had to first write a bunch of scripts and things.
So we all got into it because we really enjoyed it.
And then you look forward to, hey, I get to build software for a living.
it's great. And then you hit a sort of corporate situation.
And then you start having to bump into all this weird friction and all of these tools that just seem like they're really not made for you.
They're made for somebody, but that somebody really wasn't thinking about why you got into software in the first place.
And it just robs it of a lot of that magic and joy that was the whole reason you got into it.
So I think that's what we mean.
Building software is inherently fun.
It's inherently interesting.
And we're just trying to get out of your way so that you can experience that.
And what, what you're really concentrating on now is the development software, right?
Like the whole process of how do we build products together?
Can you tell us a little bit about what linear looks like today?
Yeah. So linear, if you look at it on first class, it looks like project management software for specifically made right for software teams. And, and we did this because we know that there's a lot of things that software developers want to take for granted.
And there's other things where they want like a lot of control.
And we're making something that's that's really purpose -built to, again, to make their workflow very efficient and very enjoyable.
So that's where we're aimed right now.
We've added more features as times progress to help different companies of different sizes adopt linear in a seamless way, but we never really take our eye off of the core workflow that individual contributing engineers have to deal with.
And for that, when you're looking at making it more magical for that software development development process.
What types of things did you really hone in on?
What frustrated you guys going into this where you're like, this could be so much better?
Yeah. I think the two very related things are speed in every sense of the word and directness.
Speed is everything from, I engage with a CTA, I click on a button or something like that.
And it should just respond immediately.
Not have to wait a few hundred milliseconds, seconds, they 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, right?
Like it's, 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, 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 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 your plate.
I feel like that's such a huge complaint to from the product management world, especially about JIRA, or some of these other tools.
And a lot of there's also a lot of developers I've heard lately, looking at product managers or let's say, people who are beginning to learn product management, right, where they're going, wow, they're just like a Jira backlog person.
That's all they're doing is they're filling in all these things, writing all this stuff, but it's not really about the work.
When you think about that, what types of things are you putting in to help product managers in that flow as well or 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 like input a bunch of data into a issue tracker, right?
That is not, 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.
with. So they just disavow them altogether.
And then it falls on us to have to fill in those blanks.
How do you see teams working differently that use linear compared to ones where we do have that product manager who's all over JIRA and putting things in?
What have you been able to unlock with the teams and help with their workflows?
Yeah, I think the first thing, the comment that we get from engineers is like, Oh, this is actually fun to use.
I actually enjoy being here.
This is a surprise to me, we'll say that, right?
Because a lot of times, especially people with some experience, they're like, Oh, they're all issue trackers are the same.
They're They're all just to -do lists or whatever it is.
It doesn't make any difference to me.
And then they use linear.
Okay, actually, this is quite different.
And I think it's the design goal that we have is, look, they all take notes somewhere, right?
They all write things down.
No one relies purely on their memory to remember what to do and plan ahead and things like that.
So we want to be as fast as just writing it into a notes app or whatever it is, right?
As long as it's that fast, then they're very happy to do it.
They're happy that it's automatically shared and managed and structured.
Those will become benefits.
fits. And what we see in the data, when people transition from other tools into linear, is that the number of distinct issue creators goes up by a significant amount, like 60 % to 100%, right?
Like people actually are engaged with the tool.
And this has like really good knock -on effects, which just means that, hey, if your engineers are engaged with the tool, that means your data quality is more robust and it's more complete.
So that if you're going to run some reporting or something off of it, then that reporting is going to be more valuable, right?
It's going to be closer to the ground truth.
Yeah. And that's important too, because I feel like with that that reporting, and if people are actually putting what they need to into those systems, it also helps leaders like yourself as well, be able to get some more transparency into what is actually happening was the work that's going out there.
And we're not all running to quickly enter all this stuff in for a whole day and backtrack to where were we and what is it taking?
So what kind of like insights do you feel like that helps you prepare for that you can get out of here?
I think there's a lot of things that you can get out of your risk tracking system.
A big part of it is, you know, like starting from a really granular level is just what are people what have people been focusing on lately, right?
And you combine that with some way to scan a lot of this stuff, and summarize it.
And then you end up with like pretty robust reporting, not just counting reporting and dashboards, but also even qualitative reporting about, hey, here's what the team has really been focusing on in the last two weeks, like, there's this problem that we described, hey, you're an inch manager, and you go on vacation for three weeks, and you come back, and then you're just like, congratulations, you just signed yourself up for a month of like Gaining all of the context that you just dumped, right?
When you're going, and we really want to help people bootstrap that context within a day or two.
And when you talk about like getting the developers in there to actually use it, are you doing that through like integrations?
Is that like UX strategy?
Like what do you feel like changes that behavioral part of them actually wanting to go in and engage with the app?
How do you unlock that?
Yeah, like fundamentally it's mapping to the workflow.
You got to start there, which is like, what's the first thing that you have to do as a developer?
developer, what's the first annoying bit of friction that you have to deal with?
It's, I got to make a new branch. I need to know what to name it, all that kind of stuff.
So we want to start from there.
The first thing you do is every issue comes with a branch name.
So then you use that branch name.
And if you use that branch name to make a new branch, the moment you merge it, it feeds back into the system.
And we know that you completed the issue and all that kind of stuff, right?
As long as we engage with you at the very start of your development process, we're automatically tracking quite a bit of progress and different stages of development as you go through, which alleviates developers of having to manually update that kind of stuff, right?
We see people coming in from other tracking systems and they're like, never keep my issues up to date.
The status is always wrong.
So at the end of the week, the PM goes in there and they like touch up everything.
That shouldn't be anyone's job, right?
We need to solve this altogether.
So by solving this, I don't know what to call my branch, right?
All these downstream problems are also dealt with.
Yeah. So we're mapping and we're integrating into the developer's workflow.
we're not actually asking them for things that are beyond what they're normally doing.
Yeah. Yeah. In fact, we're doing a lot of the cognitive work for them.
Yeah. That's cool. So with a tool like this as well, obviously, you are working with the software developers to your team is building a tool that they would be using.
How do you really balance listening to customer feedback versus having an opinion about what you should build there?
I don't I don't think about it as like balance necessarily.
A part of the privilege of building for your peers, in all honesty, right?
People who are developing software like you, people who are PMs and engineers and designers, you get to have much more like real conversations with them about what actually happens on the ground.
So if you take a PM who is naive about this, and I was naive about this when I kind of first started here, and you go into a customer call or something, and then you ask them about the process, you're expecting them to come at you with these very highly opinionated workflows, right?
Oh, we have to do things this way.
We've set up all these automations or whatever it is, and we have this well -defined process because you read any kind of, I don't know, PM blogs or whatever it is.
It's like all about, oh, here's a step -by -step guide to how to do things.
But then you ask them like, okay, tell me about what actually happened when you planned your last project or what actually happened when you planned your last quarter.
And it's just, oh, we got in a room and we decided what to do.
And you realize that a lot of that is good in theory, but they don't have the tools to actually enforce it or to carry it out.
A lot of what we get to do is, is we get to take the input about what people hope to do, understand what they are actually doing in real life and accomplishing on the ground, and then try to help them marry those two things together as much as possible.
So the constraints are not nearly as harsh as you would expect going into it, but you have to level with them as like a peer for them to open up about it.
And then I guess on that side too, it's your product managers.
And 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 one that someone has in the abstract.
act. 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 had 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? That'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?
Like usually it's, they learn a lot more about their problem in those moments as much as you do, because they didn't think of it.
They kind of and thought, if I have feature exit, which is not my problem, they can 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, 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 a very specific example here, right?
Which is a lot of times people say, I really want to notify my marketing stakeholders when my dates change.
And that's good, right?
Like 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 going to 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 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 going to ship in the first quarter.
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, 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're at a date.
How do you also help people understand maybe their capacity?
Like in development, I feel like the no, there's like this whole no estimates crowd that comes from the agile side where it's like, we will never tell you when it comes out.
They don't think that we should give any granularity whatsoever.
How do you balance that?
And what kind of insights and tools are you giving people to help understand we can take on this much, or this is how we can plan and this is how we get to a reasonable estimate of what we can accomplish and when we might be able to accomplish it.
Yeah, that's a great question.
It's good because the reason it's a good question is because there's like a lot of implications and assumptions in it, right?
When people say, what's the estimate for this thing?
What they're doing is they're fixing scope.
With a fixed scope, how much time is it going to take?
And I think the thing we encourage people to do, both within Linear with the team, but also like with our customers is to like, understand that it's fixed scopes, especially especially big fixed scopes, are almost certainly incorrect for reasons beyond estimates, right?
You're not going to build the right thing.
If you are in certain industries with certain kind of reporting and compliance requirements and stuff like that, I can understand that.
But for the vast majority of software development, that's not how it works.
How you want to build it is milestone by milestone.
You want to build it more as a sort of investment appetite, as opposed to a fixed scope and then an estimation that you're trying to get exactly perfect.
So I think that's how we think internally about capacity and planning in that way, and also how we encourage our customers to do so.
So when you have a project, rather than saying it's exactly going to take these three people starting from this day, ending on this day, just talk about it in terms of what we're going to try to deliver this in Q4.
Here's the investment appetite that we have with these three contributors.
And then here's some views to understand how overloaded people are.
This is such a big topic for people too, I think, who are transitioning out of that project type mindset into product mindset.
One of the things that I always hear from leaders and something I push back onto, I think, from the like, no estimates crowd is that you do have business planning implications, right?
So it's not like we could just be like, when it comes out for like ever, like this big thing that we're making a push for, I don't know if it's this year or next year, and then a year after, how do you manage those communications as a head of product and like work between sales and your different executive team members to communicate communicate the right level of information and the right expectations on timing and scope and all of those different things i think the the way that we manage it is we try to get to a plausibly shippable version of the app as soon as possible right of the feature
or whatever it is we're developing often that happens very quickly it delivers the core value or whatever it is in a couple of weeks right if we have three months budgeted for something like that in the first first month or the first couple of weeks have something that more or less works.
And then it's about how much refinement and how much internal testing and beta testing do we want to do to accrete on top of this to get to a point where we want to really do a big marketing push against it.
So software is one of these things where it's never done, right?
No one looks at the thing like that software is completed, so they'll never be touched again.
So it's always a decision on whether or not you want to enhance it further.
So I think our job as PMs is to position and sequence the development in a way where we get to something that is plausibly like something we can put in front of customers as early as we can.
And then everything else is about adding more value to that feature.
So I describe it like, it's like you're painting a painting, right?
And like, look, if you get a professional painter to paint something, like they'll kind of take a pass at it.
And you're like, that looks great.
I would buy that. And they're like, no, I'm not done.
It'll do another pass.
They'll make the shading better.
They'll do whatever it is, right?
They'll increasingly give you more fidelity in the product that they're making.
And at some point, they're They're good.
They're going to feel satisfied, right?
And then, and somewhere you have to go to market, but we want to give people the ability to press that button whenever the business needs it.
There's always that.
There's like a funny line that I remember everybody used to say.
There's V2 is like the biggest lie, right?
Like going back and actually going and do that second pass.
How do you ensure that your teams do go back and do that second pass?
What kind of space and what kind of environment do you create to make sure we're not just shipping something and then never ever touching it again?
It's a whole collection of techniques.
Like the most important thing that we do is we have escalating rings of users that we deploy to.
So by the time something goes to full production, it's been in private beta.
It's been an internal first, right?
Where all of our internal users are using them on a daily basis because we use our own products.
It's been in private beta with certain sort of like friendly companies and organizations that we have very high bandwidth communication with.
They'll give us like the real feedback.
It's been in public public beta where there's like an opt -in beta group where you can join and it will just like 5 % of the audience, they'll take it.
And then it conventionally makes its way to production.
By the time it makes its way to product, it's like V6 already.
It's not really about even getting the V2, it's about giving us built -in like escalations, right?
Where we're going to get more feedback and we're going to digest it and then modify the product accordingly.
And when it comes to product manager's role in that, you've said before like product management is a selling and a building function.
Can you tell us a little bit more about what you mean by that?
Yeah. We talk about talking to customers a lot.
And talking to customers, that's a mechanical thing that you do, right?
What's the point? The point is understand how the customer views the world.
Because at the end of the day, you're going to have to bring something to market and give it to them in a way that they can receive productively.
So part of that is, does it fit into their life in the way that you hope in terms of the pure product sense?
But also, can they onboard into it?
Can they understand what you're giving them?
are you emphasizing the right things when they encounter it?
So they capture the value earlier and they don't dismiss it out of hand.
All of those questions are as important as does the thing ultimately do what you want it to do?
And I think that often we discount that aspect of it, or we like say, that's up to marketing or PMM or something where I think that's really like abdicating like a really core part of the responsibility, right?
To make the thing acceptable to customers.
So when you're looking at your product managers and what you have there, you mentioned marketing, PMM, and I think this is a big topic in product management as well.
When does product marketing come in?
When does marketing come in?
What does the product manager own versus what does PMM own?
What's the scope that you give your product managers?
What do you encourage them to own and to end?
And where do you see the lines between those other functions?
So I don't see a clear handoff point between product management and PMM.
So in our org, work PMM reports into me, right?
So PMM and product management are part of the same organization.
And so they're involved very early on, right?
Maybe not quite at inception, certainly by the time the first beta goes out, usually by the time well before that.
And the first PMM deliverable is what is the messaging that we're going to give to private beta customers, right?
These people who can be really real, we can be a little bit technical, but we just need to say one or two two paragraphs about this feature in a way that will immediately help them understand what's going on.
We don't need to sell them.
That's what we don't need to do.
We don't need to sell them on linear as great.
They already believe that.
What we need to do is have them understand and be able to get value from the feature on day one.
So that's almost like the baby PMM deliverable because it's not a general audience.
It's really friendly.
And then we ramp up from there.
So as the product develops and hits wider audiences, they have to figure out wider and wider messaging.
But it starts very early, right?
I think a lot of times you end up in a situation where like PM goes like, okay, we're done.
I'm going to throw it over the wall and then PMM is going to get it and they just don't know what to do.
And it's like a big fire drill.
Hopefully with us, it's a much more gradual and natural integration.
I feel like PMM now that product is becoming bigger and bigger in many of these organizations.
There's a lot of companies out there that maybe are not purely software native or maybe they are, but they had a very strong product marketing function.
And now they've also got product and they're like trying to figure out what does product marketing do in a world where product management, right, is coming out and developing these features and going through the idea and all the things that we've just been talking about?
What does your product marketing function do?
And what kind of value does it bring to the product managers?
Like what's the kind of areas that they really concentrate on there?
I think they do a few very specific things.
I think one of the things that they really do in earnest is they are the shepherds to get it out into production, right?
They are the release managers, basically.
Because the last leg of getting this stuff, you know, acceptable to audiences is making sure that all the communication is ready to go on launch day.
And so that ends up being the bottleneck, but also the sort of enabler for the sort of final stage, right, of rolling things out.
If you work backwards from that, there are very specific communication touch points that we have. One is to our internal go -to -market team.
So there's written documentation presentation there's a sort of internal presentation that we give to our all of our internal go -to -market and sales success but even customer service and brand marketing so just internally here's our internal launch here's what it is i'm going to demo everything pretty extensively to you and then tell you about all of the the messaging and the sort of use cases and stuff like that we've developed and then in front of that if you go even further ahead is a beta messaging what do we say to our beta customers and what do we learn from them right in response So I think
all of those things are the responsibility of PMM.
And each one of those moments is a partnership with product management, right?
It's not like there's a clean handoff where PMs release it from their ownership, right?
It's like you're doing these things together the whole time.
And then the sort of more like communicative aspects of it are a PMM role.
all great and when we're talking about product management in the future of it these different roles ai always plays a really big piece in it i'm curious what are you guys considering when it comes to ai in the way that we do our work for product development and how do you also see it shaping product management in the future i can tell you what i hope right and what we're building towards which is if you think about the list of activities that a pm does day to day we already already talked about like all the silly data entry that we were asked to do, but a lot of the work ends up being shaped like
you have to try very hard and be very diligent.
And it involves reading a bunch of stuff and then honing it down to some smaller surface and then expressing it, right?
So it's like, Hey, I read a bunch of customer feedback and I like wrote this, you know, wrote this sort of report on like the requirements or what we need to do.
Or we, I took a bunch of ideas internally and I crafted the PRD out of it.
Or even we had a whole bunch of meetings and discussions and I made takeaways and next actions and updated the PRD with some decisions that we made.
All of those things that follow that pattern, I hope that AI is going to take off our hands.
That we can be as much consumers, like we can be the people who are in those discussions and being very active and in the moment and present.
And we can be the consumers of the outcomes as much as anything.
And we can be the editors at the end of it.
I think that is how I I hope AI is going to transform our jobs right personally so that we could actually focus right on what we came here to do which is as much as possible be on the ground with customers understanding their needs asking the right questions and working through people's problems with them so that like we can generate all of the right context for like subsequent decision making and when you think about linear and like the product itself how are you helping people do that yeah so we're what we're trying to do like in a very mechanical sense is to almost literally look at a set of responsibilities
that PMs are asked to do.
And it's like carving out the individual ones and saying, what can we build in order to make this a lot easier, right?
Or to completely automate.
And then, and what's left, right, is the stuff that we want to do.
So the first, our first slice of this that we did was like, I'm sure the PMs out there have had this experience before, which is, hey, look, there's a bunch of feature requests that come in.
They linear, maybe elsewhere.
And you literally have to just read a whole bunch of feature requests and decide what to do about it.
And those decisions are all sorts of, there's all sorts of actions you can take.
Oh, actually, this is a bug.
So I better file it over to this engineering team.
Or no, this goes to this other PM because it's like the service that they work on.
Or this is a duplicate of something that we talked about last week.
And then now you have to go on a quest to find it.
And if you're lucky, you remember that.
If not, then you're probably just going to have a bunch of duplicates in there.
Or it's like very related.
It tells me something more about something we've already decided to do, right?
So I should probably link it together.
So all of those little kind of things that you do add value to this new information that's come into the system.
And it's often on us to do this.
And if we're really diligent, we're able to do this with some level of reliability.
But scaling this up is extremely hard, right?
Doing it the same way across multiple teams, it's like you're going to get very unreliable results.
So our first goal is to take this specific activity off of your hands.
What you can do is you can see instead of having to deal with every single one of these things individually, you can say, hey, what's been coming in for the last week?
Let's see what's come down the pike and where it's been routed to and who's been doing it and things like that.
And then obviously you can still dig into the individual things if you want, but hopefully you're able to, again, be on the receiving end of the report rather than having to build it yourself.
When I think about linear too, and you guys play in this kind of crowded space, right?
We've got our gyros out there.
We've got all these project management tools.
We've got some things that have been so entrenched in these companies for so long.
What have you seen help people make the shift over to this?
Because I can imagine there's a lot of product managers and developers probably listening to this going, oh, it'd be great if I didn't have to go do all of these things in there, but my whole company's on this or we were so entrenched in these different ways of working.
We just spent a million dollars setting up Jira.
I can't go get them to pull that all out now because we want to do it.
What do you think helps bring people out of that mentality of we're trapped with our current systems and helps them see that we can migrate or we can get into different things like this if it will help.
I think there's a lot of different reasons people feel stuck or they feel excited to make the change.
Usually it takes some inflection point where, hey, we're about to begin a new quarter.
Let's do our new planning and this new system instead.
And I think people do have a lot of some cost feeling where they're like, hey, we've invested a lot to do all the settings for for our old system.
And it feels painful to let that go.
But I also think that people realize on the ground that if the engagement is poor across their team, that all of those settings and all of the reporting that you set up and automation stuff like that, they don't really help anybody.
And I think it takes a realization, right?
That that's what's happening, which is it's a, the larger your organization is, the more change management there is.
So it's, it can be a little bit difficult, certainly, but also with part of our goal with, a lot of the sort of AI -driven stuff, like the stuff I just described, is to help you get value on day one, right?
Because often what people feel is like, look, if I make this big change, maybe it'll pay back in like a quarter or two or something like that.
So I got to really balance how much investment it takes to migrate everybody off versus the payback period.
But one of the things that we do is like, look, you have all of this tribal knowledge, basically, right, embedded in all of the issues and stuff that you've done in the past. We're happy to import that for you.
And then every single time a new issue comes in, we're using who worked on what what and what team worked on it and all this kind of stuff to help you like actually take any of that incremental new information and route it to the right place.
So we can take a lot of that stuff off your hands almost immediately using some of the newer AI features that we've developed.
You're also making me think about, especially when it comes to product operations, this is like a huge part that's near and dear to my heart.
As leaders and as product ops people, we try to get the information out of these systems. So we get a good picture of what's going on, but it's also also to come back and help us try to link strategy to execution.
So how are you using linear?
And what other things would you need, like around it to be able to say, hey, I'm setting our strategic goals, right for my product management team?
How do I keep on track of that?
How do I make sure that we're moving towards them?
Well, I think within linear, we want to have end to end ability to express what we're trying to do.
I think like, ultimately, that's the entire point of a distributed project management system is for someone to be able to look at the system and say, what are we trying to do?
What are we even trying to do?
Because there needs to be structure to it.
It can't just be a big flat list because then you don't know what you're actually trying to do.
So we have a lot of structures in there, like initiatives and projects and timelines and stuff like that to let people express their intent.
And then on the other flip side of it, to report back out, well, how's it going?
Are we actually doing the things we set out to do?
Where is the effort being concentrated?
Is it concentrated on the strategy that we defined here in these structures, or is it concentrated elsewhere?
So in order to have reliable reporting like that, you have to have good engagement across the board, right?
So all of these things interlace, right?
So that's why the most important thing for us to do is to make sure that the on -the -ground engagement by individual engineers is extremely high, that the data quality is very good.
And then once you have that, then you get the privilege of actually reporting out what's going on.
I love that you say that too, because that was always my biggest struggle.
When we would go into companies and set of product operations, our information is only good as the data that we have in these tools.
So if people aren't using the tools, and they're not using it correctly, I can't actually pull all that information out and give the executive view or the progress view of where we are.
And I think that's such an overlooked thing when it comes to tooling.
And when it comes to what we're looking at.
It's not just about having a tool there.
It's about having a tool that somebody uses.
Yeah, exactly. And you keep coming back to we get the developers in there to interact with it.
It sounds like like that's a little bit like your Northstar metric.
Is that something that you guys are always continuously monitoring and looking at, like the engagement across it by different people?
Yeah. I think that that's our core value, right?
Everything that we do is relative, like with respect to that value.
A lot of times people talk about going up market and you can get, it can get very easy to be like distracted by saying, oh, we have to serve enterprise needs and stuff like that.
Like the way that we think about going up market is we get to be in the hands of more individual developers if we enter into a larger organization.
What can we do, to add this type of value to more individuals, which means that we can't do anything that gets in their way.
We can't be like, well, because it's a big company, we have to do all these extra things that makes life more difficult for them.
No, then we're actually not even doing the thing we set out to do, which is get this exact value into more hands.
I love the focus too.
When you explain your mission here, I could tell it's just ridiculously focused, which is very hard to find sometimes in a lot of companies.
And what is it like across your executive team to build that focus, to reinforce that mission?
What do you do to make sure that everybody knows what we're driving towards and that we are all aligned as executives as well?
I think I'll say the nice part about working at Linear, one of the real benefits is we use our products so constantly at every single level of the company that it doesn't have to necessarily come fully from the executives.
The engineers will riot if we do anything that makes their life harder.
And that's good, right?
It's a control that we get to have and keep ourselves honest about it.
Obviously, it's like top of mind for us as well.
But we know that a lot of the little details and things like that, everybody who's developing the product is constantly paying attention to.
When you're looking at the landscape too of product management, development, all of these things, we talked a little bit about AI, but over the next two to three years, what do you think's going to change and what kind of trends are you looking forward to?
Yeah, I think that reviewing work is going to be a really big deal.
And I think that often we think about it as the last step of, and then people maybe don't even take it seriously.
They just like rubber stamp it it and let it through.
But if you think about work, especially like development work, as a system of abilities and bottlenecks, the bottleneck that really got released is number of simultaneous things that you can do at once.
We have AI agents that you can deploy inside of linear like today, like coding agents, where you can go into your backlog, command A, select everything in your backlog and say, just do them.
Is it going to be good?
Is it going to be reliable?
Is it going to integrate well with your code?
I don't know yet. But you can tell it to write very plausible plausible code and make a pull request against every single thing in your backlog.
And then what you're left with is a ton of review work.
So I think that's going to be the big sort of change in software development is a much bigger emphasis on evaluation and review and certification and things like that.
Yeah. That's a really great one to bring up there.
And I don't see everybody looking at evaluation yet.
I know those types of things are still coming up and becoming more of the the talk around AI too.
And our last question for you, Anan, when you go back and look at your career, what advice would you give to your younger self?
Gosh, it's always hard. It's hard to look at that stuff in hindsight because it's like you're just swimming in it at this point.
I think when I was younger, I read a lot.
I read a lot about like craft and what a PM is all about and things like that.
And I think you can really only get so far doing that.
Like the moments where I learned the most was when I sat down with someone who's done it for a while.
I'm like, just tell me about everything you're doing while you're doing it.
And I think that those moments you cut through the posturing, and all of the what people hope is true to what actually is happening on the ground.
And it really does simplify a lot of things.
So I think that's probably Yeah, I probably read fewer things about how to PM and just go annoy a seasoned PM and see how they do their job.
I think that's great advice.
And I know so many people are afraid of just going to ask people like, How are you doing this?
Show me what's going on.
But I know, in so many companies, People are really happy to share that.
They're really happy to have someone learn from them.
Yeah. And I think a lot of people, they maybe not even vocalize this stuff.
It's stuff that they've developed over time, and it's layered on if they learn things, and they've never explained something to somebody else and walk people through how they do things.
So yeah, I wish I'd done that a little bit more and a little bit earlier.
That's super valuable advice for people out there listening.
Non, thank you so much for being on the podcast. If people want to learn more about you or Linear, where can they go?
You can follow me on X.
I'm the non -U, T -H -E -N -A -N -Y -U.
you. That's probably the best way to see stuff I write and also interact with me if you want to send me a message or something.
Amazing. Thank you so much for joining us, Nan.
And thank you to our listeners of the Product Thinking Podcast. We'll be back next Wednesday with another amazing guest. Make sure you go to dearmelissa .com and let me know any questions you have for me.
In the meantime, I answer them every single episode.
We will see you next time.
