I don’t come from a traditional product background. That gives me a fresh perspective on the job, unburdened by “best practices.”
I follow great PMs and read widely, but I try to approach the work from first principles where possible.
On a flight to Tokyo, I wrote down some reflections on product, managing teams, and what AI is changing.
The younger the product, the more frequently you need to ship. For new products, I aim for weekly releases. As a product matures and becomes more complex, that usually moves to a two-week cadence. I hold it there for as long as I can without breaking the system.
I apply a similar logic to roadmaps: the planning horizon should be roughly proportional to how long the product has existed.
The most valuable thing in product, and the hardest, is building something people truly want. Until you reach PMF, everything should serve that objective. Process, best practices, scalability, and sticking to a roadmap in the face of new evidence are all secondary. Finding PMF repeatedly is rare. The team needs to be prepared to experiment rapidly until it lands on something users love.
I’m at a point in my career where I’m comfortable questioning best practices. There is a lot of peer pressure to adopt certain processes, frameworks, and ways of working. Yet most were developed for a different world, with different technologies and different problems. To compete at the highest level, start with the outcome you want and strip away the processes that get in the way.
Healthcare is a very hard industry to build in. We build products for doctors, and I’m not one. There is always a gap between what I think they need and what they actually need, which means I have to talk to users constantly. Building for yourself is much easier. Compliance and legal breathe down your neck at every step, making each feature twice as hard to implement without compromising its value. But when you solve a problem, the impact is tangible. Our work directly affects patient outcomes. Seeing that firsthand stays with you.
Product and sales are the two best roles to prepare you to run a company.
As a CPO, I could hire a layer of middle management and focus almost entirely on the big picture. I’ve chosen not to. I want at least one product directly under me, end to end: PRDs, documentation, coordination, negotiating priorities, building prototypes, meeting users and customers. Staying close to the work keeps me connected to reality. Get too far away and you forget how hard the job is. Your expectations become unrealistic. Take on too much, though, and you can start dreaming smaller because you know exactly how many things need to move for anything to happen. More importantly, you lose the time to think deeply about the future you want to create.
A useful mental mode: I want people to be shocked by how small my team is relative to how much we deliver.
Product can mess with your head. Too many wins and your ego becomes dangerous. Too many failed experiments and you take them personally, then start doubting yourself. Your contribution matters, but you’re operating in a world far more complex than your own decisions. You have to manage your psychology on the way up and on the way down.
Building a culture of high performance is difficult. My approach comes down to a few things:
It starts at the top. People copy what leaders do. They copy the negative traits first because those are easier to adopt. Be deliberate about your behavior.
Address politics, ego, and repeated mistakes immediately.
Praise in public. Criticize in private.
Trust is earned. When someone joins my team, I micromanage them. Competence and hard work earn them more autonomy until I can step back and give them nearly complete freedom.
In the early days of a product, you’re more of an artist. You don’t have enough data, so taste and intuition carry more weight. Follow your gut too far, though, and you end up building only for yourself. Once the product gets traction, data helps balance that intuition. Overplay the data and the product becomes a commodity, resembling everything else on the market. Taste matters at every stage. Very few people have it.
Collaboration has a cost. Too many meetings keep you reactive and leave no room for deep work. Too few create information asymmetry. When I start a new product or hire someone, I begin with a daily call. Once we have strong alignment, I move to every other day, then weekly, then every two weeks.
Effective PMs come in several forms, with different strengths:
Analytical PMs are excellent with data and gravitate toward decisions grounded entirely in historical performance.
Pattern recognizers observe the world closely and borrow solutions from adjacent products and industries. This is where I place myself.
Visionaries are extremely rare. They see a glimpse of the future and can communicate it clearly.
Learning machines figure out whatever they need to get the job done. Their taste may still be developing, but they do what it takes to get the job done.
Project managers, which I don’t mean as an insult, are exceptional at organizing work, maintaining roadmaps, documenting decisions, and making sure no corners are cut.
Processes are rarely a net positive for the organization. Most benefit the person or team introducing them while imposing a net cost on everyone else. Fight them at every step. Use technology to automate repetitive work and reduce errors instead of adding more process.
When building a new product, you’re operating in one of two modes. Either you have strong conviction about what needs to exist because you’ve experienced the problem yourself or can see where the world is heading, or you’re experimenting rapidly, putting ideas in front of users until something sticks. Be honest within the team about which mode you’re in. If it’s experimentation, everything else is secondary, you should be ready to pivot at every step and go against your roadmap.
You may have “product” in your title, but much of the job is influencing other teams, particularly leadership and engineering. You spend more time doing that than making hard product decisions. You’re constantly telling stories. The better the story, the more people want to prioritize your ideas and help make them happen. An effective story needs a compelling vision, clear articulation, data, tangible examples, and a problem people can relate to.
If you’re not active on Twitter/X, you’re not serious about the PM job.
The entire world is amazed by AI, but nowhere are the benefits more pronounced than at the intersection of product and engineering. What we can build today is wild. It also gives me a much greater appreciation for the teams that built great products without it. But AI doesn’t solve all your problems. Steering models in the right direction is hard. The work still demands nearly as much foresight, analytical thinking, taste, and determination to crack difficult problems.
A few more thoughts on AI:
I’m still surprised by how many heavily hyped models and products are terrible for our use case and, by extension, many others. But every so often, you find something that lets your product do what was unthinkable a few months earlier. That alone is reason to keep testing.
The way people use AI tells you more about their intelligence than it does about the capabilities of the model.
Keeping up is hard. Too much happens every week. A few groups of smart, ambitious friends pushing as hard as you are become invaluable. What they learn is often worth far more than what you read on online.
AI has made me more patient about hiring. I’m confident it can help me keep things under control even when there’s too much going on. That gives me more time to interview properly and assess whether someone is the right fit.
I have never felt so hopeful yet so exhausted in my career. And I’ve always worked harder than most people I know.
There is real tension between product and engineering over how to use AI because the incentives differ. PMs want to reach PMF as quickly as possible. Engineers want to build a secure, scalable product that won’t let the company down. I experience this tension daily. A few conclusions I’ve come to:
AI is wonderful for prototyping, and “prototype” doesn’t have to mean something crude, cheap, and disposable. A prototype can be complex and serve large groups of users for extended periods. It depends on the problem you’re trying to solve.
For a nontechnical PM, nothing teaches you the complexity of software development like owning an AI engineering project end to end. Choosing an architecture, fitting it into existing systems, coordinating with designers, maintaining documentation, putting guardrails around code quality, managing branches and staging environments: it’s an accelerated education in what building well at scale requires. Every PM should own at least one such project. You ship more, and you build better alignment and greater appreciation across teams.
I strongly encourage using AI in everything we do, with one rule: you must be able to stand behind everything it writes that you share with other teams.