Problem Definition

"I went from wanting to curse Rick out for making me drive 15 minutes to come pick him up to feeling like, all right, no, no, no, there's real value I'm providing you in driving him just two minutes. But I recognized that wasn't embedded in the structure of paying."

"For me, it's a person who is just on the cusp of taking the action you want to take... I like to go to the worst. It shows me everything that's wrong, but the marginal user thinking helps you prioritize what thing to do next."

"In all this advancements of the AI... one easy, slippery slope is to keep thinking about complexities of the solution and forget the problem that you're trying to solve. When you're trying to start at a smaller scale of autonomy, you start to really think about what is the problem that I'm trying to solve and how do I break it down into levels of autonomy that I can build later?"

"80% of so called AI engineers, AIPMs spend their time actually understanding their workflows very well. They're actually in the weeds understanding their customer's behavior and data. And whenever a software engineer who's never done AI before, here's the term, look at your data. I think it's a huge revelation to them, but it's always been the case."

"I asked RPM at Replit, Aman Mathur who's a fan of the show to tell me what PMs like to build. And so he came up with a prompt. He kind of really crafted a great prompt... basically, what we're asking for is we want to build a web application... for product managers to track feature requests on a public dashboard."

"Don't think about agentic user. Let's say Lenny, 30 years old, doing A, B, C things... His relationship with this category of food delivery is X. These are the things that he has done in the last month. In the last three days, there were the needs, desires, aspirations, fears, frustrations, et cetera, et cetera. We say, 'Okay. It's 11:00. What's happened? Why is this user open, or what triggered this particular app, and then what happened?'"

"We have a meeting called OPA, which stands for opportunity/problem, assessment. And so, what this is, it's a meeting where basically PMs... debate and discuss with each other and spar around either areas and problems that they want to go investigate or after they've gotten data back or research back from evaluating an opportunity."

"Explaining exactly what you expect and what you're not getting is even more important with AI than with the humans. So I'm going into hooking up more of the actual functionality, but first I'll actually show you something. What's the fastest way to change what went wrong, it's created buttons that say book now and I want them to say, 'Buy now.'"

"The big learning is that you have to start with how is this product working end-to-end and then add AI or think where should we add AI? So that was a big learning for me that you really want to see what does the big picture of the user, what's the big picture of how do you think the user experience should be?"

"I've repeatedly learned that when you're doing something new, zero-to-one, the temptation is to kind of think about... go to scale before solve. So I've always said to my teams solve before scale. So what that does mean is there's a different posture and different mode when you're trying to solve a problem versus scaling something that's either post-product market fit or even at least in roughly in the ballpark."

"You can't stop until you get to the end... so much value is lost when the person in the execution role isn't really in command of all the details... you can't avoid the details, you just have to get into them."

"PPS framework that I talk about a lot, which is problem, people and system. So, whenever there's a challenge that comes up... I like to first say what's the problem? Who are the people involved and what system does it impact? Usually because people just jump straight to the system."

"First you have to really understand from first principles what is actually going on. So understand, identify, execute. So when we talk about understand work, there's a few ways to think about it. One is, it is an intentional affordance in your execution to do the work that helps you to de-risk a project and to learn what's going on."

"I try to encourage the product managers to what's the problem with the thing? And then let us solve it. Don't jump to it and tell us... Don't tell us this is just exactly what we're supposed to do."

"We connect people with complex conditions... with their own health advocate... we want to close the gap between patients and the healthcare system. There's this critical layer of the system that's missing, I think, people are navigating life-threatening or debilitating conditions largely with Google."

"But the real thing that if you start to study causality is that a struggling moment causes demand. And you start to realize that in some cases that struggling moment exists and can exist for a long time and nobody solved it."

"And so that's what we mean when we're customer-centric is that we're studying the struggling moments they have and people like Intercom and Basecamp, they look at struggling moments and that becomes their roadmap."

"The first two things are the things that are hardest to define, like who's the customer? ... Then what is the specific problem you were solving? Ideally, you would some way have quantify that problem or there's some data or customer insights that have led you to understand that problem, to know that it is a meaningful and big problem."

"I would argue this is a case where we made the mistake of what we had a technology solution in mind, which was 3D effects. And then we took that solution and we're then in search of a problem. I don't think it solved any meaningful problems for customers."

"The canonical version of it encourages you to think about the context in which the user's operating or the other things outside of your product that they might be going through."

"Product is finding the kernel of truth in a sea of ambiguity and signals... what is noise? What is a good idea, what is a suggestion and what is back to the jobs to be done for what is really going to move the customer forward?"

"I think with any company, solving a real problem is the most important thing. So creators have lots of challenges and things that can be solved... I think at the core, every creator needs two things. They need to grow an audience and they need to get paid so that they can make a living."

"We asked ourselves, what if we could combine the uniqueness of Airbnb with the reliability that you've come to expect in a hotel? And that's what we've done with Guest Favorites... we use all the signal to create the top two million homes."

"It was a digital version of something that had come before... why use this instead of the Yellow Pages? But more than anything else, why use this instead of the Yellow Pages? It was a digital version of something that had come before."

"The original framing was one click comment... we needed a one-click comment. That's where the concept came from."

"Competing Against Luck, which was the book that produced Jobs to be Done, which is a framework I really believe in."

"Go look from the last week. For a week, just pay attention to what you do and what frustrates you. And when something frustrates you, think about, is there anything we can do? Can it be done a different way?"

"I said, there's nothing better in learning how to solve a problem than trying to solve the problem. You will get all the answers, the research, the failure, the mistakes, all the evidence. You know the difference between what people say, this is what they do."

"The first step is really generating a whole bunch of problems... You start the day with, 'Hey, let's collect everybody's thoughts on what the problems are that are holding us back.'"

"Isn't the product the homes and the apartments? Jobot said, 'Nope. Product in the tech industry is something different.'"

"Problems create categories, and you either have to A, solve a new problem, or B, reframe, name and claim an existing problem in a... very different way. And if you reframe the existing problem such that people see it in a different way, that's when they'll be open to a new solution."

"Spend more time on the problem than the solution."

"I don't know that we even talk about problems without a qualifier. Are we talking about a business problem? Are we talking about a customer problem? Are we talking about an efficiency problem? Describe the nature of the problem and parse it out."

"PMs and the teams, many times, spending a lot of time at the problem area, before they think about the solution. The solution is not the case anymore. There are so many different solutions."

"Usually a successful pivot gets warmer instead of colder from what you're an expert at and somehow builds on what you learned on the prior idea. Right? ... A good pivot is like going home. It's warmer, it's closer to something that you're an expert at."

"If you think about the higher level job to be done, I was like, 'No, the real issue is that it's super hard to find my stuff, organize my stuff, share my stuff, and secure my stuff.' In the beginning that was like my stuff was my files... Now, the stuff is tabs in my browser, and cloud tools."

"one of the mistakes I think founders make is that, especially product oriented founders, is that we fall in love with the solution instead of falling in love with the actual problem"

"Build for your best user, not your worst user... you shouldn't really be building for them. I think a really good example of this is onboarding processes... Really, you should just be building an onboarding process for the user who's going to jump into your product and get it immediately."

"Step one is the step that almost everyone misses on SEO, which is be the user. Try to understand who your user is... they had zero customer empathy for why people use the tool."

"If you can't answer the question about what is it that someone's going to do a search on, then don't do SEO because SEO is about appealing to that user."

"I and we would create frameworks for everything... we'd have really joined up considered strategy... we just love to draw diagrams so you can teach all that stuff."

"I convinced them, instead of paying three years and $18 million, so you don't make the thing, let's go take a brochure, take it to some customers... customers laughed them out of the room and it was nothing to do with anything they cared about."

"The hard part now is, now it's easy to build the thing. Now it's, 'What the hell should we build? Can we clearly articulate what it is we want to build?' And then, 'Can we just have the taste to know, is this right, is this correct?'"

"The best exercise for a conscientious person especially to feel more open is to become obsessed with reverse engineering... to truly understand the inputs that generate that outcome."

"They also leave the problem stage out. So the world that customers are living in prior to discovering you, which is a really critical, that context is unbelievably valuable, especially for marketing. So to delete that out of the equation is a big problem."

"The best founders early on trust their engineering teams and product development teams to solve problems and more clearly present a problem to them and help them... Why should we build an iOS app, while the actual problem to solve is we want to increase the percentage of people using a service to five times a week versus two times a week."

"Start with some kind of data analysis to ground what you should even test... you should start with some kind of data analysis to ground what you should even test."

"Focus more on the product description, focus more on what do you want the end user to experience? What do you want the product to do? And try to be open-minded about how well the tool can implement it."

"You can't actually ask them how difficult is it to do X, y, z because they won't even know that it's that difficult to them. So the best thing I've learned about how to discover the pain is to watch people, have them screen share, have them walk you through their daily workflow."

"How you can prioritize a list of ideas against a pain point... how to look through what's an acute pain point and what's a wide range of people use, how we'd expect data in order to be used in order to validate this."

"It's really working backwards from the customer problem from what we're trying to solve, and then realize what are the best tools that we have in order to do that work better and think through that landscape versus, oh, AI is here, we have to use it."

"This idea of getting unstuck and turning maybe some abstract ideas or some concepts that you've been discussing, turning that into a concrete prototype, something that you can look at and you can click around and you can actually try. It works in a lot of different contexts."

"The first phase, the basics, as I mentioned, that's identifying who's your customer, what problem are you solving for the customer?"

"I think that problem can be really interesting because when teams sit down and think about it, it is often less clear than they thought what the actual problem is."

"I look at the underlying incentives of the customer. And the underlying incentives of customers are not always financial. Sometimes it's ego, sometimes it's career growth. If you're selling enterprise software to someone, there's an executive sponsor as an example, that person needs to trust that you're going to do a good job for them."

"We ordered just a bunch of food from these places, and we got a restaurant supplier to give us a base catalog, and we just matched up how much does the ham weigh? How much does the cheese weigh? How much does the bread weigh?... we tried to actually just compose our own independent view of what's the ingredients cost versus what's the labor cost?"

"Understanding and defining what problem matters is the most important skill that I think I've taken away, and it applies to so many things. It can apply to a specific product we're building. It can apply to what a company's mission is. I think I've found it really effective because it affects pretty much everything."

"Go and see. Right? So to look at the thing and then walk all the way to ground and talk with the engineer who's writing the code on the thing. Because inevitably this top-level communication is insufficient to get to the detail of what matters and doesn't matter."

"The person with the product thing has to get into those same weeds first to really understand it... what's the point of writing a document if you don't know what you're talking about?"

"we're going to be focused on users and people in the real world and their problems. And the first step is to understand their problems and then understand if there's an opportunity here as opposed to, 'Hey, you want to build X thing for Y person.' So that's the biggest mistake that you really have to unteach and retrain thinking around."

"There's the people like Teresa Torres and others that have come up with a technique that is universal. You can teach an element of product thinking with her techniques or this opportunity solution tree or this continuous discovery thing that everyone can find accessible no matter where your company is at."

"The most important feedback I would say is focus on identifying the problem and making it really clear for the other person, the person you're giving feedback to, what is the problem... instead of actually stating the reason, we go straight to the solution."

"I was not a fan of how we leveraged jobs-to-be-done at Twitter. I thought it was exhausting and not particularly helpful... every framework at its limit is followed to such a religious extent it's just unhelpful. You need to have nuance in how you leverage these frameworks."

"I ask myself and my key reportees every month, we go around the table and ask ourselves, ”What are the hardest problems we solved last month?”... If you're a senior, what is the role of a senior person? You have to be the chief problem solver."

"the behavioral diagnosis, I'd say, it's like a journey map on steroids where you're really trying to map the steps that get people to the behavior change... we'll do a deck of 200, 300 slides of screenshots where it's just very detailed analysis of the steps that it takes to get to the behavior change."

"When you're doing PLG and we're shifting from sales to PLG, we need to reset. We need to recognize that, again, this is sales, sales via the product. What does a good sales rep do when they're engaging? They understand what the problem is of the person in the space they're talking to."

"There is something called the shiny object trap, and I'm always telling people, "Hey, don't do AI for the sake of doing AI." Make sure there is a problem there. Make sure there is a pain point that needs to be solved in a smart way."

"It helps me create user segments in a fantastic way. It will think of user segments that your mind wouldn't even go there, it just wouldn't go there. And it will provide the motivations, it will provide the pinpoints and you just come up with ideas as you read it."

"I usually say that the generalist PM helps their team and their company build and ship the right product. But the AI PM helps their team or company solve the right problem."

"People don't buy the problem, they buy your solution. Obviously they don't buy it if it's not solving something they care about, but there are many products that are solving what they care about. The real question is, do you solve it better than everybody else so that they buy you? And that's where you need to take time. So this is more like the coaching I give the teams. I tell them, "Look, be careful. If you need to spend a little time on the problem, fine, but don't spend a lot of time because you need to save as much time as possible to come up with the winning solution.""

"In a real product team, first of all, instead of being given a roadmap of prioritized features, they're given problems to solve. So it might be a customer problem. It could be a company problem, it's all fair, but they're problems to solve."

"And a product team, an empowered product team, instead of being given a roadmap of features, they're given problems to solve. Now they're customer problems or they're business problems or both, but they're given a problem to solve."

"If people don't understand the problem then they can't understand or care about your solution. And so there was a lot of refinement on the way it was articulated."

"Cursor kind of started as a solution search of a problem... It felt like the people that were working on the space maybe had a disconnect with us, and it felt like they weren't being sufficiently ambitious about where everything was going to go in the future, and how all of software creation was going to blow through these models."

"We want to solve problems for desperate people... if a customer has the ability to do something other than what you do to solve their problem, they won't be crazy enough to do business with a startup."

"The mandate wasn't like, 'Hey, we need to upgrade our data infrastructure...' It was much more just like, 'Please help us accomplish this mission. This is the big thing.'"

"They hired a Pixar illustrator to illustrate each scene as the team's like, okay, okay, they said this is her name. And they were like, okay, what happens? Her alarm goes off... They realized from this little walk in the shoes of their customer just this day in the life... that they needed to move as soon as possible to a mobile first strategy."

"How extreme can you take it? You're designing a product. You're trying to come up with a solution. What's the most outrageous version of this along some trait? ... The biggest risk is you didn't see the right choice to begin with. You have these three choices and none of them were right. It's this fourth one that was over in this corner, but you didn't look in that corner."

"You have to look at things from an angle that other people might not have seen and for me, and for us, it's the angle of where are the emotional hooks that you're experiencing as you go through your work day... Paul Graham has a word for this. He calls it schlep blindness."

"Starting with what is your problem or what is your goal? I would say this is a bigger challenge than most people recognize or realize. 80% of the folks that I work with, this is their biggest problem. Even at executive levels, teams will have gone off for several months, and they're tackling something, and they'll come back with uncertainty, and they'll say like, "Well, you told me to improve developer experience.""

"Look for latent demand where people are trying to obtain a particular value and going through a very distortive process. If you can actually crystallize what their motivation is, you can have this kind of intense adoption."

"The problem space and the solutions to the problems space is still a big driver of success in building software companies. What problem are you really solving? And if you believe that the problem space is key, so what problems will predict success?"

"Pick a problem that is materially felt by your customers, pain points that steal their time, their energy, their money, their focus, the inability to afford their leisure. If you can solve those kinds of problems... it's a huge tailwind."

"For us with Jobs to be Done, it was a really good way of us centering on the customer problem, focusing on not getting distracted, basing it in good solid research informed insight, that told us the thing people are trying to do."

"The way that I like to frame it to people is that you're a consultant that has a particular predilection for a given solution... ideally, through a series of questions, I'm going to reveal that to them that they're doing it probably not great. And then once I've revealed to them the fact, through this directed questioning, what's known as discovery, that they have this high magnitude problem..."

"I still did not exactly understand what we were going to build, which was confusing, because I was a product manager... At some point, it was like, "Okay, I have to ask. What exactly are we," like, In the details, right? Not in describing a big problem, in a high level, big potential approach to solving it, but what exactly are we doing here?"

"All strategy is problem solving. It's a form of dealing with challenges... you're diagnosing the situation. You're trying to figure out what's going on here. What's the nature of reality that you're dealing with?"

"The crux in a climb is the hardest part... In business, the crux is the hardest part of the problem. And from the design point of view... there's usually a challenge... by focusing on the difficulty, we see a way around it."

"I think a lot about this job to be done framework... you have to really be a student of causation. Why is someone using this product? What are they doing with it and what are they trying to get done with it?"

"I used to write like a problem journal. Like just when things annoyed me or when things were like less efficient, I would write it down as like a note. And I didn't try to solve it. I didn't- didn't say, 'Oh, here's the solution.' I was just like, 'This is annoying.'"

"The first thing is we are not going to start something unless we can see the end from the beginning. We’re not going to take a big concept and then say, 'What’s the estimate for this thing?'"

"We narrowed it down to we understand that for our specific customers who are requesting this again and again, it’s more about I need to see empty spaces and in the existing agenda view, I can only see things that are already scheduled and I can’t see free spaces where I could book something. So, we got to that point of what we’re trying to solve here is the empty spaces. So, that’s a good frame."

"The PM moves upstream... less busy with, 'How do I get this project to not be in a bad state when it’s getting built?' And they’re way more in, 'How do I understand the business context? How do I narrow down the problem? How do I negotiate back and forth with maybe the CPO who brought this to me to understand where the core of it is?'"

"Empathy is not about kindness and empathy is not an option. This is something that you are making for other people. So the whole idea of RTFM, read the manual, I'm angry at you. If you're saying that to your customers, you made a mistake, they did not make a mistake."

"The eigenquestion, the simplest definition of eigenquestion, it's the question that when answered also answers the most subsequent questions... Rank them by which ones would eliminate the most other questions of the list."

"I say that my love languages are spreadsheets and frameworks. And one very simple one... is what we call MECE, mutually exclusive, collectively exhausted set of things."

"If people could get over the idea of reducing friction as a number of goal or reducing the number of clicks or taps to do something, and instead focus on how can I make this simple? How do I prevent people from having to think in order to use my software?"

"If your software stops me a second and asks me to make a decision and I don't really understand it, you make me feel stupid. ... if you're causing people to think, in the best case, it's unnecessary use of their biological resources, and in the worst case you've now made them feel bad, emotionally bad."

"I hate Jobs-to-be-Done, I think it is a terrible framework, I think no successful company has ever been built on top of JTBD and if you pick JTBD, you're probably doomed"

"The problem with that is it's just too idealistic. And most frameworks are, but this one just takes it up a notch where it's like it's almost meant for people who are so naive about product building and especially product building at scale."

"I think that the heart of good product is really getting comfortable in the problem space or the opportunity space, really taking the time to frame a problem well, and to really get into what's needed before we jump to solutions."

"As you move vertically down the tree, your opportunities are getting smaller and smaller, which is really key to helping us unlock a continuous cadence... we can deconstruct it. Maybe I can't find something to watch because I don't know if this show's any good... Now we're getting into an opportunity that we can actually solve."

"You've got the persona, the problem, the promise, and the product. Lattice kept the first one but changed the others. Vanta changed all four."

"Fall in love, fall in love, fall in love, fall in love with the problem, and then actually what you're trying to do is engage everyone else to fall in love with the same problem, to go into this journey, into this path and follow your leadership there."

"When you fall in love with the problem, then what happened is that the problem is going to serve as the North Star of your journey, and when you have a North Star, you're going to make less deviation from the course and you are way more likely to become successful."

"And what I really encourage people is first of all, go and validate the problem, speak with people, understand their perception of the problem. And only then start to think about the solution... when you focus on the problem, then the problem is going to serve as the north star of your journey. And when you have a north star, you're going to make less deviation from the course and increase the likelihood of being successful."

"A customer is asking for a feature, but then you would say, okay, why are they asking for it, and back up the problem. But I think there's one more step you can take, which is, why do they have that problem in the first place? And maybe there's something there, and that could be an opportunity to make a bigger product impact by fixing that underlying condition that created the problem in the first place."

"What matters a ton is actually figuring out what are the new markets, the new pockets of demand that are changing very quickly where the wealthiest customers in the world are willing to pay whatever it takes to improve model capabilities, and how do we focus on the leading indicators of those markets"

"What you actually need to find is the customer that's surprisingly easy to sell into where you're going to be able to grow with them. You know that it's a large pain point."

"I like art applied to problem solving because I think that design is often... There is some component of creativity to it and unique expression that you're trying to provide and create and put out into the world. But you are also trying to do it and match it to a user need, a problem that needs to be solved. And I think that it's not pure art, but if you lose the art and you're just solving the problem, it's totally utilitarian and it lacks soul."

"They really care about, to zoom out, they care about three things. They care about quality first and foremost... And then, the other huge problems you have is volume... And then, the other thing I would say model builders care about is speed."

"the tactical thing that I almost make every PM on my team do I call it top 10 things you should know. It's a living document... 10 problems you should know. And you revise it. Every quarter you update it and they're separate. So it's like a living set of problems. And they could be qualitative, they could be quantitative, they could be tech debt."

"I'll sometimes bring them in at the beginning of the strategy session and give them a template, 10 things you should know. So you use my framework to give me 10 problems. Because if you say, 'Come present,' they'll do like 50 slides. No, that's just 10 things you should know and stack rank them."

"I often go into a project, everyone's operating at a PhD level, I'm coming in at a kindergarten level... identifying the most basic building blocks of a complex problem and then unfolding, or revealing or building on top of them additional complexity and details as you go along."

"The Double Diamond Process... forces people to get out of their opinion-driven lens... You go broad when you ask like, 'What customer should I solve for?' and then you pick one... Then, you go broad, and you say, 'What are the problems this customer has?' and you narrow, and you say, 'This is the problem they have.'"

"Sometimes your product actually doesn't matter... at Uber, I learned this because, really, the price and the ETA at Uber was the product. Looking at it from a holistic perspective, we humans consume the entirety of the product."

"The first thing is empathizing. You've got to really feel the pain of your customers... the define is also a really powerful word because it forces you to articulate what the problem is."

"The way that we often describe it is, I think, Devin is best when it is working on tasks that are well-defined. One way to put it is, you want to be giving Devin tasks, not problems."

"You have to derive it from first principles. You have to say, 'How would we solve this problem given every fundamental building block that we have available right now?'... everything that you encounter, that every solution, every product, everything that exists is path-dependent, highly, highly, highly path-dependent, and often path-dependent based on having to make compromises, based on things that were true at the time a decision was made but are no longer true."

"The amazing thing about software is we can actually just overtake this piece of complexity. We know what the taxes are everywhere and we are just doing it for you. You don't have to think about taxes. In this case we have someone encountered something that stunned them, that stopped them in their tracks... lowering complexity, making good UX, creating software that just autopilots taxes or payments or any of these kinds of things, fraud, actually causes more entrepreneurship."

"We have a product process that we follow, which starts with a P-strat, which is a strategy, and then we go into P0, which is definition of the problem, then we go into P1, which is definition of the solution, and then we go into P2, which is once the solution is shipped, are we hitting the metrics."

"We have a process called friction logging. Put yourself in a user's shoes."

"Really think hard and tap into a very deep pain point."