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

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.

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

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

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

feedback. Number three, small teams ship faster. A team of four to six full stack

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

the week. The key word here is empowered. If you hire a team of A

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

real users. Number four, iterate with AI first. Everyone now has an AI teammate

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

the user. I can't believe I have to say this, but you have to dog food your own product constantly. Use your product

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

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

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

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

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

first. Every product has a few assumptions that if wrong will kill the whole thing. So, validate these

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

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

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

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

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

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,

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

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

slop. It doesn't matter how senior you are. You have to give a damn about the

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

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

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

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

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

products. Number 17, ban decision by committee. I don't believe in uh cross

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

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

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.

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

run. And number 20, be willing to be wrong. Most decisions are reversible

wrong. Most decisions are reversible two-way doors. And the right move is

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

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

anyway. And eventually the feedback from the users and the stakeholders changed my mind. And I admitted that I was

my mind. And I admitted that I was wrong. I showed the evidence why. And

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

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

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

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

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

Figma. Build a team of full stack builders who trust and respect each other's craft. And last but not least,

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

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

your application. Now what I really dislike is seeing vague jargon or buzzwords like agile expert or strategic product leader. That stuff is really

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

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.