Building software products that the market actually wants
I started my career building a product that nobody bought at scale. Four years, a Series A, a patented technology, and genuine excitement from everyone who saw it. The market just didn't prioritize the problem we solved. That experience shaped everything I've done in product since.
What product management is actually for
Product management is the function that sits between what can be built and what should be built. That sounds simple. In practice it requires maintaining a clear line between internal conviction and external evidence, and having the discipline not to confuse the two.
The role has evolved significantly. In many organizations it's still unclear what a PM is actually responsible for, where they sit in relation to engineering, and how much autonomy they should have. I've worked through those questions in multiple contexts, and my view is that the answer depends less on frameworks than on the specific dynamics of the company.
Discovery: the part most teams underinvest in
Most product failures I've seen were not execution failures. The team shipped what they said they would ship. The problem was that nobody had validated whether it was worth shipping.
Discovery is the work of reducing that risk before you commit engineering time. It means talking to customers early and continuously, not just at the beginning of a project. It means forming explicit hypotheses and designing ways to test them cheaply. It means being willing to kill an idea that doesn't hold up under scrutiny.
What good discovery looks like in practice
It's not a process or a template. It's a habit. PMs who are good at discovery talk to customers every week, not every quarter. They ask about problems, not solutions. They listen for what customers do, not what they say they want.
The output of discovery is not a requirements document. It's a set of well-grounded bets about what will create value, with enough evidence to justify the investment.
Roadmap: decisions, not lists
A roadmap is a prioritization tool, not a project plan. Its job is to communicate what the team believes will have the highest impact over a given horizon, and why.
The hardest part of roadmap work is not deciding what to build. It's deciding what not to build. Every feature request that makes it onto a roadmap crowds out something else. The discipline is in maintaining a clear view of what drives retention, activation, and expansion, and ruthlessly protecting time for those things.
How I approach roadmap prioritization
I start from customer evidence: what are the patterns in support tickets, sales objections, and churn reasons? What do your best customers use most? What do churned customers say they were missing?
From that, I work with the team to separate the roadmap into three buckets: what keeps current customers happy, what enables the next ICP segment, and what creates a defensible long-term position. The balance between those buckets depends on the stage of the company.
The product-market relationship
Product and market are not separate concerns. The market shapes what the product should be. The product shapes what markets are reachable. Managing that relationship is an ongoing conversation, not a one-time alignment exercise.
I've worked on products that were technically strong but commercially misaligned, and on GTM motions trying to sell products that hadn't quite nailed the use case yet. Both experiences taught me that the gap between product and market is always a leadership problem before it's a product problem.
Cross-functional alignment
Product management is roughly 50% alignment work, 30% collaborative thinking, 15% communication, and 5% actually deciding what to build. That distribution surprises people, but it reflects reality: the best product decisions are worthless if the people who need to act on them don't understand or trust them.
The work of alignment is not about consensus. It's about creating shared understanding across product, engineering, sales, and customer success so that each function can make good decisions independently.