25 Things I Believe In To Build Great Products in 12 Minutes

Hey everyone, I've spent over a decade as a product leader at companies like Meta, Amazon, Reddit, and Roblox. Here are 25 things that I believe in to build great products. And the funny thing is that what I believe in is often the opposite of how big companies like to work. All right, let's get started.

First, speed is the only moat. Number one, build rapid feedback loops. The faster you iterate with real users, the better your product will likely be. You should be able to build a prototype in the morning and get user feedback by lunch. You should absolutely reject doing three rounds of internal reviews before talking to a real user. Number two, ship to concentric circles. You know, it's almost always a bad idea to ship a new product to all your users at once. Instead, run staff alphas and customer betas to catch issues and uplevel quality before launch. I don't actually know how to build great products without a community of beta users who can talk to every day to get feedback. Number three, small teams ship faster. A team of four to six full stack builders who are empowered to co-create with users and learn from failure will out execute a 50 person org any day of the week. The key word here is empowered. If you hire a team of A players, you have to give them the autonomy to iterate relentlessly with real users. Number four, iterate with AI first. Everyone now has an AI teammate who is available 24/7. So work with AI to summarize feedback, draft plans, and improve your prototypes before you meet with your team. Doing the basic AI work ahead of time is a baseline expectation at this point. And number five, become the user. I can't believe I have to say this, but you have to dog food your own product constantly. Use your product like a first-time user and write a friction log of how annoying the experience is. I estimate that less than 10% of PMs actually dog food their own product on a weekly basis. You know, nobody is too senior to test their own Okay, so to bring these five principles to life, I want to share a quick example. Boris is the creator of clock code and he recently asked for user feedback on X and got hundreds of replies. And the most remarkable thing was he not only responded to each of his replies, but he also worked with the AI to ship dozens of fixes on the same day. Boris is a perfect example of a small team of one person in this case iterating fast with real users. Speed is everything. Okay, the next section is

focus is a superpower. And let's keep going on the list. So number six, do fewer things better. I don't believe in pursuing more than one to three P 0 high priority projects per quarter. Focus on solving the biggest user pain points that grow your business instead of trying to build everything at once. You know, saying we can do both or listing five to 10 priorities for your team or even company is a red flag to me. Number seven, do the simple thing first. Always ship the simplest thing that could work to avoid solving problems that don't exist yet. For example, you probably shouldn't be optimizing for scaling your product if it hasn't even reached product market fit yet. Right? So, speaking of which, number eight, validate your riskiest assumptions first. Every product has a few assumptions that if wrong will kill the whole thing. So, validate these assumptions first with real users using a simple prototype or AB test before you build anything else. Don't work on secondary or peripheral features when your core hypothesis remains unproven. Number nine, protect your calendar. You can't build good products and you can't focus if you don't have control over your time and energy. I like to do deep work in the mornings when I have mental clarity and I'm ruthless about declining meetings that drain my energy. Number 10, say no 10 times more than you say yes. Get comfortable saying no to features, to meetings, and even user requests that don't align with the most important problems that you want to solve. Just be sure to show empathy and explain your rationale clearly. The other party will usually understand if you do this. Okay, so as an example, I once worked at a company where the CPO announced nine priorities for the year. He even had a great acronym to help people remember all of these nine priorities. After barely making progress on any priority for a year, he reduced the list to just three. Here's a quote from Richard Rumount, who is a professional of strategy on what good strategy is actually about. At the core, strategy is about focus. And most complex organizations don't focus their resources. Instead, they pursue multiple goals at once, not concentrating enough resources to achieve a breakthrough in any of them. So, focus your priorities, focus your time. Focus is the key to achieve a breakthrough product. All right, moving on. The next section is

product over process. And let's start with number 11, which is reject PM theater. You know, 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. You have to obsess about the product the users actually use, not about your internal artifacts. I know it's hard, but try your best to do this. Number 12, build minimum viable plans. You know, stop pretending that you know exactly what to build a year from now. Instead, create a minimal viable plan that covers 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. Number 12, practice prototype verse development. You know, 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. You can use tools like Google AI Studio, Replet, Cursor, all these different tools to build a prototype of your product first and most importantly, show it to stakeholders and real users for feedback. So validate interest with a prototype before you create your PRDN design to cover a bunch of the edge cases. All right, speaking of edge cases, number 14 is obsess about the details, default states, edge cases, and writing 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. Number 15, simplify product reviews. You know, nothing slows down velocity like waiting weeks to get on an executive's calendar to review your work before you can ship. So, if you're a leader or exec, empower your team to ship freely to their beta community and review prototypes async instead of blocking them around your busy schedule. As an example, RAMP grew to $32 billion in record time by empowering their team to ship fast. As Jeff Ramp's CPO explains in this post, RAM teams can ship to beta users at any time without an exact permission. And they also have a minimal review process before they can ship to general availability. The line that I particularly love in this tweet is leadership has 48 hours to review the product or it just ships. This puts accountability on the leaders and the execs not to slow down product velocity.

Next section is really important. You have to be ruthlessly truth seeeking. Number 16. You know, arrogance is the biggest turnoff. I cannot stand product leaders and creators who think they're better than everyone else. The best leaders that I've met are also the most humble because they failed repeatedly before and they've seen some real If you're not humble, then you're not listening and you won't build great products. Number 17, ban decision by committee. I don't believe in uh cross functional alignment as a goal because trying to make all stakeholders happy will inevitably compromise the product experience. So definitely seek diverse opinions from the stakeholders and real customers but then have a single person make the call and own the outcome. Don't try to do decision by committee. It never works. Number 18. Don't surround yourself with single fence. Great companies decay when leaders surround themselves with yesmen who won't challenge their ideas. Find and reward people for willing to ask the hard questions as long as they stay constructive. You know, if you have a product review and everyone's silent and just nodding their heads, that's actually a bad sign. You want to encourage debate. All right, number 19. Assume good intentions. When you disagree with someone, listen to understand what they're saying instead of trying to formulate a rebuttal. Chances are they're actually making a great point that you haven't considered. The best debates are collaborative truth seeeking exercises, not battles to be run. And number 20, be willing to be wrong. Most decisions are reversible two-way doors. And the right move is often to just decide and learn instead of waiting for perfect information. I learned this quote from my interview with Jana. By the time you've debated two ideas, I've already shipped 10. Don't wait for perfect information. Just launch and be willing to be wrong. So, as an example, recently at work, a few stakeholders pushed for a feature that I resisted for weeks. But I kept talking to users and showing them prototypes anyway. And eventually the feedback from the users and the stakeholders changed my mind. And I admitted that I was wrong. I showed the evidence why. And now we're building something that we're more confident about. The point is your goal should be to find the truth, not to prove that you're right all the time. All right, the last section I feel

especially strongly about and that is builders over bureaucrats. Look for people who generally care about crafting great products instead of people who are just doing it to climb the career ladder. Also try to hire people who have that just figure it out energy. They're willing to wear multiple hats and solve problems instead of waiting for permission. Number 22, proof of work is greater than credentials. You know, in this day and age, people don't care about your fan pedigree or AI product certificate. I want to hire people who have built great side projects or demonstrated high agency in some way, shape, or form. The only credential that matters is what they've shipped. What was the impact that they made and what are their ideas to improve your product? Number 23, hell yes or no. If you're not excited about a candidate, don't hire them hoping that they'll work out. One great hire beats three mediocre ones. And never lower the bar because you're desperate to fill a rope. Number 24. Your job title doesn't actually really matter. The best teams blur the lines between PM design and engineering. I love it when engineers update my spec and when designers let me tweet copy in Figma. Build a team of full stack builders who trust and respect each other's craft. And last but not least, aim to replace yourself. Your job as a product leader is to eventually make yourself unnecessary. If your team can't function without you for a week, that's actually a failure, not a flex. The best leaders empower others so that they can move on to higher order problems. So as an example, I'm hiring a senior PM right now and I explicitly wrote in the job description to link your best side project or ship product at the top of your application. Now what I really dislike is seeing vague jargon or buzzwords like agile expert or strategic product leader. That stuff is really just meaningless to me. Just start with what you shipped and what the impact was. All right, so there you have it. 25 things that I believe in to build great products after over a decade working at some of the best companies. And if you like this list, I encourage you to write down your own and find and work for companies that share the same values and principles as yourself. It'll make your life much easier. I promise. All right. So, if you enjoyed this quick video, please like and subscribe to my channel, and I'll share more personal product takes and AI tutorials along the way. Thank you.