We’re breaking down the story behind Nvidia’s unofficial motto and lessons from three Nvidia stories Jensen shared in an inspiring commencement speech last year. There are some wise words here. Ready? Let’s dive in!

Lesson one: Be humble and ask for help

One of Jensen’s early jobs was as a dishwasher at Denny’s. He often starts his story with these humble beginnings and hard work rather than mentioning that he was also a brilliant engineer and Stanford graduate. He said he considered himself successful until he started Nvidia.

“I was also successful until I started Nvidia. At Nvidia I experienced failures, great big ones, all humiliating and embarrassing. Many nearly doomed us. Let me tell you three Nvidia stories that define us today.”

— Jensen Huang (Source: NTU commencement speech)

That’s from Jensen’s commencement speech at National Taiwan University last year. And here’s the first of the three stories he shared:

In the 1990s, Nvidia won a contract with SEGA to build their next-generation console, the SEGA Dreamcast. At the time, Nvidia used quadrilateral-based graphics, shapes with four points, because it was cheaper to build and looked better. Their competitors were using triangles, shapes with three points, which required more expensive hardware but made developing software and rendering cheaper and faster.

Two-dimensional triangles can easily be combined to make three-dimensional shapes. That’s why everything looks like a Tesla Cybertruck in classic video games. Modern devices can support millions of triangles on a single screen, but each triangle has three simple points, floating points, with coordinates that are quick and easy to change. This would become very important for AI years later, but we’ll get to that.

The trouble with quadrilaterals, Nvidia’s approach, is that four points can exist on multiple planes, creating complex shapes like a pyramid. Now, imagine moving millions of those shapes onto a screen, which uses pixels, and your brain breaking is what’s called rendering. 🤯

Quadrilateral-based shapes could not be rendered as fast as triangles could. In the end, faster was better than better. At the time of this realization, Microsoft announced it would only support triangle-based development in Windows 95, a death sentence for Nvidia’s entire business. Nvidia’s new NV1 chip and their next-generation NV2 chip, which was still in development, were obsolete before they could even hit store shelves. RIP, NV2.

Jensen would need to abandon quadrilateral graphics, do a 180, and create an entirely new chip based on triangular graphics, but the company didn’t have enough money to start all over in that new direction. They were also one year into the development of the SEGA Dreamcast and really needed that money, but if they continued developing their inferior technology, their core chip business would go belly up. Both roads led to bankruptcy.

Here’s what Jensen did: He called SEGA’s CEO and explained that they couldn’t continue to build inferior technology, but if they were not paid, Nvidia would go bankrupt. To his shock, SEGA paid, and when Nvidia launched a new chip, they were only 30 days from going out of business.

The lesson: Be humble, ask for help, and always work like you’re 30 days from going out of business.

Triangles nearly destroyed Nvidia. It was painful; they had to lay off more than 50% of their workforce and almost failed. Yet this is what Nvidia’s Silicon Valley headquarters looks like. Notice anything? 🤔

Lesson two: Endure pain and suffering with glee

Jensen recently appeared on the Acquired podcast and was asked what company he would start today if he were magically 30 years old again and starting from scratch. His answer was shocking: He wouldn’t do it!

“The reason why I wouldn’t do it, and it goes back to why it’s so hard, is building a company and building Nvidia turned out to have been a million times harder than I expected it to be, any of us expected it to be. And at that time if we realized the pain and suffering and just how vulnerable you’re going to feel and the challenges that you’re going to endure, the embarrassment and the shame and the list of all the things that go wrong, I don’t think anybody would start a company. Nobody in their right mind would do it. And I think that that’s kind of the superpower of an entrepreneur, they don’t know how hard it is and they only ask themselves ‘How hard can it be?’ and to this day I trick my brain into thinking ‘How hard can it be?’”

— Jensen Huang (source: Acquired)

This reminds me of the most popular quote from Jessica Livingston’s book Founders at Work: “Determination is the single most important quality in a startup founder.” Jensen was no exception to this rule. People think of startup success as glamorous, but Jensen says you should have low expectations and embrace pain and suffering.

When he was recently asked to give advice to Stanford University students about building a successful company, his answer was: You need resilience, and that doesn’t come from intelligence; it comes from pain and suffering.

“To this day I use [the phrase] ‘pain and suffering’ inside our company with great glee. … I wish upon [you] ample doses of pain and suffering.”

— Jensen Huang (source: Stanford SIEPR keynote)

This brings us to the second Nvidia story from Jensen’s NTU commencement speech. Nvidia nearly failed because they bet big on CUDA, a platform they developed in 2006 as a revolutionary way to program on a GPU instead of a CPU. GPUs are capable of parallel computing, which would make them especially useful for breakthroughs in machine learning, data, and AI, but they needed CUDA to unlock their future potential in AI.

Focusing on CUDA was a costly gamble that didn’t pay off for years. It took the stock market nearly two decades to realize the potential of CUDA and AI. At a time when tech stocks were soaring, Nvidia’s stock performed terribly.

The lesson: Overnight successes often take years of pain and suffering.

In the background of all those years before Nvidia stock took off, innovation was happening, and it was as if the company would go bankrupt in 30 days. They were doing things that don’t scale, helping researchers write code, and even giving away AI supercomputers to non-profits. In 2016, Jensen hand-delivered the world’s first AI supercomputer in a box to a non-profit called OpenAI, and we all know how that turned out. 📈

Lesson three: Pursue your vision and retreat if you go off course

The third and final Nvidia story from Jensen’s commencement speech was about following your vision.

In 2010, Nvidia partnered with Android to build chips for mobile phones. They were an instant success. However, competition quickly grew and Nvidia would need to dedicate significant resources to succeed, but the mobile market did not fulfill their mission to build computers to solve problems that ordinary computers could not. So, they strategically retreated from a multi-billion dollar industry to work on robotics chips in a zero-billion dollar industry.

“We now have billions of dollars of automotive and robotics business and started a new industry. Retreat does not come easily to the brightest and most successful people like yourself, yet strategic retreat, sacrifice, deciding what to give up, is at the core, the very core, of success.”

— Jensen Huang (source: NTU commencement speech)

The lesson: Follow your vision and strategically retreat when you go off course.

Deciding what to give up is at the very core of success. To be strategic, you must learn to select the very few products or features that can fulfill your company’s vision and retreat from all other projects.

Nvidia’s journey is one of the most amazing success stories. Check out the full references linked below to dive deeper.

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. This self-paced training program will set a strong foundation for your product career and offers optional one-on-one sessions with me.

📺 PM Crash Course (free) is a fun, free playlist of videos that introduces the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

❤️ Develop Products People Love course on Skillshare—a beginner class on product development for entrepreneurs.

🙋🏻‍♀️ 1-on-1 coaching. For personalized coaching, book a one-on-one call with me. You can also book time with me on Skillshare!

Referenced in this post & video

• [YouTube] Commencement speech at National Taiwan University, May 2023, by TTV News

• [The New Yorker] How Jensen Huang’s Nvidia Is Powering the A.I. Revolution by Stephen Witt (November 2023)

• [The Wall Street Journal] He Built a Trillion-Dollar Company. He Wouldn’t Do It Again. by Ben Cohen (December 2023)

• [YouTube] NVIDIA CEO Jensen Huang interview by Acquired

• [YouTube] Nvidia CEO Jensen Huang and the $2 trillion company powering today's AI by 60 Minutes

• [YouTube] Keynote by NVIDIA CEO Jensen Huang at 2024 SIEPR Economic Summit by Stanford Institute for Economic Policy Research

• [YouTube] Nvidia CEO Jensen Huang full keynote at GTC 2024 by Yahoo Finance

• [YouTube] E167: Google's Woke AI disaster, Nvidia smashes earnings (again), Groq's LPU breakthrough & more by All-In Podcast

• [YouTube] How do Video Game Graphics Work? by Branch Education

• [YouTube] Why video games are made of tiny triangles by Vox

• [YouTube] Nvidia CUDA in 100 Seconds by Fireship

• [WebWire] NVIDIA CEO Delivers World’s First AI Supercomputer in a Box to OpenAI (August 2016)

• [Electronic Design] Nvidia’s RIVA 128

• [Nvidia.Developer] Life of a triangle - NVIDIA's logical pipeline

• [Nvidia] NVIDIA History and About Us

“The best way to come up with startup ideas is to ask yourself the question: what do you wish someone would make for you?”

— Paul Graham

We're breaking this down in the fun-filled video below! 👇

Two Types of Startup Ideas

Paul Graham is a co-founder of Y Combinator. In 2010, he wrote the essay, Organic Startup Ideas, breaking down two types of startups. And he says one is better than the other.

“There are two types of startup ideas: those that grow organically out of your own life, and those that you decide, from afar, are going to be necessary to some class of users other than you. Apple was the first type. Apple happened because Steve Wozniak wanted a computer. Unlike most people who wanted computers, he could design one, so he did. And since lots of other people wanted the same thing, Apple was able to sell enough of them to get the company rolling.”

— Paul Graham

The first type of startup idea is what PG calls “organic ideas.” They're the ideas that come to you organically through your own life experiences. In your own life, you experience a problem, and you decide to fix that problem. Often, the problems you have are experienced by other people, too, so other people may find value in the solution you build. If enough people care enough about the problem to seek a solution, and if those people find your solution valuable, you might have a startup on your hands.

That was the case with Apple. Steve Wozniak wanted to build a computer for himself, and lots of people were interested in buying what he created. He solved his own problem, and that was Apple's organic startup idea.

The essay makes the case that organic startup ideas are the best way to start. Ask yourself, “What do you wish someone would make for you?”

Ironically, Paul Graham points out that he made his fortunes with the second type of startup idea: a startup idea for other people. He co-founded Viaweb, which was acquired by Yahoo! and became Yahoo! Store. (And if you've seen my other PG video, Do 10 Things That Don't Scale, you know this was a big deal for the world's most important Filipino karaoke mall store. I'm talking about my family's business in the 1990s that used Yahoo! Store. 😊)

Viaweb was basically like Shopify, but way back in the day. PG wrote:

“We didn't need this software ourselves. We weren't direct marketers. We didn't even know when we started that our users were called ‘direct marketers.’”

— Paul Graham

Despite his massive success with the second type of startup idea, PG recommends that aspiring founders focus on organic ideas. He says, “the most successful startups seem to be closer to the Apple type than the Viaweb type.” He's been around thousands of startups through Y Combinator, so that's saying a lot.

Why Organic Ideas Are Better

Simply put, solving a problem for yourself is easier because you have an initial understanding of the problem. It's much harder to predict what others need and solve a problem you don't understand yourself.

“Organic ideas are generally preferable to the made up kind, but particularly so when the founders are young. It takes experience to predict what other people will want. The worst ideas we see at Y Combinator are from young founders making things they think other people will want.”

— Paul Graham

The dangerous words here are “things they think other people will want.” It's really hard to predict what other people want. We product managers know that discovery work is hard. It takes a lot of effort to uncover the problems that users actually have and care about.

Having experience helps because if you've been working on a problem space for many years, you start to recognize patterns, and you may notice opportunities where you could solve problems for other people. But figuring out what people need is still hard work.

In the footnotes of the essay, PG adds:

“[2] In retrospect, we should have become direct marketers. If I were doing Viaweb again, I'd open our own online store. If we had, we'd have understood users a lot better. I'd encourage anyone starting a startup to become one of its users, however unnatural it seems.”

— Paul Graham

I love this. It's a great example of getting closer to your customers to understand their world. At every great startup I've worked at, all the employees were encouraged to use the product themselves, and this helped us understand our users much better.

However, not everyone has time to start one business to learn how to start another, as in PG's example of opening a store. 🤪 So, focusing on solving a problem you understand deeply because you are facing it yourself can be an easier way to get started. In the essay, he gives examples of organic startup ideas like Apple and Facebook. Here are a few more examples that I really like:

• Dropbox's founder kept forgetting his USB drive, so he built a file syncing solution, solving his own problem.

• The founders of Stripe were building a bunch of side projects and were frustrated that integrating payments into their apps was so hard. They solved that problem.

• Slack started as an internal chat tool for a video game company. The game didn't make it, but the team solved their own communication problem, and that was a hit.

• AWS was Amazon's internal web services, and when they opened it to other companies, it was more profitable than all of Amazon's e-commerce sales combined for many years.

• My favorite example is Looker, where I used to work. Looker's founder, Lloyd Tabb, built his own analytics tool at three different companies, solving his own data needs before deciding to launch Looker as a company and make the solution available to everyone.

The list goes on.

Organic Ideas are Overlooked

The companies I mentioned above are huge now, and the problems they initially solved may seem obvious in retrospect. So why were the problems overlooked? Why were these founders able to swoop in when they did? PG says it's because organic startup ideas usually don't look like startup ideas at first.

“There are ideas that obvious lying around now. The reason you're overlooking them is the same reason you'd have overlooked the idea of building Facebook in 2004: organic startup ideas usually don't seem like startup ideas at first. We know now that Facebook was very successful, but put yourself back in 2004. Putting undergraduates' profiles online wouldn't have seemed like much of a startup idea. And in fact, it wasn't initially a startup idea. When Mark spoke at a YC dinner this winter he said he wasn't trying to start a company when he wrote the first version of Facebook. It was just a project. So was the Apple I when Woz first started working on it. He didn't think he was starting a company. If these guys had thought they were starting companies, they might have been tempted to do something more "serious," and that would have been a mistake.”

— Paul Graham

Great startups often look like a “toy” or a silly project at first. But all big companies started somewhere, usually as something small and crazy-sounding. So, just finding broken things and taking the time to fix them can lead to an unexpected breakthrough. The small side project could turn into a wildly successful startup if it turns out to be something lots of other people want, too.

🚨 Don't Skip Validation 🚨

Solving your own problems may be a great place to start, but this doesn't mean you can skip validation! To go from a project to a viable company, you need to find a market for your solution, and usually, that means you need to make pivots and iterations to turn your initial idea into something that people are willing to buy.

In this essay, PG's not saying, hey, since you like the product you built, everyone will like it, too! No, far from it. You are not your end customer, and there's still a lot of work to be done to align your project with your customer's ideal product. So, how do you do it? Well, that is for another PG essay.

But you can check out my video on The Lean Startup or my new course on Skillshare (links below!) next.

You got this!

📚 Build that skill 📚

If you have an organic startup idea and are not sure how to turn it into a product, check out my new course, Develop Products People Love, on Skillshare. It's a beginner class on product development for entrepreneurs. If you're not a Skillshare member yet, use my referral link above for one month free! (where available)

The class is just under one hour, so you can take my class and other great classes on Skillshare in your one free month. I hope to see you there!

📚 📚 📚 📚 📚

If you're looking for more product management lessons, here's how I can help!

📚 Product Management Foundations course. This self-paced training program will set a strong foundation for your product career and offers optional one-on-one sessions with me.

📺 PM Crash Course (free). This is our free email-based crash course. For seven days, you'll receive one email a day, each introducing a core concept of product management. You'll learn the basics in just one week! (Fun videos included, of course!)

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

❤️ Develop Products People Love course on Skillshare. A beginner class on product development for entrepreneurs.

🙋🏻‍♀️ 1-on-1 coaching. For personalized coaching, book a one-on-one call with me. You can also book time with me on Skillshare!

Kahneman is a legend in the field of psychology and won the 2002 Nobel Prize in Economic Sciences for his work on decision-making. Thinking, Fast and Slow is his most famous book, and it's massive (almost 500 pages!), so I won't try to summarize the whole thing here, but let's talk about the most popular quote, which has 50,000 highlights on Kindle. (That's a lot!)

Here's the quote:

"This is the essence of intuitive heuristics: when faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution."

— Daniel Kahneman

Confused? 🤔 No worries, I was too, so let's break this down.

You know what intuition is, like when a doctor sees a patient and immediately knows what's wrong, even if they can't articulate how they knew. It sometimes feels like magic, but it’s not.

"Intuition is nothing more and nothing less than recognition."

— Herbert Simon (quoted by Daniel Kahneman)

Intuition is a form of fast thinking based on a lot of past information and experience. We only call it intuition when people are likely correct.

Heuristics is also fast thinking, but it's more of a mental shortcut we use when we don't have enough information and past information to make a decision that's likely right. This is where things get tricky because if we can't articulate why we did something, it's hard to know if our decisions are based on intuition and likely to be correct or if it's heuristic, and our brain just jumped to a conclusion that might be very, very wrong. Are we full of experience or something else? This is where we all, even the most intelligent people, run into problems.

Here’s an example: You've heard of recency bias, also known as an availability heuristic—it leads us to make decisions based on how available or recent the information is in our heads. That's why ads work. You might not even remember seeing an ad or realize you're hungry, but suddenly, you feel like a Snickers bar because of that availability heuristic.

Heuristics manifest biased decisions, good or bad. In the book, Kahneman tells the story of asking a Chief Investment Officer why he invested in Ford, and the executive replies that he recently went to an automobile show, and "Boy, do they know how to make a car!" This is also an example of another heuristic, the affect heuristic, where the executive based his decision on his feeling of liking Ford rather than reasoning about the value of the stock—big mistake. Knowing the actual value of stock requires a lot more information.

"The question that the executive faced (should I invest in Ford stock?) was difficult, but the answer to an easier and related question (do I like Ford cars?) came readily to his mind and determined his choice. This is the essence of intuitive heuristics: when faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution."

— Daniel Kahneman

In the example above, the executive answered an easier question (the heuristic question) instead of the original, more challenging question (the target question). The heuristic question was easier to answer because he could apply a heuristic to it, and his brain could quickly arrive at an answer using fast thinking.

This example might sound silly. When I first read it, I thought, “What a bad investor! I'd never make a dumb decision like that!” but then I realized I've definitely made this same mistake when deciding what features to invest in as a product manager. Have you ever been asked a hard question like, should my team invest in building this feature? (the target question) and subconsciously answered a heuristic question instead: how excited am I about this feature? 😬 I'm willing to bet we all have made this error at some point in our product careers. 😅

What's fascinating about this substitution process is that people don't notice when they make these substitutions and, as a result, are confident in their decisions. We don't notice that we've answered a different question, and we might not even recognize that the target question was difficult because our minds quickly came to an answer.

“People are not aware that it happens and it is a source of many intuitions that don't come from expertise and they are much less likely to be correct than the intuitions that do come from expertise but they come with equal confidence.”

— Daniel Kahneman (from a talk at Google in 2011)

This is an important concept for anyone to know, especially people who have to make lots of decisions at work, like product managers. We need to make important decisions every day. We're often the final decision-maker for our products, and we constantly deal with ambiguity, so decision-making is often hard. To excel in our jobs, it's critical to know how to make good decisions and to understand the ways that our minds might trick us into making poor decisions.

So, are you facing difficult questions or answering easier ones instead? Here are some things you can do to improve your decision-making:

• When faced with a difficult decision, stop to ask yourself if you're answering the target question.

• Be rigorous in your product discovery methods to validate the problems and solutions you work on.

• Practice dealing with ambiguity and collecting evidence to help you make hard decisions.

• Ask colleagues for feedback when making important decisions to check your thinking.

You got this!

If you're looking for more product management lessons, here's how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. It is self-paced and includes optional one-on-one sessions with me.

📺 PM Crash Course (free) is a fun, free playlist of videos that introduces the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

❤️ Develop Products People Love course on Skillshare—a beginner class on product development for entrepreneurs.

🙋🏻‍♀️ 1-on-1 coaching. For personalized coaching, book a one-on-one call with me. You can also book time with me on Skillshare!

Referenced in this post:

• Thinking, Fast and Slow by Daniel Kahneman (Book)

• Thinking, Fast and Slow | Daniel Kahneman | Talks at Google (YouTube)

Today, Copart is the world’s largest online auto auction site, selling more than 3 million vehicles annually. The company is incredibly successful, with impressive tech and decades of massive and sustainable growth, so it’s mind-blowing to find out that Copart was founded in the 1980s as a junkyard. What??!?! 🤯

This is a fascinating story with so many great business lessons for product people. So we’re breaking it down, as told by Copart’s founder, Willis Johnson, in his book Junk to Gold.

Here are ten big lessons we can learn from Copart’s founder, Willis Johnson.

Lesson 1: Unwavering determination

The most popular highlight from the book is this:

“He taught me that you have to do your research and that if you don’t stay on top of reading about other people’s ideas, you never come up with ideas yourself. It’s good to learn from others.” - Willis Johnson

Willis is talking about his father here, and what’s amazing is that his father didn’t know how to read. Willis’s mother would read him the newspaper each morning, and his father would find opportunities to make money as an entrepreneur. Yeah, you heard that right.

Willis is a billionaire businessman now, but unlike many billionaires, he didn’t get money from his parents to start his enterprises. Willis’ father didn’t have money to give him, but he gave him something better: determination. That’s lesson one, have unwavering determination. He never stopped.

Lesson 2: Specialize

When Willis returned from Vietnam, he got a loan for a junkyard lot, which included a small building, basically a shed, where he’d live with his new family. When he started the business, he struggled to compete with other junkyards, so here’s what he did:

“At the time Chrysler, Dodge, and Plymouth were not cars dismantlers wanted to have because they weren't hot-selling items. So we made a decision to specialize in Chrysler, Dodge, and Plymouth. All the other dismantlers thought I was crazy.” - Willis Johnson

He went from selling $3,500 of junk—car parts—a month to $3,500 per day. Niches too small for big business can be big business for little startups to specialize in. Specialization helped Willis find an initial market that he could serve and excel in.

Lesson 3: Struggle to make the customer not struggle

A theme in the book is Willis’ relentless focus on his customers. Here’s a great example of how he put customer needs first:

At the time, junkyards would sell an entire engine outside as a whole package. This made things easier for the junkyard operators but harder for customers to find specific parts. Putting the customer first, Willis decided to do things differently. He pulled out all the parts, cleaned them, and sold parts individually indoors. This was like the Apple store of junkyards. It was more work for him, but it improved the customer experience.

Lesson 4: Let me find that for you

Junkyards were like treasure hunts. There were parts from thousands of car makes and models, different years, condition of parts, and missing parts. People just searched and hoped they’d find the parts they needed because junkyards hold an incredibly complex inventory.

So, Willis became one of the first businesses to computerize inventory.

“I spent $110,000 on a large reel-to-reel computer—about double the amount most people spent on a house at the time… [Other junkyards] thought I was crazy (or stupid–or maybe both)...” - Willis Johnson

But it was magic for customers to have instant access to parts from all over California. As Willis expanded, he had a mesh network of shared data, the power of data analytics, and you know what that is. It’s gold. The more data, the more gold. Junk to gold.

Lesson 5: Open source for progress

Willis started selling so many cars that the DMV ran out of car title books. Not good. Plus, the whole process of handwritten title paperwork created a nightmare of problems for his customers and his business.

“I spent about $40,000 building the computerized system for the state of California. Now we could go to the computer and fill out all the paperwork needed and didn't have to wait for books. It sped up the whole process and was an example of how it pays to fix something yourself instead of waiting for someone else to solve the problem for you.” - Willis Johnson

Willis decided to fix the problem for everyone by building the solution himself.

Ok, ok, technically, this isn’t open source because I don’t think he made the code freely available to everyone. Still, he provided a solution that benefited everyone in California, so it’s the same spirit. The point is that he didn’t wait around for someone else to fix his problems, and he was willing to make a solution available to everyone rather than hoarding the benefits for just his company. He doesn’t complain about problems; he just fixes them and makes the whole industry better as a result.

Lesson 6: Be your customer’s most valuable partner

“Be your customer’s most valuable partner.” - Willis Johnson

When Willis started auctioning junked cars for insurance companies, he knew they were losing money. They (the insurance companies, who were his customers) didn’t want to pay full price to shine up junk cars. So, instead of charging them fees, he proposed a partnership: He would take a small commission on cars they sold, with no upfront costs.

Throughout the book, he constantly finds ways to make every process more efficient and make his customers more money. Again, there’s that hyper-focus on customers. He knew that when your customer wins, you win, too.

Lesson 7: Continuous improvement

By 1998, Copart upgraded to a nationwide computer system called CAS (Copart Auction Systems). But people were still bidding in person, and you needed to be a licensed rep to bid, so people (his customers) were waiting around all day and had to pay reps $150 just to bid on cars. The process was ridiculous.

So, Jay, Willis’s son-in-law and now Copart’s CEO, asked customers, Hey, what if you could bid online? They all told him, No thanks, that’s a dumb idea. (Not a direct quote; we’re just telling a story here.)

There’s a product lesson here, don’t ask customers if they would use technology they don’t understand. It’s easier for them to tell you “No” than to admit they don’t know.

So Jay walked them through the process: first look at the cars, now instead of paying that dude $150 and waiting all day, you bid on this computer for $35 and go home.

That brings us to the next lesson…

Lesson 8: Do things that don’t scale

Walking each customer through the process was time-consuming, but sometimes, you need a concierge service to show buyers how to buy. Jay was doing things that didn’t scale, and it paid off. Customers started to use Copart’s new online bidding service, and word spread. They made $1 million in sales in their first quarter online.

However, Jay noticed someone from out of state had bought a car, and he was shocked because every customer he spoke with told him they would never buy a car without seeing it first. So he called the guy from out-of-state to ask about his experience, and the guy said, Yeah, I know what I’m doing, so I don’t need to see the car, but yeah, some pictures would be nice.

So Copart added pictures to the online auction, and suddenly, they were doing $10 million in sales from bids worldwide.

Lesson 9: Cannibalize gracefully

Just adding “gracefully” here to make the word cannibalize sound nicer. 😜

Copart’s online bidding became so popular that it started cannibalizing the company’s in-person auctions. Things got really messy when they introduced live bidding, where people could instantly bid against each other.

Just imagine a live auction with an auctioneer pushing up the bids while a computer moves even faster, instantly ticking up the price. It’s just too much. You can’t mix the rapid mumbling of an auctioneer with computers; that’s a recipe for chaos. Willis’ employees were ready to quit.

So, they set up computer kiosks at a few locations and showed people how to bid online, to convert in-person auctions to fully online auctions. Once they tested it on a small scale, doing things that don’t scale, they rolled it out to more locations. People loved it and naturally taught others how to do it. More people bid, and insurance companies made more and more money. And I don’t know about you, but that’s what I live for, making insurance companies more money.

They would then slowly roll the idea out to more yards. Slowly, Copart became the global leader in online vehicle auctions, selling over 175,000 vehicles daily. They are incredibly successful, the Nvidia of Junk.

Lesson 10: Losers focus on competition

I left out that this was a rivalry story, and Copart was the underdog. However, their much larger competitor, IAA, was focused on things like revenue and the number of auction sites—we call those vanity metrics. They were constantly trying to sabotage Copart’s acquisition of junkyards.

But Copart didn’t focus on short-term revenue. They were concerned about continuous improvement for their customers and employees. Willis believed that if he took care of his employees, especially the talent from new acquisitions, they would, in turn, take better care of customers.

Junk to Gold is a great book, and there are so many more business lessons I didn’t get to cover here.

Copart won because losers focus on the competition, and winners focus on the customer.

You got this.

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. It is self-paced and includes optional one-on-one sessions with me.

📺 PM Crash Course (free) is a fun, free playlist of videos that introduces you to the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

❤️ Develop Products People Love course on Skillshare. A beginner class on product development for entrepreneurs.

🙋🏻‍♀️ 1-on-1 coaching. For personalized coaching, book a one-on-one call with me. You can also book time with me on Skillshare!

But as product managers, we don’t need to come up with all the solution ideas on our own; in fact, that’d be a bad move. Ideas will come from lots of places, and we need to be open to ideas from our teammates, stakeholders, and customers. Our job is to sift through the many, many ideas to find the good ideas that are worth pursuing and throw out the bad ideas.

In this super short, fun video, Mando and I will walk through some common places where you can find great ideas. Stick around after the video for more tips!

First of all, let’s revisit what a product manager’s job is. I like to explain it like this:

A product manager figures out what their team should build with limited time and resources and does whatever it takes to make their product great.

To figure out what your team should build, first, you need to find the right user problem to solve and then the right solution to that problem. This process of figuring out what to build is called product discovery. There’s a lot to it, which we’ve talked about in this post, so today, we’re covering where ideas come from—the sources of inspiration that can fuel your discovery work.

Here are four common places you’ll find ideas:

1. Your cross-functional team

I’m talking about your closest partners, the engineers, designers, and any other folks who are dedicated to the same product area as you. Maybe you call them your “pod” or “squad,” but whatever the name, the point is that these folks are committed to the success of the same product area as you. You’re all experts in that space, and you're continuously working to improve it for your users and the business.

Your partners are probably thinking about the problems in your product area as much as you are, so naturally, they will have great ideas that you should tap into. Listen closely for ideas that teammates mention during team meetings, retrospectives, and casual conversations, and keep track of them.

2. Organized idea-generating events

There are lots of formal ways that companies and teams generate ideas. Here are a few:

• Brainstorm sessions. These are events where you use one of the many brainstorming frameworks to generate ideas as a team. They are great to hold during the roadmap planning process or when kicking off a new project to come up with solution ideas as a group. This post from Miro includes tips on how to run a successful brainstorming session and provides templates for different brainstorming techniques.

• Design Sprints are a highly structured method used by teams to go from a big problem to tested prototypes in just five days. They’re a great way to generate and validate ideas fast. Check out the book Sprint to learn how to run one.

• Hackathons. Lots of companies host hackathons, where employees do rapid, collaborative engineering for a short amount of time, usually a couple of days. This is a great way for technical teams to try out creative solutions. As a product manager, you can look out for hackathon projects that align with your product strategy as ideas to explore further.

• 20% time programs. Some companies encourage individuals to pursue topics of interest for a fraction of their work time. If your company has a program like this, you can check out what folks are working on and collaborate with them on ideas that fit your strategy.

3. Your business partners

Colleagues from other parts of your company (think Sales, Marketing, Customer Support, Operations, etc.) can offer new and different perspectives on the business and customer needs. This can be a great source of inspiration, and you should spend lots of time with your partners across the business to learn from them.

Many of them will have plenty of ideas that they’d love for you to add to your roadmap. It can get overwhelming, though, if colleagues are cornering you in the hallway and office kitchen to share their thoughts. You’re just trying to grab an afternoon snack, but Sally has a great feature idea she wants you to hear!

To keep things organized and easy on yourself, you can ask each department to have a representative from their team organize a prioritized list of their team’s ideas. Meet with their representative once or twice each quarter to hear them out and discuss their ideas. They’ll be happy you took the time to listen, and you’ll walk away with lots of idea inspiration.

4. Your customers

When you talk to customers during product discovery work, you typically want to focus on them — understanding their world and learning about their problems. (We want to explore the problem space!) But customers have solution ideas, too, and they’ll share these with you in the form of feature requests. They’ll suggest specific features and functionality that they believe will solve their problems.

Feature requests can be a great source for ideas, but you have to make sure you understand the problem that the customer thinks their request will solve to ensure it’s realistic and aligned with your own strategy and objectives. I like to ask, “If we built this feature, what would it help you achieve?” This way, I can get to the root problem that the customer is asking us to solve and find the right solution, which might be their idea or something entirely different.

So many ideas; what do I do now?

Ideas and inspiration for ideas come from all over the place. I like to keep track of all the ideas I hear and review the list often. Having a list of ideas comes in super handy during planning and roadmapping because I’m never starting from scratch.

I like to use a simple spreadsheet to log ideas. For each idea in the list, I keep track of:

1. The idea itself, usually a short description of the feature

2. The user problem this idea aims to solve

3. The expected impact I think the idea could have

4. Impacted customers — who are the users who have the problem and could benefit from this solution idea?

5. Any validation or supporting evidence we have around the idea

6. Who suggested the idea (who/where did the idea come from?)

If you liked this post and want to learn more about solution ideas, discovery, and delivery, check out my online course, Product Management Foundations. We cover designing and validating solutions and so much more.

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. It is self-paced and offers optional one-on-one sessions with me.

📺 PM Crash Course (free) is a fun, free playlist of videos that introduces the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

❤️ Develop Products People Love course on Skillshare. A beginner class on product development for entrepreneurs.

🙋🏻‍♀️ 1-on-1 coaching. For personalized coaching, book a one-on-one call with me. You can also book time with me on Skillshare!

Most articles about the history of product management will tell you that the role originated in the 1930s at Proctor & Gamble, but the need for product managers goes way further back than that. Some version of product management has been around for as long as humans have been trying to figure out the right thing to build for customers. To understand the origins of this job, we need to go way way back. So grab some popcorn and enjoy our historical reenactment of the origins of modern-day product management. 🍿🎥

When we started piecing together the evolution of the modern product manager, it became clear that communication was at the core of it all. Each new technology era brought new communication challenges. Builders and customers grew further apart, and the knowledge gaps within companies increased as technology advanced. And every time this happened, someone would point out that a bridge was missing and that someone needed to connect customer needs to business capabilities.

Neil H. McElroy called it out in 1931 with his famous “Brand Men” memo. The Agile Manifesto made the same point in 2001 in the Internet age, and we saw footage of a frustrated Steve Jobs in 1986 asking, “Whose job is it??”

Someone must be the glue, holding it all together and communicating across business units and with customers. In each era, those people were the product managers, whether or not they had the official title.

Let’s see how the role evolved over time.

Blacksmith product managers

To understand the origins of product management and why the role exists in the first place, we took it back to a simpler time, to 1500 B.C. (though arguably the AI-generated background was more like 1300 A.D.; this was a low-budget documentary 😜) and the product managers who we imagine worked in the blacksmith trade back in the day.

Ok, so the story about Edward and Sir John is fictional. The point is that people have been building products and selling stuff to customers throughout human history. So there’s always been someone who converted user needs and business goals into a plan of action for the builders to build the stuff to sell.

I like to use a simple definition when I describe what product managers do. In a nutshell:

Product managers figure out what their team should build with limited time and resources, and they do whatever it takes to make their product great.

If we think about the role like this, with all the tech-industry jargon removed, then, yeah, people have been doing this job since the beginning of trade and commerce.

We saw Blacksmith PM and PM2 both take on this role. They were both under a time crunch to interpret the customers’ needs, communicate those needs back to the technologists, and deliver products to their customers on time, and that would be of value to both the customer and the business. PM2 was more skilled in what we now call discovery and delivery techniques, so his team produced a superior product.

Figuring out the right thing to build was easier back then because communication was easier. People only made a single custom product at a time for a customer they knew deeply, with technology that was generally understood by the entire team, and the results of their labor had clear results, which the whole village understood.

Industrialization breaks product management

If we jump forward centuries to industrialization, problems arise. You see companies start to produce thousands of products for customers they’ve never met, sold by salespeople they don’t know, built by people they’ve never talked to. Communication was easy when goods were produced in small quantities by hand, but that easy communication was lost as the world shifted to mass production by machines.

This was the exact problem in my product lesson on toothpaste before Dr. Sheffield added the mint and satisfaction. Toothpaste was mass-produced in jars as a chalky powder that the whole family shared. It was nasty and unpopular. But history ripples: you see the same problem today, with many products that leave you wondering, “Does anyone want this? Did they talk to a single user before making thousands of these?”

Why did PM2 succeed in product management? He effectively communicated his customers’ needs and translated all of the inter-departmental knowledge required to make the best product for the customer.

The problem is that technology expands our customer reach and, therefore, reduces our customer communication. Technology expands our knowledge but also widens the knowledge gaps between teams, reducing communication within an organization.

That is why the need for product management will grow as technology advances continue to distance us from the customer and increase the knowledge gaps between team members. This theme will continue to ripple in history.

1931 Brand Men

That brings us to the book Product Leadership by Richard Banfield, Martin Eriksson, and Nate Walkingshaw, which gives a fantastic overview of modern-day product management and inspired this post and video. The authors of the book state and everyone agrees, that modern product management comes from a memo written in 1931 at P&G. Neil H. McElroy wrote the 800-word memo that outlined the need for “brand men,” or what would become known as a product manager.

McElroy was frustrated while advertising Camay soap at P&G. He couldn’t figure out why the brand was losing to P&G’s flagship soap, Ivory. It was the same communication problem that formed in all mass production.

You had the expansion of all these manufacturing roles, yet nobody knew why the customers at “local stores” weren’t buying Camay. Somebody needed to go “personally to the consumer” and ask, what is it about Ivory soap that’s better? Is it the smell? The texture? The text on the package?

You had executives busy managing multiple products, but who was entirely responsible for Camay? Nobody. This wasn’t about “criticizing” Camay soap. It was about learning everything about the brand and taking responsibility. “Experiment” with every team involved and follow the entire production process with sales “right to the very finish.” Get to the local stores and talk to customers “in order to find out the trouble.”

The memo is so good. It instills that someone must be responsible for communicating the voice of the customer throughout the entire production process, all while working with and communicating with various teams so they can focus on their jobs.

Camay became an iconic top-selling soap brand—I think it’s dead now; product management is hard—and Procter & Gamble moved beyond soap to become one of the most successful, longest-lasting companies in the history of the world.

1943-1993 HP PMs

McElroy later helped found a small startup called NASA, and he also advised two young men at Stanford named Bill Hewlett and David Packard. Their company, HP, went on to sustain 50 years of unbroken 20% year-over-year growth between 1943 and 1993. In this period, the world faced WW2, multiple recessions, and stagflation in the 1970s, and yet, according to the book The Hewlett-Packard Way, putting brand men as close as possible to the customer to make the product manager the voice of the customer, led HP to succeed while the rest of the world was in turmoil.

HP divided product groups into small self-sustaining organizations that developed, manufactured, and marketed products in one cohesive unit. Tiny teams = big communication. If a team had over 500 people, they would split it. These smaller, tighter units allowed specific products to be developed faster for a specific customer.

1948-1975 Toyota & Lean PM

Around this same time period, Toyota was perfecting its own version of this called Lean Manufacturing, where a chief engineer, a shusa, took on the role of the product manager to take full responsibility for a car with a small dedicated team.

Toyota took it a step further and looked at reducing all forms of waste in the production process, including physical waste from defective parts and any waste in the process.

Whereas the brand men were instructed to “experiment with and recommend wrapper revisions,” the Toyota shusa was explicitly instructed to identify any waste that “does not generate value for customers” and immediately experiment with ways to solve tiny problems before they turn into millions of issues for customers. Toyota’s principles transformed not only the standards of the car industry (cars were unreliable in the 1980s) but also improved manufacturing standards across industries. This is also the basis for The Lean Startup, which we’ll get to soon.

Through brand management and lean manufacturing, product management practices continued to develop around physical products in established markets, with tons of acronyms you’d learn in business school. But a new technology revolution would present new challenges. Communication problems expanded exponentially with technological advances, and the world was about to embark on a new technology era.

1980s Steve Jobs asks for a PM

The 1980s introduced the personal computer era, but it wasn’t like adding mint to chalky toothpaste or making an established product slightly more reliable. It was a whole new ball game.

You couldn’t study your brand history, as the brand men were instructed to do because it didn’t exist. You couldn’t talk to current customers because you didn’t even know who your customer was. Heck, you don’t even know the technology your team is capable of because they were literally inventing the future in their minds. The personal computer era would present the need for a new era of brand men.

In the video, we see this struggle play out in 1986, with a frustrated Steve Jobs and the team at NeXT.

“… so somebody's got to say here's what we can do and we can make it happen and here's the level of thing we can ship in 16 months…”

That was Steve Jobs talking about the need for… a product manager! They couldn’t name the role at the time, but the team knew something was missing.

The PBS documentary is fascinating. It shows the team’s struggle to launch the next generation of computers, and blame gets aimed at Marketing, Sales, or Engineering. They need someone to communicate with everyone, “This is what we are building, here’s our priorities, and here’s our deadline.”

1984 Microsoft’s first PM

In the 1980s and 90’s, the role of product manager began to emerge with different names, other than “it’s not my job” or it “should be his job.” After all, someone must manage the product, whether the company makes it an official title or not.

Microsoft originally called the job Program Manager. In the book One Strategy, Jabe Blumenthal described how it happened:

“In early 1984, we began to work on a spread sheet for the Mac. I got involved and became a sort of service organization for the development group. I helped document the specifications, do the manual reviews, and decide what bug fixes were important and what could be postponed to a later release. While I didn't make the design decisions, I made sure that they got made. The process worked out really well, so they decided to call it something and institutionalize it.®”

Microsoft called it Program Manager, a job title that blurred the lines between project, program, and product manager over the decades to follow. Today, Microsoft also has product managers, but the lines between all of these jobs are blurred depending on the company you are at. So, it’s difficult to say who the first product manager was because the role carries many names. But whatever you call it, someone was doing the job.

1990s PMs

Then came the Internet, marking the beginning of the next era of technology and a new era of product manager, with the official title of “product manager” emerging around 1999. The history is murky, but you have examples like Kate Arnold, the first product manager at Netflix in 1999.

Then you have Marissa Mayer, Google’s first female engineer in 1999, who took on product manager roles and became the first product manager at Google in 2001.

Just a year later, in 2002, Mayer started the Associate Product Manager program at Google, a pivotal moment for the product manager profession in many ways. It was a shift away from brand men marketers to an engineering necessity. The waterfall method was over, where a boss would write a long list of specs, toss it over to engineering to build, and hope their customers enjoy their toothpaste or Windows 2000 CD-ROM. The Internet was here, and it was not static. Could you imagine if Google stopped their algorithm updates in 2000? No, software updates were being released rapidly to millions of customers. Once again, technological advances increased communication problems exponentially until they broke the system.

2001 & The Agile Manifesto

So, in 2001, 17 software engineers got together in a ski resort and wrote the Agile Manifesto. They took what they had learned from Scrum, DSDM, XP, and the learnings from Toyota to pen this manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As we saw with the brand men memo in 1931, with technology moving us further away from the customer, we had to refocus on customer collaboration. Things were moving too fast. It wasn’t that a plan was no longer necessary; it was that responding to change became more important.

Engineers could no longer follow orders from a boss who didn’t understand their technology. To truly innovate in this fast-paced technology era, engineering and product would need to work together to experiment and learn about their customer’s needs before they build their final product. Remember, they were no longer building a better computer; they were building new technology for entirely new markets. They had to learn who their customer was before shipping their final product.

Agile created a harmonious atmosphere of collaboration, where product and engineering no longer fight, and customers are now delivered perfect products. (Sometimes… 😜)

2011 The Lean Startup

The Lean Startup built upon all of this in 2011. It focused the entire company, not just a product, on learning what the customer wants through rapid experimentation, shorter sprints, continuous improvement, communication, and customer focus—history ripples.

2024, Product Managers Today

As technology has increased our distance from customers, the number of product managers on LinkedIn has grown to over a million.

We now have Chief Product Officers, a name far above the title “it should be your job.”

You can now attend Carnegie Mellon for a Master of Science in Product Management.

Now, some people say AI will kill product management, but I say product management is the last job that will connect the human experience to technology. AI will help create millions of new products, product managers will need to manage those, and when AI can do that, it’s game over for humans anyways. 🤷🏻‍♀️

And there’s a really important reason that product managers will be the last job on earth, and that is this: I sell product manager courses at the Academy of Product Management. I’m bullish on PMs having a long future ahead. 😉

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. This is a self-paced course with optional 1-on-1 sessions with me.

📺 PM Crash Course (free). A fun, free playlist of videos to introduce you to the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

🙋🏻‍♀️ 1-on-1 coaching. Book a 1-on-1 call with me for personalized coaching. You can also book time with me on Skillshare!

Referenced in this post:

• Product Leadership by Richard Banfield, Martin Eriksson, Nate Walkingshaw (O’Reilly)

• The history and evolution of product management by Martin Eriksson (Mind the Product)

• PDF of Neil McElroy's 1931 Brand Man Memo (Wikimedia Commons)

• Great Moments In Branding: Neil McElroy Memo by Derrick Daye (Branding Strategy Insider)

• Entrepreneurs, 1986 PBS documentary featuring NeXT and Steve Jobs (IMDB)

• One Strategy: Organization, Planning, and Decision Making by Steven Sinofsky and Marco Iansiti

• When they hired their first PM by Lenny Rachitsky (Lenny’s Newsletter)

• Lean Startup in 13 Hot Takes (Academy of PM)

This, my friends, is what I call the ✨ Shiny Pivot. ✨  And Stanley has perfected it. Watch the video below to see how they did it.

The shiny pivot at Stanley is the work of Terence Reilly. He’s now the president of Stanley and was the former CMO of Crocs, where we see his first attempts at a shiny pivot. Reilly brought his experience from the sneaker industry to Crocs, where he used the tactics of celebrity collaborations and limited edition runs to connect the Crocs brand with a new market. It was a shiny pivot that shocked the world, or at least it shocked me. I remember thinking, “What?? Crocs are back?? How did this happen?” Terence Reilly and the Shiny Pivot — that’s how.

So when Reilly joined Stanley, he brought the same expertise to the Stanley product. Stanley cups were already iconic and well-known by construction workers and outdoorsy types. My husband, a former firefighter, knew Stanley from their TV commercials in the 80s and 90s, where they’d toss a Stanley thermos off the top of a skyscraper construction site, and the bottle would survive the fall without a dent. It’s a solid product line, but its durability made it challenging to grow the business. Consumers don’t need to buy another Stanley bottle because the one they have will last a lifetime. So, how could Stanley grow and reach new markets? The answer — a Shiny Pivot.

A ✨ Shiny Pivot ✨ has two components:

One: Make it shiny! Make the product shiny, cool, photogenic. Do this physically with tangible products. If your product is digital, you can find a way to give the product a cool factor. Remember when Slack launched, and the UI was cool? It was like playing a game while all other office communications tools were boring and corporate-like. It was shiny.

Two: Find your natural influencers. Crocs kicked off a collaboration with an up-and-coming Post Malone, who was already sporting Crocs. Stanley collaborated with a small group of bloggers in Utah who loved their product. You don’t need to collaborate with a massive celebrity. If the product is shiny enough, your early adopters will naturally share it. They’ll be excited to share it. Those natural, authentic influencers are the ones you want to collaborate with.

That’s the ✨ Shiny Pivot ✨ in a nutshell. It’s for products with core functionality that is rock-solid, but you need to make it shine to attract new users, maybe a new market or a new generation.

Anyone know how we can get the ✨ Shiny Pivot ✨ added to the Lean Startup pivot list? 😉

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. This is a self-paced course with optional 1-on-1 sessions with me.

📺 PM Crash Course (free). A fun, free playlist of videos to introduce you to the basics of product management.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

🙋🏻‍♀️ 1-on-1 coaching. Book a 1-on-1 call with me for personalized coaching. You can also book time with me on Skillshare!

Referenced in this post:

• How to Reinvent a Consumer Brand, HBR IdeaCast Episode 927

1999: Internet, Shminternet.

2024: AI, Schmay-I.

History repeats itself, and it feels like we’re having very similar conversations today about AI. Like the Internet in the 90s, recent advances in generative AI are truly changing the world. And everyone is feeling the pressure to adopt AI or become irrelevant. It feels like every single product I interact with now has some fancy-schmancy new AI features, and while many of them are awesome and game-changing, most leave wondering, “Does anyone actually need this??”

It’s so refreshing to see Bezos-of-the-past standing his ground that obsessing over the customer experience is more important than chasing the latest technology trends.

You can compare Amazon’s success over the past two decades to the countless “pure internet plays” that died in the early 2000s to see where we’re going here. Companies that chase technology trends without focusing on their customers, won’t stand the test of time. The internet in the 90s and AI today are tools to solve problems, but to have a sustainable business, your product needs to solve a real problem that customers care about.

The Internet was a huge part of Amazon.com’s solution, because the Internet was the right technology for the right solution to a real problem that customers cared about.

In Jeff Bezos’ first public shareholder letter in 1997, he wrote:

But this is Day 1 for the Internet and, if we execute well, for Amazon.com. Today, online commerce saves customers money and precious time. Tomorrow, through personalization, online commerce will accelerate the very process of discovery. Amazon.com uses the Internet to create real value for its customers and, by doing so, hopes to create an enduring franchise, even in established and large markets.

— Isaacson, Walter; Bezos, Jeff. Invent and Wander: The Collected Writings of Jeff Bezos, With an Introduction by Walter Isaacson (p. 31).

The Internet was not the focus, and even though Bezos acknowledges that it was “Day 1” for the Internet, he was focused on the long term, not just the hot new tech of the moment.

Obviously, the Internet and AI are revolutionary technologies. It’s Day 1 for AI, and we’d be silly to ignore it. Being on the first wave of a new technology can be incredibly profitable, and let’s be honest, it’s fun and makes you look cool. 😎 But when we’re building our products and want to throw in some AI features, we have to pause and ask, is AI necessary here? Is it the right technology for the right solution to a real problem?

Lots of product managers and entrepreneurs make the mistake of jumping to solutions. Don’t do it. Always start with the customer and their problem. (Check out my video about exploring the problem space if you’re not sure where to start! 🪐🌌🧑‍🚀)

This quote from Bezos’ 1999 shareholder letter (the same year as the interview clip above) hits home on this topic. You can see his obsessive focus on the customer. Even invention is “on their behalf.”

Our vision is to use this platform to build Earth’s most customer-centric company, a place where customers can come to find and discover anything and everything they might want to buy online. We won’t do so alone but together with what will be thousands of partners of all sizes. We’ll listen to customers, invent on their behalf, and personalize the store for each of them, all while working hard to continue to earn their trust.

— Isaacson, Walter; Bezos, Jeff. Invent and Wander: The Collected Writings of Jeff Bezos, With an Introduction by Walter Isaacson (p. 47).

So, lean into the cool, new tech, but don’t lose sight of who you are building for. Start with the customer and obsess over their problems to build lasting products.

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📺 PM Crash Course (free). A fun, free playlist of videos to introduce you to the basics of product management.

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. This is a self-paced course with optional 1-on-1 sessions with me.

📖 Product Influence course. Learn simple influence principles and frameworks to take your product career to the next level.

🙋🏻‍♀️ 1-on-1 coaching. Book a 1-on-1 call with me for personalized coaching. You can also book time with me on Skillshare!

Referenced in this post:

• Jeff Bezos In 1999 On Amazon's Plans Before The Dotcom Crash by CNBC on YouTube

• Invent and Wander: The Collected Writings of Jeff Bezos, by Walter Isaacson, Jeff Bezos

But first, watch the video!

Atomic Habits is a masterclass on building good habits and breaking bad ones. Before we connect the dots to Product, let’s understand how habits work in the first place.

The Loop

Habits exist to give our brains a break. Habits are actions we take nearly automatically because we’ve done them enough times that our brains can act on auto-pilot, and you don’t need to think much to complete the task. Habit science tells us that there are four steps to building a habit:

1. Cue

2. Craving

3. Response

4. Reward

It’s all subconscious; your brain is constantly searching for cues. For example, in nature, the sound of a river would cue your thirst (craving), you’d respond by finding the river, and your reward is that your thirst is quenched. Your brain associates the reward with the cue, creating a loop, the habit loop, and if you go through this loop enough times, the whole thing becomes automatic, and you’ve just developed a habit.

If you’ve worked in tech, specifically building products, for the last ten years, this loop probably looks familiar to you. Nir Eyal published his best-selling book, Hooked: How to Build Habit-Forming Products, in 2013. It was a sensation. I remember attending a Hooked workshop back in the day and the fan-girl moment I had when Eyal stayed after the session to answer students’ questions, and I got to ask him in person about building habit loops into my own product. 🤩

Eyal did such an amazing job teaching us product builders about habits that he followed up his own work with a second book, Indistractable, to teach us how to disconnect from the habit-forming products we’ve built. (P.S. The loop in the Hooked Model is a bit different from James Clear’s version that we’re focusing on here.)

So, you already know that product managers need to understand habits to build great products. What’s so special about Atomic Habits? James Clear shares a whole framework of practical steps you can take to improve your habits. It’s an incredible resource for anyone trying to improve how they work and live. And I think three big ideas from the book are particularly helpful for product people: compounding, identity, and environment.

1. All the small things

The main idea in Atomic Habits is that small (atomic, get it?) changes that you make consistently compound over time, leading to massive wins. We often think that to achieve big things, we need to make big, heroic moves, but most of the time, the small, consistent habits we commit to make the biggest difference.

“Habits are the compound interest of self-improvement.” – James Clear

If you improve by just 1% every day for a year, you’ll be nearly 37 times better at that thing by the end of the year. 🤯 And this works in reverse, too. Bad habits lead to big declines.

Dave Brailsford took over the British cycling team in 2003 when they were a disaster. In a century of riding, the team had just a single Olympic gold medal. Jump forward to the 2008 Olympics, and they won 7 gold medals, 70% of all of them. How’d they do it? As the team’s performance director, Brailsford focused on 1% improvements everywhere. From the spandex to checking for dust on bicycles to personalized pillows to help riders get the best sleep. They even hired a surgeon to teach the riders how to wash their hands to reduce their risk of getting a cold by a smidge. Small improvements over time set them on a trajectory for success.

James Clear uses this story to encourage us to focus on small improvements over time and our trajectory rather than our current position. With good habits, time becomes your ally.

I’ve always been a “go big or go home” type of person, so I did not appreciate this phenomenon until recently. Now that I’ve been working long enough, I can look back on my own career and find evidence of small, consistent habits paying off massively. The trouble is you can’t see the change right away. It’s too small. You need time to work its magic.

Like when I committed to hosting a weekly presentation at work. At first, public speaking terrified me, literally putting me into a panic every Tuesday morning before my presentation, but I did it every week for two years. Next thing you know, I’m a two-time keynote speaker on-stage in front of a thousand-person audience.

Or how I blocked off study time every Friday afternoon to research technical concepts I didn’t know. I went from knowing nothing about infrastructure to being a confident platform product lead in a super technical area. In both cases, the commitment to small improvements over time set my career on a trajectory for success.

Scrum teams get it. The Scrum process forces teams to pause at the end of every two-week sprint to hold a retrospective meeting. We ask ourselves, what worked and what didn’t? And we commit to small improvements to our process, communication, and team work habits to get a little bit better in the next sprint.

What about your product? What 1% improvement can you make with every release? Can you fix small, annoying bugs or remove bits of friction? What if you add small features to increase delight for your users? These improvements compound over time for a great user experience.

This is the premise of Atomic Habits: tiny changes that seem insignificant, 1% improvements, compound over time to achieve remarkable success. Or failure if your habits are bad ones.

As product managers, there are plenty of ways we can use small, consistent habits to up our game. Here are a few ideas to get you started!

• Spend a few minutes observing the products you use every day and reflect on what’s great and not great about the product’s design. This will strengthen your product sense. (Use my worksheet to help!)

• Spend 15 minutes exploring your product data every day to become data-fluent.

• Write every day to become a clear communicator.

• Schedule a customer interview every week to increase your customer empathy.

• End every 1-on-1 meeting with the question, “What can I do to help you?” to build stronger relationships with your colleagues and grow your influence.

2. Habits ↔️ Identity

Habits shape your identity and vice versa.

“The true reason that habits matter is that every action you take is like a vote for the type of person you wish to become.” – James Clear (Source: YouTube)

In humans, you need to establish an identity first to become the type of person you wish to be. According to Clear, it’s easy-peasy. As he writes in the book:

“It’s a simple two-step process:

1. Decide the type of person you want to be.

2. Prove it to yourself with small wins.”

So, if you want to be a writer, start saying, “I am a writer,” and you’ll naturally be more inclined to write every day because that’s what writers (you!) do.

It’s a simple yet powerful concept. It means you can transform yourself with these small actions. Because the small actions build up the proof you need to believe in your new identity, and the new identity fuels the behavior you want to develop. Pretty cool!

My husband and I used this tactic about five months ago when we realized we needed to improve our health. We kicked off a health quest by deciding, “We are healthy, fit people!” Then we proved it to ourselves with small daily wins: eating vegetables every day, standing at our desks while we work, taking our hyper-active golden retriever on not one, but two walks every day because that’s what healthy, fit people would do. I’ve lost twenty pounds, and Jeremy lost forty. By establishing that identity, we became the type of people we wanted to be.

Ok, ok, Sondra, good for you, but how does this apply to product management???

We’re getting there. 😉

With products, your product vision is that identity; it’s the type of product you want to be. And you prove it to your customers with small wins over time – you build the features that get you to that 3- to 5-year vision.

The best product companies take their identity a step further; they have a user-centric identity. They say, “We put our users first,” and they mean it.

When I was at Looker, “Love Looker Love” was a core company value. It meant our customers love us, and we love them. It was part of our identity and culture that our customers’ success is our success. This customer-centric identity helped make the company super successful, just like it did with Slack. You can check out my video for more on Slack and their customer wall of love.

If you identify as a company that puts your customers first, you’ll develop customer-first habits, like you’ll actually listen to your users. Every company says they listen to their users, but companies with a user-centric identity prove it with the atomic habit of listening over and over again.

And when you listen to your users, you’ll build things they actually need, and then they’ll buy those things because they need them, and they’re delighted that you listened. You win because they win.

When I consult with startups, I always ask, are you listening to customers? Yes is always the answer, but the team’s daily, even weekly, actions often tell a different story.

The real reason habits matter is that every action you take is a vote for the type of person or company you wish to be. So, do you identify as a customer-centric company? Do you take those actions that prove that? Because people will love you if you do, or you can be like my cable company and just say you’re listening.

The four laws of behavior change

Establishing your identity is step one, but to make habits stick, James Clear shares a framework for optimizing every step of the habit loop. He calls it the Four Laws of Behavior Change. There’s a law for each step of the habit loop, with practical tactics that enable good habits, while the inverse of each law can be used to break bad habits. Here it is in a nutshell:

To create good habits:

• The 1st law (Cue) → Make it obvious.

• The 2nd law (Craving) → Make it attractive.

• The 3rd law (Response) → Make it easy.

• The 4th law (Reward) → Make it satisfying.

In reverse, it looks like this:

To break a bad habit:

• Inversion of the 1st law (Cue) → Make it invisible.

• Inversion of the 2nd law (Craving) → Make it unattractive.

• Inversion of the 3rd law (Response) → Make it difficult.

• Inversion of the 4th law (Reward) → Make it unsatisfying.

The book goes into great detail for each law, making each one super actionable so you can start creating good habits and breaking bad ones today. I have personally used most of the tactics in my health quest, so I highly recommend checking out the book for all the details. But back to product management, there is one more idea I want to leave you with.

3. Your environment matters

Don’t underestimate the power environment has on how people behave or the products they use.

Your environment is a critical factor in the habit loop. In Clear’s Four Laws of Behavior Change framework, the tactics behind the first (Make it obvious) and third (Make it easy) laws are largely about designing your environment.

B = f(P,E)

A person’s behavior is a function of the person in their environment. Yay, science!

The habit loop starts with a cue, so make that cue an obvious and visible part of the environment to cue desired behaviors more often.

Habits don’t exist with the actual action, the response, so priming the environment to make those actions as easy as possible will make the response more likely.

An ideal environment will subconsciously trigger an easy response that leads to success.

For product leaders, this means we should design environments that make desired behaviors from our team obvious and easy. To achieve that customer-centric identity we talked about earlier, you need to design a customer-centric environment where it is dead simple to talk to customers. Here are some ideas to get you started:

• Build feedback loops into your product directly so users can continuously tell you how they feel about your product, and send that feedback out in an automated report to your team.

• Schedule weekly user interviews to get regular feedback on things you’re building.

• Ask the customer-facing teams in your company for a brain dump on what they’re hearing from customers. Better yet, can you get them to CC their automated reports to your team?

• Add “What have we learned from users this week?” to your weekly product team meeting agenda to peer pressure all the PMs to actually talk to users.

Design an environment where customer empathy is inescapable.

And remember, the real reason habits matter is that every action you take is a vote for the type of person or company you wish to be. If you want a product that is successful with customers, your company's environment must be centered around the customer, and you should be able to show the actions you took this week to prove you are a customer-centric product team.

Check out Atomic Habits by James Clear for more.

You got this!

If you’re looking for more product management lessons, here’s how I can help!

📚 Product Management Foundations course. My 9-week training program will set a strong foundation for your product career. This is a self-paced course with optional 1-on-1 sessions with me.

📺 PM Crash Course (free). A fun, free playlist of videos to introduce you to the basics of product management.

📖 Product Influence course (free). Learn simple influence principles and frameworks to take your product career to the next level.

🙋🏻‍♀️ 1-on-1 coaching. Book a 1-on-1 call with me for personalized coaching. You can also book time with me on Skillshare!

I’m so excited to announce the launch of my new course, Product Management Foundations, and share a sneak peek of my favorite lesson from the course. It’s a horror story with a happy ending. The lesson is linked below.

For more about the course and the 50% discount, scroll to the end of this post, but first, let’s learn stuff.

The Lesson: Get obsessed with your users

This lesson comes from week four of my course, which is focused on Identifying Opportunities. “Identifying opportunities” is a fancy way of saying, “figure out the right problem to solve.” Figuring out the right problem to solve is half of the process that we Product people like to call discovery: before we build things, we need to make sure that we’re solving the right problem and building the right solution to that problem. 

Many product teams skip this entirely – they dive into a solution without figuring out if they are focusing on the right problem. We have cool tech or a brilliant idea, so we go build that tech/idea without talking to users—big mistake.

I made this mistake myself, and this is my story: You can find and watch the full lesson here.

P.S. Don't worry; the sad story I told in this lesson has a happy ending. In Week 5 of the course, we learn about Designing and Validating Solutions, and I share how I turned this failed feature into a big success that got me promoted. 😉 

The Product Management Foundations course

Real talk: it’s embarrassing to tell this story, but I think it’s important to share my struggles in this job to help you avoid making the mistakes I made. I developed this course, Product Management Foundations, because it’s the curriculum I wish existed for me when I was a new PM and for my team when I was a busy manager struggling to train my direct reports. 

The nine-week program covers all the fundamentals a new product manager needs to be confident in the role; plus, I share so many pro tips (lessons learned the hard way!) to help any PM level up. You can check out the full curriculum here. 

I designed the course to fit into any PM’s busy schedule. It’s less than one hour of content per week, and each week builds on the previous lessons.

The course has three options:

• Standard: This is the do-it-yourself option. You can go through the course at your own pace. 

• Pro & Pro+ : If you want personalized help, these two options include 1-on-1 sessions with me! In our 1-on-1 sessions, we can review the course material and work on specific PM skills you’d like to develop, or I can provide mentorship on a particular project you’re working on IRL.

I’m offering 50% off the Pro and Pro+ tiers for a limited time. Just use the coupon code YOUGOTTHIS at checkout to claim the discount. The code is valid for one week only (expires Jan 20, 2024), and space is limited! So check it out now or book an intro call to learn more.

I’m so excited to offer this program. I would be honored to be part of your journey as you build the foundation of your product management career. 

You got this!

Thank you for subscribing and watching!! When we launched this Substack newsletter and our YouTube channel earlier this year, I was pretty nervous (maybe it’s too much fun??) 😅 but now, we are having a blast turning big tech and business ideas into fun little videos. I’m so glad you’re enjoying them too!

We have so many things planned for 2024: more videos, more big lessons, more fun. We will help you kick off 2024 STRONG 💪 with even more great content and not one but TWO new courses launching early next year. Stay tuned. I’m so excited to share it all with you. 

Till then, I’m re-sharing two of our best videos from 2023. Check them out in case you missed them, or re-watch them to close out the year with some good vibes and motivation. 😎

Erase Imposter Syndrome

Imposter syndrome is common among product people because we’re doing things that haven’t been done before. In this video and guide, I share the research-backed steps I took to manage my own imposter syndrome, and we highlight many super successful people who suffer from imposter syndrome, too. This might be the motivation you need going into 2024. You got this. 

Do 10 Things that Don’t Scale - Paul Graham

Our breakdown of Paul Graham’s famous essay has been a hit on YouTube. Whether you’re a startup founder or a product manager launching a new feature, you need to do things that don’t scale to get your first users and feedback so that you can make your product the best it can be. Watch the video for inspiration to get you going.

And finally, a word from the real star of our videos, our Chief Dog Officer, Mando. Happy New Year!! 🎉

More ways to connect with me

📚 I’m launching a new course on January 8th, 2024! Product Management Foundations is a 9-week training program for new product managers. There’s a DIY option and packages that include 1-on-1 training sessions with me! I’m so excited to share this with you. You can pre-order here. 

🙋🏻‍♀️ I’m a teacher on Skillshare! Book a Skillshare 1-on-1 training call with me, and look out for a new Skillshare course from me coming in early 2024. 

Then, in 2011, I got my hands on The Lean Startup and realized I had been doing it all wrong. My whole perspective on launching products and businesses was forever changed. This book has shaped a generation of product people. 

If you read it ten years ago, like me, and want a refresher, I got you. Here is our super short summary of The Lean Startup, one of the greatest business books ever written. Enjoy!

More ways to connect with me

📚 I’m launching a new course in January 2024! Product Management Foundations is a 9-week training program for new product managers. There’s a DIY option and packages that include 1-on-1 training sessions with me! I’m so excited to share this with you. You can pre-order here. (Why not use what’s left of that 2023 training budget? 😉 )

🙋🏻‍♀️ You can also find me on Skillshare! Book a 1-on-1 training call with me on Skillshare here and look out for a Skillshare course by me coming early next year. 

Referenced in this video:

• The Lean Startup by Eric Ries (Amazon)

• Reflections on a movement | Eric Ries (creator of the Lean Startup methodology) - Lenny’s Podcast (YouTube)

• The Lean Startup | Eric Ries - Talks at Google (YouTube)

• Lean Startup Lessons For Founders with Eric Ries & Ben Casnocha - Village Global (YouTube)

• Eric Ries: Building a Startup for Long Term Success - J.P. Morgan Tech Trends (YouTube)

• Snoop Dogg on Speechify

Your PRDs are part of your legacy as a product manager. Love them or hate them, Product Requirements Documents (aka PRDs) are a big part of a product manager’s life. We use PRDs to describe the problem that needs to be solved and how our team will solve it. Everyone in your company will look to your PRDs to understand what your team is building, and years from now, your future colleagues will dig up these docs to learn about past features. 

Unfortunately, most new product managers don’t get any training on how to write a PRD well. As a new PM, you probably got assigned a problem to solve (or a feature to launch 😛), and someone told you to write a PRD. They probably sent you a link to a PRD template and expected you to figure it out from there. That’s how I got started, and 10+ years later, I’m here to share PRD lessons I’ve learned the hard way. 

Today, we’re talking about five critical mistakes product managers make when writing PRDs and how to avoid them; then, I’ll walk you through my process for writing great PRDs and (bonus!) I’ll share my PRD template with you.

Five ways PRDs fail (and what to do instead)

Mistake #1: Your customer problem is a solution

A product manager’s job is to figure out what problems are most important to solve for your users, so in every PRD, you need to describe what user problem you’re setting out to solve. A big mistake I see PMs make is describing the customer problem in some variation of “our app can’t do X,” where “X” is a feature the product doesn’t have. You’ve just described a solution, not the problem.

We include a description of the user problem in our PRDs to paint a picture of the user’s world so that everyone involved with designing the solution has the context of the pain we’re trying to fix. When you describe the problem as “our app can’t do X,” you’re missing the opportunity to help everyone understand your user’s world. 

What to do instead:

The customer's problem should be from their point of view, not yours. Instead of describing what your product can’t do right now, explain why users want it – what will it help them achieve? What pain point will it fix for them? Your PRD should paint a vivid picture of who the user is and the problem they are facing.

Mistake #2: You don’t have success metrics

Success metrics are the quantifiable measurements you’ll use to determine whether your feature was successful. They are your goals. Every feature you launch should have a goal. We’re running a business here, after all. Failing to define the goals upfront is a big PRD mistake. Without success metrics, your team won’t know what you’re aiming for, and worse, after you’ve launched the feature, you may disagree on whether or not it was a success. 

I learned this lesson the hard way. As an associate product manager, my product area was new user onboarding, and I was responsible for the product’s user activation metrics. One of my early features improved the user activation rate (a higher percentage of new users were activating their accounts) but negatively impacted average spend per user (new users were spending less on the platform). So, was this feature a success? Unfortunately, I didn’t define what success should look like upfront, so everyone argued about it. 

What to do instead:

Your PRD should define the metrics and measurements you’ll use to determine if you’ve successfully solved the problem. Consider what success will look like, and describe in your PRD how you will know if we've solved the user problem. How you define success will vary depending on your business, strategy, team goals, and other factors. Success could be determined by the adoption and usage of the feature or how your feature impacts other business metrics. Most importantly, make sure you will be able to track the metrics you’ve defined. 

Mistake #3: You’ve given too many details, stifling creativity

This is a rookie mistake that a lot of product managers make. They put too much detail into their PRDs, making the requirements too prescriptive. This backs their team into a corner where only a single solution is possible, killing creativity. Here’s another video to explain this problem.

@academyofpmAmateur Vs. Pro Product Managers Write PRDs #productmanager #productmanagement

Tiktok failed to load.

Enable 3rd party cookies or use another browser

The example I gave in the video above is pretty simplistic. Not using the words “can push a button to…” in your user stories can definitely give your team more space to be creative with their solution ideas, but here’s another less obvious example:

Recently, I wrote a PRD for a startup team. The company faced a big user problem: their customers were overwhelmed by their product. The product keeps track of a user’s activities on their computer to help them understand how they spend their time. Users typically had hundreds of recorded activities at the end of the day, leaving them overwhelmed trying to make sense of it all. 

Many people at the company already had a solution in mind; they wanted to use data science to cluster similar activities together so that users would have a smaller, less overwhelming set of things to review at the end of each day. My task was to write a PRD for this clustering feature, but as I started writing, I realized we were leaving other solution options on the table. If I narrowed in on “clustering” from the start, the PRD would be too prescriptive and could stifle other creative solutions. 

So I took a step back. Instead of naming the PRD “Activity Clusters,” I called it “Activity Aggregation.” The requirement was to find ways to “aggregate” (not “cluster”) similar activities to reduce overwhelm. I stopped using the word “cluster” and deliberately talked to the team about “aggregation.” Why? Because clustering is a specific data science method, a specific solution, I wanted everyone to step back and think about alternative solutions, especially any that might be easier and faster to implement. Ultimately, the team designed and tested two solutions. Clustering was one solution. The second solution was a simple filter on the activity list to give users a sense of control. Clustering would take some time to refine and get right, but filters were easy to build, so we could immediately deliver value to users. The language used in the PRD and our team meetings made all the difference; it opened the team up to additional creative possibilities. 

What to do instead:

Be careful with the language you use to describe the requirements in your PRD. Focus on the user’s problem and what’s required to solve that problem. Even if you have a solution in mind, resist the urge to describe a specific solution in too much detail. Try to describe the requirements as generically as possible so that your team can think creatively about solution options.

Mistake #4: You didn’t define the scope

Great PRDs include boundaries– they tell the team what is in scope (what must be part of the solution) and what is out of scope (what they should skip). Without boundaries, your team won’t know where to focus and could get bogged down in unimportant details. As the product manager, it’s your job to describe in the PRD what is most important to your user and the business so that your team can stay focused on the most important things. 

What to do instead:

You need to prioritize. Tell the team which requirements are most important so they can focus on those first in the limited time you all have to build a solution. I like to break up requirements into three buckets: 

1. Must haves - these are use cases that the chosen solution must address. They are the most essential requirements for our users and our business.

2. Nice to haves - these are requirements that we’re willing to live without. We want our team to focus on building the “Must haves” first and only work on these if they have the time to spare.

3. Out of scope - these are use cases that we have explicitly decided we will not solve now. 

To determine how to bucket your requirements, go back to your success metrics and consider the minimum requirements to achieve success as you’ve defined. Those requirements are your “must-haves.” Anything else is either “nice to have” or “out of scope.”

Mistake #5: You left out the why

The last PRD mistake we’ll cover is a big one – leaving out the why will leave your team unmotivated. Businesses don’t exist to build technology for technology’s sake. You need to explain why it’s vital for your team to work on solving the user problem. Without a strong rationale, you likely won’t get approval to start work in the first place, and even if you do, you’ll have a hard time convincing your team that it’s important to work on.

What to do instead:

Your PRD needs to build a strong case. You need to explain why it’s important for your company to solve the problem. Consider the benefit to your customers and the business if you can solve the problem successfully. Describe the opportunity and add some urgency to the mix; explain why focusing on it now is important. Include customer quotes and data to help the team feel your customers' pain and the opportunity on the other side when you launch the best solution.

How I write PRDs

To maximize collaboration and creativity, here’s my process for writing and using PRDs:

Start with the four critical sections.

Every company has its own version of a PRD template (if yours doesn’t have one, you can borrow mine here!), and no matter how long your template is, I believe there are four sections of any PRD that are the most critical. They are 1) the customer problem, 2) the why, 3) the success metrics, and 4) a prioritized list of requirements. 

Whenever I draft a PRD, I start with these four critical sections. First, I’ll write the customer problem and the why – it’s essential that I clearly describe the problem our users face and why our company should invest in solving it. Next, I define the success metrics to tell the team how we will know we’ve solved that problem. Finally, I work backward from the success criteria to list the requirements in priority order by considering what must be true to achieve the success criteria.

Notice I haven’t defined a solution yet. I like to write “TBD” in the solution section of my PRD drafts because I want to discuss options with my teammates first. 

Collaborate to get the best solution.

PRDs are best used as a collaboration tool. I fill in the four critical sections first to frame the problem for my team; then, I schedule working sessions with my teammates (my product design and tech lead partners at a minimum) to explain the problem to them and discuss possible ways to solve the problem. 

Make adjustments.

As these discussions and working sessions start, I adjust the PRD. The PRD should be treated as a living document, not a locked spec. Your PRD should be the cornerstone of collaboration, so update it regularly as you work with your team and the plan evolves.

There are two areas in particular you’ll want to keep updated: 

1. Your list of requirements. You’ll probably need to clarify the requirements and re-order them as your design and engineering partners start to weigh in on how to solve the problem.

2. Keep track of assumptions, risks, and dependencies that teammates and stakeholders point out.

Finally, when your team has decided on a solution to pursue, go back to the solution section of the PRD and fill that in. I like to describe the solution as a hypothesis; it’s a bet our team is making.

Keep the source of truth accurate.

As work begins to build the chosen solution, you’ll inevitably encounter roadblocks or edge cases you hadn’t planned for. When these things come up, update the PRD so your document won’t get stale. And come back to the document post-launch to link to or add details about what happened. What did you learn? Was your hypothesis correct or proven wrong? What will you do next? Your future self (and colleagues) will thank you for keeping excellent documentation of decisions and outcomes.

Want more help with PRDs and other product management skills?

👉 Get my PRD template to write product specs like a pro here 

👉 Book a 1-on-1 training call with me on Skillshare here 

👉 Check out my Product Management Foundations course, launching in January 2024, here

You got this!

Referenced in this video:

• [First Round Review] From 0 to $1B - Slack's Founder Shares Their Epic Launch Strategy

• [Spotify] Slack & Flickr: Stewart Butterfield on How I Built This with Guy Raz 

• [YouTube] Stewart Butterfield: How We Scaled the Fastest-Growing Business App Ever by 99U

• [YouTube] The Origin of Slack - Stewart Butterfield by Qualtrics 

• [YouTube] Stewart Butterfield, Cofounder and CEO of Slack by Stanford Graduate School of Business

• [YouTube] Stewart Butterfield: Serendipity in Design and Entrepreneurship [Entire Talk] by Stanford eCorner 

• [Twitter] Collection: Slack Wall of Love by @SlackHQ

Our video (below) covers Biddle’s “DHM” model, why strategies are just hypotheses, and how to test your strategies.  

Biddle covers so much more in his 12-part series on product strategy, which you should check out. He also has self-paced and live courses and tons of resources on his website, gibsonbiddle.com.

Enjoy our breakdown of Gibson Biddle’s product strategy framework!

Doing things that don’t scale seems counter-intuitive when building a business, but giving your product the jump start it needs is necessary. Whether you’re a startup founder or a product manager launching a new feature or product, you need to do things that don’t scale to get your first users and feedback so that you can make your product the best it can be. 

Without further ado, here’s our breakdown of the critical lessons in this essay. Enjoy!

In the video below, we give a quick breakdown of Jorge Mazal’s original story, with helpful visuals. Plus, we give an update on how Duolingo has exploded DAUs, again, in the last year. 

There are so many product management lessons to glean from this tale. Huge shoutout to Jorge Mazal, Duolingo’s former CPO, for inspiring product people with both the wins and lessons in this story. 

Our video is a fast, fun breakdown with big updates. If you want to dive deeper, check out the original story on Lenny’s Newsletter (20 min read) and Mazal’s interview on Amplitude (55 min video). Both are well worth the time. You can also read more about the Daily Active User model from Duolingo’s data science team here. 

P.S. The making of this video inspired me to reactivate my own Duolingo practice. I’m currently on a 20-day streak, and I’m hooked! ¡Es bueno!

You got this!

Referenced in this post

• [Lenny’s Newsletter] How Duolingo reignited user growth, a guest post by Jorge Mazal

• [Amplitude] AMA with Jorge Mazal

• DAU user stats from Duolingo’s S-1 filing, and Q2 2022 and Q2 2023 shareholder letters 

• [Statista] Leading learning and education apps worldwide in 2022 by downloads

• Duolingo on TikTok

• [YouTube] Duolingo Review 2023 (Pros & Cons Explained) by Test Prep Insight

• [Duolingo blog] How Duolingo uses AI to create lessons faster by Parker Henry

Transcript for the video above:

It doesn’t matter if you're building your own product or just launching a feature, before you build anything, you need to know this man’s formula for risk. The should-I-build-this formula.

Naval Ravikant is the co-founder of AngelList and has invested, or gambled as I call it, in over 200 companies. 

But there’s a big difference between Naval and your average gambler or angel investor. He wins. He has over 70 exits, including more than 10 unicorns. An incredible record.

Today, we're talking about the Kelly Criterion, what is it Naval?

(Audio clip starting at 0:03) “The Kelly criterion is a popularized mathematical formulation of a simple concept. The simple concept is: Don’t risk everything. … Don’t bet everything on one big gamble. Be careful how much you bet each time so you don’t lose the whole kitty.”

Here’s an example (see video above) of the Kelly Criterion formula for gambling. The simple concept is important here, not the actual formula. 

The result tells you what percent of your money you should bet based on what you’ll win and the probability of winning. Pretty simple.

So, this example (see video above) shows if you have a 60% chance of winning, you should only bet 20% of your pot.    

Why not bet the whole kitty?

Any gambler will tell you, no, no, no, you might lose a couple hands before you win. So you can’t bet the whole kitty, you’ll go broke! Pretty simple. 

Here’s where it becomes useful for angel investors. You might say, Kelly, can I invest 100 grand in a startup that has a 2% chance of returning a billion dollars? I’m using a 2% probability just as an example because the chances of a startup becoming a unicorn are extraordinarily low. Ms. Kelly Criterion will say, yes, just make sure you’re only betting about 2% of your total fund, meaning you need at least 5 million dollars to make that $100,000 bet. 

Gambling and startup investments are obvious places to look for risk because many have extraordinarily low probabilities of success. 

Well, any product launch is also a gamble and a lot of people making these bets don’t assess risk in the way that your average gambler might. 

Some product leaders are basically sitting down at a roulette table and betting the entire company on red. “But have I considered the risk?” 

Sidenote: The Kelly Criterion says to only risk negative 5% of your money on red in roulette, meaning don’t risk anything if you’re not the casino.

Unless you factor in fun and free drinks, then I would say risk only a few percent of your pot on each roll, knowing the house always wins in the end.       

As a product manager, your job is to figure out what your team should build – and risk is an important criterion for you to consider when deciding what to build.

The gist is this, when people don’t understand risks, they risk too much, the whole kitty. They bet everything on one big gamble that can wipe them out completely. 

The Kelly Criterion simply tells us to make any decent-sized bet, you need to reduce your probability of a loss. You don’t need to use the formula, just acknowledge the risks and take steps to mitigate them.

The Kelly Criterion shows that most people don’t understand the risk they’re taking. Marty Cagan kind of says the same thing, All these products get built without thinking about the risks, and that’s what leads to failure. And that’s why product managers should learn these four types of risks (see video above), how to de-risk them and reduce the probability of failure. 

I’ll link to my video on discovery for more on this or you can read his book Inspired. 

It doesn’t matter if you’re launching a huge product or a small feature, risk is risk. Someone is going to ask, “What steps did you take to ensure that people want this? That they can figure out how to use it? That the engineers can build it and the company can support it? None? Nothing? You bet it all on red?”

Don’t risk your reputation on a bad bet. De-risk before making any product bets, and don’t bet the whole kitty. You got this!

I try to catch my breath before I join the Zoom call. I’m about to talk to… a customer. 😱 

The call starts, and they talk, but I’m not fully listening. I’ve spent hours studying their business, anticipating what they will say about my product. And now, my mind is distracted, practicing the clever things I prepared to say, waiting for my chance to sound smart.

Oh, sh*t, they just asked me a question. I didn’t plan for that! What do I do?!

Talking to customers can be nerve-wracking. This is a scene that, unfortunately, I experienced often. And given how many product managers experience imposter syndrome (92%!) I’m guessing some of you have felt this way too. One small mindset change helped me overcome this fear, made my user interviews 100 times better, and can help you too.

It’s also the same thing that some of the greatest product leaders do, one’s who aren’t afraid of customers, to gain customer insight and build the world’s greatest products.

Get out of the building 🏢

Before we get into how to talk to customers, let’s talk about why we need to do it.

Talking to customers is how we explore the problem space to find real user problems, understand the whole problem, and get more creative with solution ideas. It’s a critical part of the discovery process and key to a product manager's job.

Steve Blank, the serial entrepreneur responsible for the ideas that led to the lean startup movement, says it like this: “Get out of the building.” 

His advice is aimed at startup founders, but it’s true for product managers too. “Get out of the building” is a reminder to test our hypotheses by talking to real customers. (Source: YouTube)

As a product manager, you should talk to customers often. Common advice is to have a conversation with a customer at least once a week. Those convos are usually called user interviews; they can be formal or casual, and the goal is to learn about your customers. Ideally, you can walk away from interviews with one or more insights that you can bring back to your team to help you all understand the user’s problem space and design better solutions for them.

But it’s scary outside of the building 😱

For me, talking to customers was nerve-wracking because I thought I had to have all the answers all the time. As a product manager, I’m supposed to be an expert, an authority, on the product. But in reality, I’m an expert-ish in my product area, not the whole dang product. 

As a senior product manager at Looker, a data analytics company, customer calls gave me extra anxiety because the product was so technically complex, customers used it in so many different ways, and I was often talking to users who were running the data teams at huge companies and the most successful startups. It was intimidating! I thought they were experts who would expect me to be an expert, but I didn’t always feel like an expert. (Hello, imposter syndrome! 👋)

So whenever I had a customer call coming up (which was all the time), I would force myself to do tons of homework before I could even have a conversation with them. 

Ahead of a meeting, I’d try to figure out how they used data and how they were using our product. I’d try to anticipate all their feedback and requests. I’d spend hours looking at notes from our sales and support teams. I’d go into the meeting sweating, distracted by wanting to not look dumb in front of our customers. 

Sidenote: Your product may not be as technically complex, and your users may be less intimidating, so maybe you don’t spend hours on “homework” before talking to them like I used to. But the fear of not knowing something and asking “stupid questions” is a real and natural human fear in the workplace.

Back to the story… My approach was failing me. I started to dread talking to customers. 

Instead, I should’ve taken my husband, Jeremy’s, approach from when he worked at a hardware store.

Lessons from Ron Swanson

Jeremy worked at a local hardware store when he was a teenager (before becoming a firefighter). Like any hardware store, this one sold lots of parts and tools for various construction projects. Customers could come in with all kinds of projects they were working on, like fixing a bathroom sink, replacing kitchen cabinets, or even building a tree house. 

With so many different use cases, it was impossible for Jeremy to be an expert in everything a customer could possibly do, especially as a new, young employee. And then there were the intimidating, Ron Swanson type of customers, who were actually experts and had no patience for fakers.

So, instead of trying to have all the answers, Jeremy listened to customers and asked lots of questions. He would learn as much as he could about the customer’s needs to find ways to be helpful. 

For example, if a customer needed to hang a picture frame, Jeremy would ask more questions to learn the context of the customer’s needs. 

• What are the dimensions of the picture frame?

• How heavy is the frame?

• What material is the wall made out of? Is it ½” sheet rock or ¾”?

If he didn’t know the answer, he’d consult with colleagues who knew more than him and get back to the customer with an answer. 

Every time he talked to a customer, he had one goal: to understand their problem to help them solve it.

It’s not about you 💡

That’s the mindset shift we need to make when talking to customers. It’s not about us… It’s about them. 

I was so focused on sounding smart, or more accurately, not looking dumb. 

I didn’t want to embarrass myself by not having all the answers. 

When product managers talk to customers, it’s mostly about discovery. We’re having a conversation to discover the customer’s problems and needs. To do that, we need to focus on them. 

Focusing on the customer means walking into a conversation with openness, genuine curiosity, and active listening.

My absolute favorite PM advice for talking to customers comes from Matt Lemay. He wrote a great book called “Product Management in Practice” and his advice? Play dumb.  

Yup, you heard that right. And yes, the perfectionist in me is screaming, “nooooo!” but this advice is spot on. I’ll let Matt explain:

“When talking with users, your job is not to convince, or to impress, or to align. Your job is simply to learn as much as you can about their needs, their world, and their perspective. If you are to follow the guiding principle ‘live in your user’s reality,’ you must understand your user’s reality in bright and vivid detail. In many cases, this means that your best approach is not to sound smart, but rather to ‘play dumb’ and create as much space as possible for your users to communicate with you in their own words and on their own terms.”

—Matt Lemay, Product Management in Practice (First edition), p. 85

Quick sidebar here: there are two scenarios where you should not play dumb when talking to customers:

1. If you’re meeting with an angry customer about a problem they want a solution to (e.g., a huge bug in the software they purchased or a delay in a feature you promised). This is a very unfortunate scenario, and you should show up prepared.

2. If you’re presenting something on stage or doing a talk, yeah, it’s best to sound smart in this scenario.

But in most cases, when you’re talking to customers to do discovery work, playing dumb is a great tactic. Don’t make it about you looking smart; it’s not about you, it’s about the customer. Playing dumb also has the added benefit of removing your preconceived assumptions about the customer so you can learn more. 

So, how did I learn to stop making it all about me? Honestly, it was on accident. 

One day, one of my fellow PMs got sick on a day when a customer was coming to the office to have a conversation with them. I filled in at the last minute, absolutely zero time to prep. I didn’t have to play dumb; I knew nothing about this customer’s use case.

With no preconceived assumptions or prepared talking points, I let the conversation flow naturally from a place of genuine interest and curiosity. I asked lots of questions like, “Can you show me how you’d do X?” 

I’d even go so far as to say, “I’m not an expert in Y; can you tell me more about that and why it’s important for your business? I’ll share your feedback with members of our team who are experts in that area.”

Guess what happened? I had FUN. And I learned more from that customer than any of the customer interviews I’d prepared hours for. 

In my old approach, I’d have too many assumptions about the customer, and I was so stressed that I wasn’t open and curious. By “playing dumb,” I learned way more, AND it didn’t feel scary. 

Like Ron Swanson at the hardware store, this customer didn’t want me to pretend to have all the answers. I could be more helpful to them by just listening. 

Things you can do for better convos with customers

User interviews are just one user research method, but it’s usually the easiest and cheapest method for a product manager to bring a lot of value to their team.

Here are some things you can do to make these conversations easier, more productive, and more enjoyable.

User interviews 101

• Remember: it’s not about you. Focus on the customer. You have one goal: understand their problem to help them solve it.

• You don't need to know all the answers; play dumb to give the customer space to tell you their own story in their own words.

• If you have access to a UX researcher, partner with them and let them lead! Listen to how they ask questions and learn from them. Following the lead of a great UXR person is a great way to learn the ropes.

• Know what you want to learn from your customers and prepare questions you want to ask them.

• Avoid hypothetical questions and ask about past behaviors instead. People will often lie to you and themselves, so focus on past behaviors (“Tell me about the last time you did X”) to combat that unhelpful human instinct.

• Ask customers to show you how they do a thing over describing it.

• Ask open-ended questions so they can tell you a story – you’ll get more interesting details this way. 

User interviews pro tips

• Bring your team along for customer interviews, and share insights, quotes, or video clips with your team. This way, everyone on your team gets to hear directly from your customers. This can spark more creative solution ideas from your whole team.

• Set up ways to get continuous feedback by making the outreach and interview scheduling process easy. Teresa Torres has excellent tips on continuous discovery habits. 

• Make sure you know your company’s rules for talking to customers. Do you need users to sign an NDA? Do you need to go through your account management team before contacting customers? Are there privacy policies to adhere to? Learn these up front to avoid problems later.

• Use quotes from customer interviews in your product strategy and roadmap presentations. This is one of the best ways to tell the story of your customers’ needs and influence stakeholders.

So remember, it’s not all about you. Get out of the building, focus on your customer, and just listen.

You got this!

I’ll break down the findings and why everything I thought about scaling fast was wrong. 🤯

Heads up, this new research is still a draft, so the final version may change, but it’s already been reviewed by many academics, so the main takeaways are unlikely to change.

Two conflicting hypotheses

The researchers analyzed two opposing perspectives on when startups should scale. 

The first perspective is a widespread belief in Silicon Valley and Ricky Bobby’s life motto: If you ain’t first, you’re last.

Reid Hoffman, Linkedin’s co-founder, calls this idea blitzscaling, which prioritizes speed over efficiency because you'll likely lose out if you’re not first to scale. 

Rocketship success stories of companies like Airbnb, Uber, and Beyond Meat are often cited as examples of why this theory works. On the surface, these companies embody the scale-fast-or-crash mentality and reap the benefits of amassing resources, contracts, network effects, and economies of scale. 

That’s the popular Silicon Valley scale-fast hypothesis: the earlier a startup begins to scale its business, the less likely it will fail. In the study, it’s stated like this:

Hypothesis 1a: The earlier a startup begins to scale its business, the less likely it will fail and/or the more likely to successfully exit (i.e., an IPO).

Or is the opposite true, does scaling fast increase the failure rate of startups? That’s more of a business school counterargument and the second hypothesis tested in this study.

Hypothesis 1b: The earlier a startup begins to scale its business, the more likely it will fail and/or the less likely to successfully exit (i.e., an IPO).

This second hypothesis suggests that startups that scale too fast have less time for experimentation—talking to customers and testing their assumptions—which makes them more likely to launch an unproven idea. Researchers call this commitment risk, the mistake of coming up with a bad idea, building that bad idea, and then being so committed with time and resources that it’s too difficult to pivot to better solutions.

So, which hypothesis is correct? Do you experiment or scale fast? Or better yet, can you do both? We’ll dig into the findings, which are still a draft, so these numbers aren’t “final-final” even though they probably will be.

This research is so exciting because it’s the first time anyone has analyzed the timing of startups scaling on a large dataset (more than 38K startups!) with math.

How the researchers measured scaling is really clever, I won’t get into the details here, but if you’re a data nerd 🤓 like me, check out the entire paper. I stayed up late reading all 60+ pages because that’s how I spend Friday nights, but you’ll see, it’s more fun than you think.

Ok, on to the findings.

Wild Fact #1: Four long years

Out of 38,217 startups, the researchers found that, on average, startups post a job for their first sales and manager positions at 49 months—the same time for both positions—roughly four years in. The researchers used job postings for the first sales and manager positions to indicate that a startup had begun scaling its business.

This finding is wild. I was shocked by it. Four years is much longer than most people would expect, including your mom and all your friends. If you’re a founder, they’re all wondering what you are doing with your life, chasing your startup dreams for that long.

The research shows more than 77% of startups scale after two years, and only 4% scale in the first six months. Wild. What happened to overnight success? But did these companies succeed? We’ll get there.

Wild Fact #2: Smart money scales slow

There’s a common belief that VCs want to see their portfolio companies scale or die as fast as possible. One speed, go. Surely, of the companies that scale fast, they must have VC money. No. Only 0.1% of the startups that scaled in the first six months were VC-backed, barely a fraction of one percent. 

Compare that to a whopping 19% of those that scaled after 24 months being funded by VCs. This seems to imply that the smart money wants you to take time to experiment and validate customer assumptions before you blow all their smart money on a dumb idea. Smart.

Wild Fact #3: Scale fast, fail fast

Wild fact number three is the answer you thought you were here for, but I warn you, wild fact three may be misleading if you don’t stick around for wild fact number four… 

Scaling within the first 12 months represented a 20% to 40% increased failure rate. Bad news Ricky Bobby, if you’re first, you’re last.  

The study used a few different complex models, and the results consistently showed scaling within the first 12 months represented a 20% to 40% increased failure rate, where scaling was measured by the first job post for a manager or sales position.

And overall, fewer companies failed when they scaled after 32 months, about three years, compared to those that scaled early. (Keep this in mind when we look at Airbnb later.)

The graphs and charts in the study are a bit confusing because they use multiple data points, which need to be compared to the already astronomically high failure rate of startups in general, no matter when they scale, but the overall results are clear. Scaling early was bad. 

Interestingly, this was also true for companies that were first to market, when you would think the saying, “if you’re not first, you’re last,” would matter. It didn’t. Scaling slower was better for the average startup. 

And what about two-sided platforms, where you have buyers and sellers, like Airbnb? A top benefit to scaling fast is network effects. You need a large network of buyers to buy and sellers to sell, and you need both fast because one doesn’t exist without the other. Surprisingly, the relationship between scaling early and failing was three times greater for two-sided platforms than for non-platform companies. 

On all accounts, scaling early was bad, except for one. 

Wild Fact #4: A/B testing changes everything

The theory behind this research is that scaling too fast results in less time for talking to customers, validating ideas (which I cover in detail in my video on the problem space), and experimenting before wasting money on a large scale. 

So, the Wharton researchers said, if this is really about experimenting, let's identify the companies that use advanced A/B testing software for experimentation. In most cases, these companies are paying a lot of money to run experiments, gain customer insight, and experiment with multiple options before launching anything. 

The results are staggering. There was no meaningful risk for companies that A/B tested and scaled in the first six months, while companies that A/B tested and scaled in 7 to 12 months actually had a reduction of 9.7 to 12 percentage points in the likelihood of failure. This flips the research upside down and says scaling fast is bad, except for the companies that use A/B testing software, then it doesn’t matter, and they might even perform better when they scale fast. 

The researchers conclude that the risk of scaling early does not apply to startups that engage in A/B testing, supporting their argument that scaling early is a risk because it increases the likelihood of commitment risk. That is, scaling early is only a risk because it increases the likelihood that the startup didn’t take time to talk to customers, experiment, and ultimately committed to building products that nobody wants. 

And yes, both of the unicorn startups I worked at did a lot of experimentation before scaling.

The blitzscaling misconception

Timing is not the issue; it’s about talking to customers and experimenting. This is the misconception of blitzscaling, where Reid Hoffman recommends prioritizing speed over efficiency. Nowhere does he suggest that you should blitzscale a bad idea that hasn’t been validated with customers or experimentation—quite the opposite.

Reid Hoffman was a series A investor in Airbnb, and Airbnb is a popular example of blitzscaling, scaling fast, even mentioned in the Wharton research we just discussed. Hoffman invested in late 2010. I don’t know when they hired their first manager and salespeople (which is how the Wharton paper measured starting to scale). But, they hired their first product manager in early 2011, which may have been around the same time because their team was really small before that. This chart below makes it look like they scaled like a rocket ship without time for user research or experimentation.

But let’s ask Airbnb’s co-founder, Nathan.

“... and Paul Graham told us something else he said, ‘it's okay to do things that don't scale.’ It's counterintuitive a little bit, you're making an internet company the whole idea is that it's self-serve and it can scale to millions but he said when you're trying to find that product market fit it's okay to do things that don't scale, and he asked us where are your users, and we said well our users are everywhere, he said well no where do you have the most users, we said New York, he said go to New York and meet all your users…”

– Nathan Blecharczyk, Co-founder Airbnb (Source: YouTube @17:45 - 18:14)

You can’t just look at a chart of when their user base scaled fast, after 2010; you need to go back, years back, to 2007. 

Airbnb started in late 2007 by renting out air mattresses solely for events—Reid Hoffman famously passed on that initial idea—and it was through the founders living with their customers, literally, over years, that they found that users wanted to rent out entire homes, that users wanted an easy payment platform, and that users needed help taking pictures. (This was a time before Instagram when camera phones were terrible.) I found a TechCrunch article from June 2010; Brian Chesky, another co-founder, was living full-time with customers in Airbnbs while their apartment was still the tiny company headquarters, years after their first booking, and this was just months before Reid Hoffman's series A investment.

Blitzscaling, much like overnight success, can happen after years of hard work. 

As with Airbnb, sometimes we look at when a startup scaled rapidly without considering all the years of experimentation before that. And that’s what this research shows, for the first time, on a large dataset, with math! More importantly, it’s not about scaling early or not; this is about focusing on the customer and experimenting before you scale the right product.

And, get this, the person who originally told Ricky Bobby, “If you ain’t first, you’re last,” was also taken out of context. You’ll have to watch the end of my video above to find out why. 😉

You got this!