Why Dan Olsen Loves Product - TPH Spotlight
On designing nuclear submarines, writing the book that product people still reach for eleven years later, and why the question nobody thinks to ask him is also the most important one.
Nobody ever asks Dan Olsen why he loves product management.
It seems obvious. He wrote the book. He hosts the meetup. He runs the summit. He speaks at conferences on every continent. He has been consulting on product since before most people had a name for what he was doing. Of course he loves it.
But the why matters. And when you sit with him long enough to get to it, you realize that the reason he loves it is also the reason the work is hard, and the reason most people who try it either fall deeply in love or quietly find something else to do.
We will get there. First, we talk submarines.
Education and Professional Highlights
Currently: Product management consultant, trainer, speaker, and author. Clients include Google, Walmart, Amazon, Meta, Box, Microsoft, Medallia, and One Medical Group.
Book: The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. Published by Wiley, 2015. Bestseller. Still widely read. Dan narrated the most recent audiobook version himself.
Meetup: Host of the monthly Lean Product and Lean UX Meetup in Silicon Valley.
Before consulting: Product leader at Intuit (Quicken), Friendster (VP of Product, 2004 to 2005)
Before tech: Lead Technical Product Manager, Naval Reactors, US Navy. Designed nuclear-powered submarines for five years.
Education: BS Electrical Engineering, Northwestern University. MS Industrial Engineering, Virginia Tech (lean manufacturing). MBA, Stanford University.
Based in: Silicon Valley.
Where He Came From
Dan’s parents gave him a computer when he was ten years old. He used it the way a ten-year-old with a curious mind would: he wrote a program to help him practice spelling words for school. He wrote another one to track his newspaper route and of course, he played games. But underneath all of that was something more durable than any specific application.
He became completely comfortable with computers. Not as a user. As someone who understood that you could have an idea and make it real.
“The most important thing is it just made me comfortable with computers and coding. I was not intimidated by that at all. I was excited by the ability to create something.”
That comfort, and that excitement, never went away. It threaded through three degrees, five years in the Navy, a career built across submarines and social networks and financial software and early-stage startups, and eventually into the book that tens of thousands of product people have used to understand what their job actually is.
His father was a science-minded person who encouraged curiosity and loved math. Dan credits him with the thread of first principles thinking that runs through everything he has built since: the instinct to understand the causality behind things, to find the mental model that explains why something works, rather than just accepting that it does.
He went to Northwestern on a Navy ROTC scholarship and studied electrical engineering, because it felt like a natural extension of his strong interest in computers. At Virginia Tech he got a master’s in industrial engineering and studied lean manufacturing, years before lean startup existed as a concept. When Eric Ries published The Lean Startup, Dan read it and instantly recognized how it reinforced many principles of good product management.
The MBA at Stanford was the most deliberate step. He knew he wanted to move beyond engineering, he knew he wanted to work in high tech, and he knew that Silicon Valley was where that would happen. Stanford was the most direct path to all three.
Five Years Designing Nuclear Submarines
After Northwestern, Dan went to Naval Reactors in the Washington, D.C. area where he spent five years as a Technical Product Manager working on the nuclear propulsion plant design for the next generation submarine that would become the Virginia class.
He describes it as probably the best job you could have right out of college.
The work required first principles thinking applied to one of the world’s most complex products. Every decision had consequences. Everyone working there was exceptionally smart and completely focused on the mission. Naval Reactors was founded by Admiral Hyman Rickover, the person who almost single-handedly created the nuclear-powered submarine program in the 1950s. Dan says that although he is not well known, Admiral Rickover was an innovative tech maverick on par with Steve Jobs and Elon Musk. Rickover was celebrated on the cover of Time magazine back in 1954. The culture Rickover had built over decades at Naval Reactors was so strong that Dan says it felt like his ghost was still roaming the halls.
“It was all about first principles thinking and a systems approach. The only way to tackle a big complex product is to divide it up into areas of responsibility. Everybody works in a matrix organization., People don’t report to you and you have to work across teams.
That was my first example of working in a cross-functional matrix org to drive technical decisions for a complex product. And it worked extremely well.”
As part of Naval Reactors training, he also spent six months studying nuclear and mechanical engineering in Pittsburgh, essentially another graduate degree on top of the ones he already had. By the time he finished his five-year commitment and went to Stanford for his MBA, he had built significant expertise in how to design complex systems .
He did not know yet that it was perfect preparation for product management. He just knew he wanted to do something broader.
Walking Into a Machine
In his second year at Stanford, Dan had a general sense that he wanted to work in high tech, but hadn’t figured out the details yet: Which company? Which job? He discovered product management through an on-campus recruiting info session by Intuit. The PM from Intuit was super enthusiastic about his job, and as he explained what product managers do, it instantly clicked with Dan that this role sounded like it could be a perfect match. Despite his excitement for this job he had just discovered, Dan realized he had never done it before. He had never even worked at a software company. So he asked people in the know: where is the best place to learn product management?
Everyone said Intuit.
He interviewed at Intuit and accepted an offer to join the Quicken product team. And he walked into what he still describes as a machine.
Intuit’s approach to product was unlike anything else that existed in software at the time. The company’s founder, Scott Cook, came from Procter and Gamble, and he brought with him a deep belief in customer research, marketing discipline, and product differentiation grounded in genuine understanding of what people actually needed. Dan had a PhD in market research sitting next to him on the Quicken marketing team. They flew around the country doing qualitative discovery research with customers. They mailed CD-ROMs to beta testers. They followed people home from stores to watch them install software. They had a usability lab before usability was a recognized discipline.
“As a PM you were the spokesperson and the public-facing person. You had to go represent your product to Walt Mossberg at the Wall Street Journal, people at PC Magazine. They were also just really good at planning and executing the different phases of a cycle. You started with research and discovery. Then planning. Then the MRD. Then you kicked off. Then specs. Then beta. Then GA. It was a one-year cycle, which in hindsight was great because you had enough time in each phase to do it properly before you moved on.”
He also learned something at Intuit that he has carried ever since: the best research and product management in the world does not save you if the UX design is not right. He made it a deliberate choice to learn as much as he could about UX design, not because it was his job, but because he could see how it was so critical to creating successful products.
He led the Quicken product team to record sales and profit. He left after five years. Not because anything was wrong, but because he was ready to take what he had learned and go do it somewhere smaller and faster.
Transition to Startupland: Being Inside Friendster During the Wild West of Social Networking
If any of you reading this was like me back in college getting hooked on Friendster, you can imagine the excitement I had talking to him about this part of his journey. Friendster, to so many of us, was a cultural phenomenon and a moment - something that opened up the future, and perhaps sealed a part of our past, as we all became a little too connected and conscious about what we appeared like to the world.
Dan joined Friendster as Head of Product the summer of 2004. Facebook launched in February of the same year.
He went in with his eyes open, at least as open as they could be. They were on their third CEO. The heads of product and engineering were not speaking to each other. He wanted to make sure he understood what he was walking into. Before accepting the offer, he interviewed everyone with whom he would be working. Compared to the Intuit machine, Dan found this early-stage startup to be a completely different and more chaotic planet. He tailored his product process to the startup environment, created a hierarchy of user needs framework based on uptime and performance as table stakes before features and UX, facilitated the creation of the company’s first business OKRs, and drove viral loop optimization at a time when no one had a name for that yet.
But he could also see, almost from the day he arrived, what was actually happening.
“I learned right away that we were basically walking dead. We had this terminal disease, we just hadn’t died yet. Everyone was looking at the worldwide numbers of users, and we looked great because we were huge in the Philippines and South America. But when I looked at just the US numbers, MySpace had already passed us before I even joined. The curve was going up. We tried to fight the good fight, but you could tell how things were going to play out.”
Network effects in a social network are the strongest type: exponential. He watched it happen in real time. MySpace ate Friendster’s lunch. Then Facebook ate MySpace’s lunch.
How the Book Got Written
After Friendster, Dan went back to school. Not to another graduate program. To City College of San Francisco, eighty dollars a class, where he took HTML, CSS, JavaScript, PHP, MySQL, Unix, Apache, and Photoshop back to back. He wanted to understand the web stack the way he understood electrical engineering and submarines. He ripped off the bandaid and dove in.
Then he started consulting. The first engagement was serendipitous: a startup needed a product leader but could not wait for him to finish his classes, so they agreed to a part-time arrangement as interim VP of Product. It worked out well. He did it again for another company. And another. He realized he was seeing more in a year than most product leaders see in five, working across multiple companies, multiple spaces, multiple teams, each time learning what was working, what wasn’t, and trying to fix it in a defined window.
He worked with Box post-series A when they were just getting going. With One Medical when they had three engineers. With Medallia, where he helped grow the product team from six to twenty-one people. And along the way he was giving talks, iterating on his frameworks based on the questions people kept asking, and accumulating hundreds of slides that captured what he was learning.
On January 1st, 2012, he opened Excel and made a project plan to write a book. He then proceeded not to write a single word.
In 2013 he gave a popular new talk at Google about lean product principles. The talk was recorded and published online because it was Google and they owned YouTube. A Wiley editor saw it and emailed him. Had he thought about writing a book?
He signed the contract partly because he knew writing a book would take tons of work and he needed a forcing function. Without a contractually committed deadline, he knew it would keep getting deferred. The book enabled him to go deeper than he ever had in his talks, to sit down and think without distractions, and to push beyond the frameworks he had created across hundreds of slides.
That is when he created the Product-Market Fit Pyramid. Precursors of it existed in earlier, piecemeal fragments. But the sustained focus of actually writing the book gave him the space to make it coherent.
The Lean Product Playbook came out in 2015. It has been widely praised ever since.
What Still Holds Up Eleven Years Later
I asked Dan what in the book has held up most cleanly. His answer was immediate.
The concepts. All of them.
Understand who your customer is.
Understand their problems before you think about solutions.
Define your differentiated value proposition.
Identify which features should be in your minimum viable product.
Design a great user experience.
Test before you build.
None of those things have changed, because none of them are tied to a specific technology or a specific moment. They are tied to how people make decisions about what to buy and what to use, which has not fundamentally changed in eleven years and is not going to change in the next eleven.
What has changed is the tools. When he recorded the most recent audiobook version, which he narrated himself, he updated all the tool references. InVision became Figma. The rest stayed.
“A number of reviews on Amazon say things like, I wish I had this book three products ago. I wish I had this book when I did my startup. People that have tried it a different way read the book and have this eye-opening moment. That’s what I hope happens. That they recognize when their org is starting with solutions instead of problems. If nothing else, they come away with that awareness.”
By the way, I highly recommend you get the book and the second version of the audiobook which he narrated himself. You’ll get genuine, energetic, focused, Dan Olsen in those assets.
The Design Gap and Why Vibe Coding Actually Matters
Dan has been excited about AI prototyping for over a year, and he is specific about why in a way that cuts through a lot of the noise.
He has a slide he first created in 2006 based on what he saw in many companies. He calls the problem it describes “the design gap”: the persistent reality that most product teams do not have adequate prototyping resources. When he asks audiences to raise their hands if they feel like they have enough prototyping support to test ideas properly before sending them to engineering, fewer than ten percent of hands go up. Every time. For nearly two decades.
What vibe coding and AI prototyping tools have done, he says, is unblock all the teams that always wanted to do discovery prototyping but could not, because they did not have a designer available or the time to wait for one. Now a product manager who cannot code and is not a designer can create a high-fidelity, functional prototype in a fraction of the time it used to take. The behavior that was always right, prototype before you build, is now accessible to almost everyone.
“Before, you’d be stuck if you didn’t have a designer who could create a prototype for you. Now that’s unblocked. And actually there are multiple audiences for the prototype. The first audience is you as the PM. You’ll put your PRD in as a prompt, get the first shot prototype, and instantly realize three things you forgot to specify. So you’re the first audience. Then your team. Then senior stakeholders. Then customers.”
He is also honest about where the tools are not yet delivering what the loudest voices claim. The last mile is hard. Getting from a working first shot to something at the ninety-fifth percentile requires debugging and iteration and enough technical fluency to navigate the bumps. The super fans and the skeptics are both wrong. The truth is somewhere in the middle, and the people who will get the most out of these tools are the ones who bring persistence and judgment alongside the prompts.
He is currently most excited about task automation tools, with Claude Cowork as the leading example. Unlike chat-based AI or code generation, these tools automate workflows without requiring coding knowledge. He has been giving talks and teaching workshops on this specifically, because he thinks it represents the next frontier of what becomes accessible to all knowledge workers, even those who are not technical.
The Problems That Are Always the Same
Dan has worked with enough companies across enough stages that when a new CEO or CPO starts describing their situation, he can often predict what they are going to say before they say it. He keeps this observation to himself. But the pattern is unmistakable.
Lack of role clarity. People have not defined what a PM’s role is versus a designer’s versus an engineer’s. Turf battles emerge not from bad intentions but from unspoken assumptions about who is supposed to do what.
No clear process. Teams jump straight to coding without doing discovery first. Not because they do not know they should do discovery, but because no one has made discovery an explicit part of how they work.
And above all: starting with solutions instead of problems. YES!
“Everyone is coming to you as a PM with solutions. Your CEO, your stakeholders, your clients. They’re all asking for features. And the number of times you build exactly what they asked you to build and it doesn’t actually solve a problem or create value, it’s sad how many times that happens. The PM’s unique value add is defining who the customer is and what their problems are. That’s really the biggest thing.”
He has a move for when a CEO brings a solution instead of a problem. He calls it the judo move. You do not tell them their solution is wrong. You say it sounds like a great idea, and ask if you can make sure you are clear on what problem it is solving. You open the door. Once they are talking about the problem, two things often happen. First, they realize their original solution would not actually solve it. Second, a different solution idea emerges that does, usually with a much smaller scope.
He said something else about this that I love. No professional sports team would take a group of random people, put them in jerseys, and tell them to go play. They would ask, what are our positions? What are our plays? Let us practice. Product teams do this constantly. They throw people together with similar titles into a room and assume a functional team will emerge. It almost never does. And many companies don’t take the time to train or even discuss with those people how to actually work together.
The People Who Changed Everything
Dan thanked his parents. His dad, the science-minded curiosity-encourager who pointed him toward first principles thinking. His mom, who was always supportive even when the path was not obvious.
He thanked Admiral Hyman Rickover, whom he never met. Rickover created Naval Reactors and the culture of the place where Dan started his career. The culture was so strong, Dan said, that it felt like the admiral’s ghost was still roaming the halls decades later. You can learn a lot from a ghost with that kind of imprint.
He thanked Steve Grey, his GM at Intuit, who saw potential in Dan early and made a specific, deliberate choice: when the manager between them left, Steve did not backfill the role. He let Dan report directly to him instead, which meant more access, more exposure, and more learning than he would have otherwise had. That kind of quiet, specific act of investment in a person is easy to overlook. It is also the kind of thing that compounds for decades.
He thanked Dave McClure, who invited him to give a talk in a Stanford class on Facebook app development in 2007, saw him speak, and then got him a slot at the O’Reilly Web 2.0 Expo at Moscone. That was the moment Dan got off and running as a speaker. More than five hundred people in the room. Every question the audience asked became a new slide or talk. The whole body of public work grew from there.
He thanked Richard Narramore, his editor at Wiley who saw the potential for The Lean Product Playbook and supported Dan’s choices as he wrote the book.
And he thanked Vanessa, his wife of twenty years. He said it plainly: he calls her his co-founder in life. When he was writing the book and their kids were one and three, the only way he could make real progress was to go into an office on Saturdays and Sundays when his energy was good and his attention was unbroken. She made that possible. She has made a lot of things possible, across years of travel and workshops and conferences and all the demands that come with the work he does.
“She’s always been very supportive. With my work, I travel a lot for conferences and workshops. That can be tough on our home schedule. So she’s always been very supportive. That’s why I call her my co-founder in life.”
Why Do You Love Product Management So Much?
I always end with the same question. What do you wish someone would just ask you that nobody ever does?
Dan had thought about it. He said he had come up with a few candidates, but this one was the best:
He wishes someone would ask him why he loves product management so much.
He explained that the answer is obvious in one sense: he has been obsessing over this discipline since his first day at Intuit, he wrote a book about it, he hosts a monthly meetup, he runs a summit, he speaks about it everywhere, he teaches it. Of course he loves it. But nobody ever asks why. And the why, he thinks, is worth saying out loud.
“It is a role where you can create a lot of value. For your customers. For your company. And for your co-workers. A good PM can take a dysfunctional cross-functional team and whip it into shape and make everybody excited and happy and proud of what they’re launching. But the weird thing is, you are not granted much authority or respect. You have to earn it. No one reports to you. You have to influence and persuade without being a pushover. You have to have strong opinions while being genuinely open to feedback. On paper it sounds like torture. What is this job?”
He paused. And then he delivered again:
“When it’s high and you’re launching and people are loving your product and you’re creating a lot of value, it’s a lot of fun. I hope most people have had a chance to experience the highs as well as the lows. Because when it’s good, it’s really good. The job of Product Management is about zooming in and out. The really good product managers can hold the thirty-thousand-foot view of why the company is doing what it is doing, zoom all the way down into the details of a single line of wrong text on a landing page, and connect the dots between the two. They understand that fixing that text is connected to a strategic objective. That bug. That UX issue. All of it connects. And underneath all of it, is the fundamental thing: it is always decision-making under uncertainty.
You are creating order out of chaos. Helping groups make decisions in the fog. That is the job. That is what it actually is.”
He has spent thirty-plus years in this field. He designed submarines, watched social networks rise and fall, helped build some of the most important companies in the Valley, and wrote the book that a new generation of product people is still reaching for.
He loves product management.
I’m so happy we all get to understand why.
_______________
You can find Dan at dan-olsen.com and on LinkedIn. The Lean Product Playbook is available wherever books are sold. Make sure you get the audiobook version narrated by Dan himself. He will know if you did not.
Dan, thank you. I owe you a better photo from the next time we are in the same room :)
