Product Management is one of the few roles that can mean almost anything depending on the company, the team, or the moment. Over the years, I’ve developed a clear point of view on what great PM work actually looks like — not as a rigid framework, but as a set of principles I return to again and again.
What shaped those principles? Partly the products I’ve built and the teams I’ve been part of. But honestly, the foundation was laid much earlier — in classrooms, working with students who struggled to learn and struggled to fit in. Teaching gave me a deep respect for the human being behind the challenge, a tolerance for ambiguity, and an instinct for meeting people where they are rather than where you wish they were. Those lessons didn’t stay in the classroom. They came with me into every product role I’ve held since.
Start with the Customer. Stay with the Customer.
The best product decisions I’ve made trace back to a single source of truth: deep, ongoing customer understanding. Not a quarterly survey. Not a NPS score. Real conversations, observed behaviors, and an honest reckoning with the gap between what users say and what they do.
Numbers and data points are essential — but they’re a starting place, not a destination. Behind every metric is a person with a context, a frustration, a workaround they’ve quietly built into their day. The data tells you what is happening. Only the human conversation tells you why. I’ve always believed that the most important insights live in that gap — in the moments of confusion, hesitation, or delight that no dashboard captures.
My years as a teacher — especially working with students who struggled to learn and who often felt like they didn’t belong — taught me this before I ever touched a product roadmap. A struggling student rarely lacks intelligence. They lack the right entry point, the right framing, the right moment of being truly seen. I learned to look past the surface behavior and ask what was really going on underneath. That instinct translates directly to product work. A user who abandons a flow, skips a feature, or contacts support isn’t failing — they’re telling you something important. The question is whether you’re paying enough attention to hear it.
I believe discovery is never “done.” Markets shift, user needs evolve, and assumptions that were true six months ago may quietly no longer hold today. The PMs I most admire treat customer obsession as a discipline — something you practice, schedule, and protect — not a phase you complete before moving into execution. Real discovery requires searching, testing, experimenting, and sometimes just playing. The quick win feels satisfying, but it rarely produces the powerful, memorable experience that keeps users coming back.
This means I push hard for direct access to users at every stage. I want my team to ask questions before we write a spec, not after we’ve shipped. The goal isn’t to let customers design the product — customers often tell you what they want, and it’s our job to understand what they actually need. It’s to make sure we’re solving a real problem worth solving, in a way that makes things meaningfully better for the greatest number of people.
Design for Humans: Don’t Make Me Think
If there’s a single principle that has shaped how I think about product design, it’s this: don’t make me think. Great design isn’t ornamental — it’s purposeful. It removes friction, anticipates need, and gets out of the user’s way. The best products feel almost invisible because they work exactly the way a person expects them to.
Simplicity is not a style choice. It’s a form of respect for the user’s time and attention. Every unnecessary step, every confusing label, every cluttered screen is a small tax on the person trying to get something done. I push hard for clarity — not because I don’t value creativity or craft, but because the goal of design is to serve a purpose, and that purpose belongs to the user.
The classroom taught me this, too. When a lesson was too complicated, too cluttered with objectives, or required too many leaps at once, students didn’t fail to understand — the lesson failed them. The best teaching, like the best product design, strips away everything that isn’t essential and makes the path forward feel obvious. That standard has stayed with me.
This also means resisting the temptation to add. Features accumulate. Interfaces get complicated. Complexity tends to creep in quietly over time, and it takes deliberate effort to cut, simplify, and focus. The products I’m most proud of are the ones where we made something harder to build to make it easier to use.
Saying No Is an Act of Respect
I’ll be honest: saying no is hard for me. By nature, I’m a pleaser. I want people to feel heard, supported, and valued — and telling someone their idea won’t make the roadmap can feel like a rejection of them, not just their suggestion. It’s something I’ve had to work at.
But I’ve learned that saying no, done with care and clarity, is one of the most important things a PM can do. Every yes has a hidden cost: the team’s time, focus, and energy. Every feature that gets added must be maintained, explained, and eventually reconsidered. Protecting the integrity of a product vision sometimes means disappointing people in the short term to serve them better in the long term.
The key is that a good no is never dismissive. It comes with an explanation rooted in the strategy, an acknowledgment of the idea’s merit, and — whenever possible — a better path forward. When people understand why you’re saying no, it builds the kind of trust that makes the next conversation easier. And that trust is worth more than any single feature.
Strategy Is a Series of Bets, Not a Blueprint
I’ve come to think of product strategy less as a roadmap and more as a portfolio of informed bets. You rarely have perfect information. What you can have is clarity about why you’re making each bet — what assumptions it rests on, what would prove it wrong, and how it connects to a larger outcome you’re working toward.
A strong product vision gives a team something to navigate by. It answers the question: If we succeed, what will be different in the world? That question sounds simple, but the rigor required to answer it well — and to keep the answer honest over time — is where I’ve seen good strategy separate itself from wishful thinking. The goal is always to make something that is not just functional, but different and meaningfully better — for the widest possible range of people it touches.
The Soup We Make Together
Product Managers don’t own a team, but they’re responsible for what the team produces. That tension is the defining challenge of the role — and I’ve found that navigating it well comes down to one thing: trust.
Teaching shaped how I think about this profoundly. A classroom where students feel unsafe to be wrong is a classroom where no real learning happens. The same is true of a product team. When people are afraid to surface bad news, flag a bad assumption, or advocate for an unpopular direction, the team loses its most important early warning system. Building psychological safety isn’t a soft goal — it’s a strategic one.
I think of a great product team like a good soup. Everyone brings something to the pot. The engineer who flags a technical constraint that reshapes the solution. The designer who reframes the problem entirely with a single sketch. The support rep who shares what customers complain about most. The marketer who knows how the message lands in the real world. No single ingredient makes the soup — and no single person, including the PM, has a monopoly on good ideas.
In practice, that means investing heavily in a shared vision before a project begins, not scrambling to re-align after it goes sideways. It means treating engineers, designers, data scientists, and go-to-market partners as genuine collaborators — not executors of a solution I’ve already decided on. Their input and lived experience are equal to mine. The PM’s job is to hold the direction, not hoard the answers.
Building this kind of team culture requires intellectual honesty. PMs who protect their own certainty at the expense of the team’s input tend to ship products that reflect their assumptions rather than reality. The role demands enough conviction to hold a vision steady, and enough humility to be genuinely changed by what you learn from the people around you.
Failure Is the Better Teacher
Some of the most important projects I’ve worked on never shipped. Months of work, discovery sessions, prototypes, debates — and then nothing. It’s a particular kind of professional grief that doesn’t get talked about enough.
But I’ve come to believe, genuinely, that those projects taught me more than most of my successes. Thomas Edison put it well: “I have not failed. I’ve just found 10,000 ways that won’t work.” That’s not just a motivational poster — it’s a real description of how durable knowledge gets built. You remember the discomfort. You remember the moment a core assumption collapsed. You remember the frustration of a test that went sideways or a launch that landed quietly. Those memories stick in a way that easy wins don’t.
Failure sharpens your instincts. It teaches you where your blind spots are, what questions you should have asked earlier, and how to build processes that catch problems before they become expensive. I’ve tried to cultivate a team culture where a project that didn’t work is still considered a success if we learned something worth knowing — because that learning compounds, and eventually it becomes the foundation of something that does.
What I’m Always Working Toward
At its core, my PM philosophy is this: be obsessively close to the customer, design for simplicity and purpose, hold the vision while sharing the journey, and learn relentlessly — especially from what doesn’t work. These aren’t trade-offs. They reinforce each other.
But I want to be clear about what “learn relentlessly” means to me — because it extends well beyond product work. I’m in constant pursuit of understanding more about how the world works. The neighborhood I live in. The history behind the places I visit. The music I’m listening to and the ideas embedded in it. The people I meet and the lives they’ve lived that I haven’t. I read widely, ask questions freely, and try to stay genuinely curious about things that have nothing obvious to do with my job — because they always end up having something to do with my job.
This habit started in the classroom. Working with students who struggled — who had been written off, misread, or simply never met a curriculum that fit the way their minds worked — forced me to stay humble about what I didn’t know. Every student was a different puzzle, and the moment I thought I had it figured out, I’d meet one who rewired my assumptions entirely. That experience built in me a deep allergy to certainty. I don’t want to be the person who thinks they have all the answers. I want to be the person who keeps finding better questions.
The clearest product visions I’ve seen came from teams that truly understood their users. The most elegant solutions came from teams that resisted complexity on principle. The smoothest executions came from teams with a strategy everyone believed in — and the wisdom to keep building even when a project didn’t pan out.
Product management, done well, is one of the most intellectually demanding and genuinely rewarding crafts in the industry. I’m a better PM because I was a teacher. I’m a better teacher — of teams, of ideas, of craft — because I never stopped being a student.
Phil Havlik 