25 Things I Believe In to Build Great Products
What I believe in is often the opposite of how big companies like to work
Dear subscribers,
Today, I want to share 10+ years of PM lessons in just 12 minutes.
I’ve been a product leader at companies like Roblox, Reddit, Amazon, and Meta. But the funny thing is that:
What I believe in is often the opposite of how big companies like to work. 😅
Watch my video now to get my unfiltered take on how to be a great PM in the AI era.
Timestamps:
(00:00) Why what I believe in often the opposite of how big tech works
(00:18) Speed is the only moat: Build fast feedback loops
(02:34) Focus is a superpower: Say no 10x more than you say yes
(05:00) Product over process: Reject PM theater
(07:32) Seek the truth: Ban decision by committee
(09:45) Builders over bureaucrats: Start with proof of work
Watch now on YouTube or keep reading below.
This post is brought to you by…Framer
Early-stage founders often face a frustrating choice: spend weeks getting a professional site up or settle for something that looks like a purple AI-generated slop.
Framer solves this by letting you:
Launch a beautiful professional site in hours without hiring developers.
Scale your site from MVP to full product with CMS, analytics, and AI localization.
Early-stage startups can get one year of Framer Pro free ($360 value) and join thousands of founders already building on Framer with my link below.
Speed is the only moat
Build rapid feedback loops. The faster you iterate with real users, the better your product will be. Build a prototype in the morning and get user feedback by lunch. Reject doing 3+ rounds of internal reviews before talking to a real user.
Ship to concentric circles. It’s almost always a bad idea to ship a new product to everyone at once. Instead, run staff alphas and customer betas to catch issues and improve quality before launch. I genuinely don't know how to build great products without a community of beta users I can talk to daily.
Small teams ship faster. A team of 4-6 full-stack builders who are empowered to co-create with users will out execute a 50-person org any day. The key word here is “empowered” — if you hire a team of A players, give them the autonomy to listen, ship, fail, and learn with real users.
Iterate with AI first. Everyone now has an AI teammate who’s available 24/7. So work with AI to summarize feedback, draft plans, and improve prototypes BEFORE you meet with your team. Doing the basic AI work ahead of time is now a baseline expectation.
Become the user. I estimate that less than 10% of PMs actually dogfood their product on a weekly basis. Use your product like a first-time user and write a friction log of how annoying the experience is. Nobody is too senior to test their own shit.
Example: Boris (the creator of Claude Code) asked for user feedback on X and got 100s of replies. He then worked with AI to ship dozens of fixes on the spot. He’s the perfect example of a small team (of 1 🙂) iterating fast with real users.
Focus is a superpower
Do fewer things better. I don’t believe in more than 1-3 P0 projects per quarter. Focus on solving the biggest user pain points that grow your business instead of trying to build everything at once. You have to prioritize until it hurts — saying “why don’t we just do both” or listing 5-10 priorities is a red flag.
Do the simple thing first. Always ship the simplest thing that could work and avoid solving problems that don’t exist yet. For example, you probably shouldn’t optimize for scale if your 0-1 product doesn’t have product market fit yet. Keep repeating this mantra to yourself and your team.
Validate your riskiest assumption first. Every product has a few assumptions that, if wrong, will kill the whole idea. Validate these assumptions with real users using a simple prototype or A/B test. Don’t work on secondary features if your core hypothesis remains unproven.
Protect your calendar. Your calendar decides what you actually work on and you can’t build good products if you don’t control your time and energy. I do deep work in the mornings when I have mental clarity and I’m ruthless about declining meetings that drain my energy.
Say no 10x more than you say yes. Get comfortable saying no to features, meetings, and even user requests that don’t align with your highest impact work. Show empathy and explain your rationale clearly — the other party will usually understand.
Example: I once worked at a company where the CPO announced 9 priorities for the year. He even had a great acronym to help people remember all 9 things. A year later, we barely made any progress and he reduced the priorities to 3.
Lack of focus is an extremely common problem in successful tech companies. Anthropic is an example of a company that did it right:
Product > process
Reject PM theater. I’ve talked about how important it is to build feedback loops with real users. But most PMs are focused on internal theater like polishing documents and doing endless pre-meetings before the actual review. Obsess about the product that your users actually use, not your internal artifacts.
Build minimum viable plans. Stop pretending that you know exactly what to build a year from now. Instead, create a minimum viable plan that cover the user problem, vision, goals, principles, solution, and what you’re not doing. Keep it to one page and update it as you learn. Reject annual planning and OKR theater.
Practice prototype first development. Prototypes give people a much better sense of your solution than any slide deck or document. They’re also more fun to build and easier to test with real users. So validate interest with a prototype BEFORE you create your PRD and design.
Obsess about the details. Default states, edge cases, and good copy — these details are what separates a great product from slop. It doesn’t matter how senior you are, you have to give a damn about the tiniest details to ship something that you can be proud of.
Simplify product reviews. Nothing slows velocity like waiting weeks to get on an exec’s calendar before you can ship. If you’re a leader, empower your teams to ship freely to beta users. Review prototypes async instead of blocking them around your busy schedule.
Example: Ramp grew to $32B in record time by empowering their teams to ship fast. As Geoff (Ramp’s CPO) explains in the post below, Ramp teams can ship to beta users at any time. The line that I particularly love is “leadership has 48h to review or it ships.” This puts accountability on execs not to slow down velocity.
Seek the truth
Arrogance is the biggest turn off. I cannot stand product leaders and creators who think they’re better than everyone else. The best leaders I’ve met are also the most humble because they’ve failed before and seen some real shit. If you’re not humble then you’re not listening and you won’t build great products.
Ban decision by committee. I don’t believe in cross-functional alignment as a goal. Trying to make all stakeholders happy will inevitably compromise the product experience. Seek diverse opinions first, then have a single person make the call and own the outcome.
Don’t surround yourself with sycophants. Great companies decay when leaders surround themselves with people who won’t challenge their ideas. Find and reward the people who are willing to ask hard questions. If everyone’s nodding along in your review, that’s a bad sign.
Assume good intent. When you disagree with someone, listen to understand instead of to defend your opinion. Chances are they’re making a great point you haven’t considered. The best debates are collaborative truth-seeking exercises, not battles to be won.
Be willing to be wrong. Most decisions are reversible two-way doors. The right move is often to just decide and learn instead of waiting for perfect information. I love this quote from my interview with Yana: “By the time you’ve debated 2 ideas, I’ve already shipped 10.”
Example: Recently at work, stakeholders pushed for a feature I resisted for weeks. But I kept an open mind by talking to users and testing different prototypes. Eventually, these feedback loops changed my mind. I admitted I was wrong, showed the evidence, and now we’re building something we’re confident about. The goal is to find the truth, not to prove you’re right.
Builders > bureaucrats
Hire builders, not bureaucrats. Look for people who genuinely care about crafting great products instead of people doing it to climb the career ladder. Find people who have that “just figure it out” energy — the willingness to wear multiple hats to solve problems instead of waiting for permission.
Proof of work > credentials. Nobody cares about your FAANG pedigree or AI product certificate. Hire high agency people who have built great side projects or demonstrated proof of work. The only credential that matters is what you’ve shipped and your ideas to improve the product.
Hell yes or no. If you’re not excited about a candidate, don’t hire them hoping they’ll work out. One great hire beats three mediocre ones. Never lower the bar because you’re desperate to fill a role.
Your job title doesn’t matter. The best teams blur the lines between PM, design, and engineering. I love when engineers update my spec directly and designers let me tweak copy in Figma. Build a team of full-stack builders who trust and respect each other’s craft.
Replace yourself. Your job as a leader is to make yourself unnecessary. If your team can’t function without you for a week, then you’ve failed as a leader. The best leaders empower others so they can move on to new problems.
Example: I’m hiring for a senior PM right now, and I explicitly wrote in the job description to link your best side project or shipped work. I hate seeing vague jargon like “Agile expert” or “strategic product leader.” That stuff is meaningless. Just start with what you shipped and what the impact was.
So there you have it — 25 things I believe in to build great products.
Write down your own list and work for companies that share the same values and principles. It’ll make your life much easier, I promise.
For more, watch my 12-minute video and check out my 40 life lessons I know at 40 that I wish I knew at 20. Here’s a handy infographic with all 25 things I believe in:
Really great list. I am struck by how much it translates to my former career in an architectural firm.
Great read! As a PMM interested in learning the PM side too, I loved the practical lessons.