Peter Yang’s 10 rules for making products that customers love

Mastering the craft that makes products stick

Peter Yang, a product lead at Roblox with more than a decade of experience, argues that the most effective product managers share a common characteristic: a relentless focus on the craft. In his view, this dedication to the details of building and shipping is what separates a good product leader from a great one.

Yang’s philosophy is grounded in the idea that product management is not just about coordinating teams or ticking off roadmaps. It is about developing a deep, personal understanding of the problem space and the user. This requires a hands-on approach that goes beyond delegating tasks—it involves direct engagement with the design, the data, and the feedback loops that shape the user experience. This mastery is what allows a PM to make the tough, autonomous calls that most impact customer satisfaction.

Ten rules for building with intention

Drawing on his career, Yang distills his approach into a set of actionable principles. These are not abstract ideals, but practical shifts in how a PM spends their time and where they place their attention.

• Quality is a team culture, not a checklist. High standards must be defined by tangible examples, not just slogans. A team needs to see what "great" looks like to replicate it.
• Sweat the details. A near-perfect experience beats a broad but shallow feature roll-out. Fixing the small interaction flaws is often where loyalty is built.
• Resist the feature treadmill. Addition is easy; focus and clarity are the real challenges. A clear, differentiated strategy guides better decisions than a long list of asks.
• Invent from user pain. Avoid generic or "safe" ideas when solving a problem. Go to the root of the user behavior to find a highly specific and memorable answer.
• Make time for the deep work. Innovation requires uninterrupted focus. Protecting blocks of time ensures you are experiencing the product and synthesizing rather than just executing.
• Understand the economics of your user. Acquisitions and activations attract a lot of attention, but sustainable success depends on shipping value. A PM must always be honest about the actual cost of a build against the value it returns.
• Use the product daily to stay sharp. Seeing the product through the eyes of a user is a discipline. The best insights come from feeling your own metrics, not just reading them.
• Create a bias for direct feedback. Hiring seniors and "tell-me-whats-broken" reviews encourage openness over politeness. Product maturity comes from a culture that fights for truth over comfort.
• Set the vision by writing. Words create a shared story for the team. A sharp, written strategy forces alignment better than a hundred slide broadcasts.
• Expose yourself to the best work in your field. Just like any designer or engineer, a PM must study the best-in-class products and breakdown what makes them great.

The core of the role is stewardship

Yang points out that the modern PM role often has a problematic reputation, involving low-level coordination that rarely satisfies the desire to create something impactful. To counter this, a PM should reject the role of a program manager and instead act like a mini-CEO of the product—taking full ownership of the experience the user has. When you care about the business outcomes, the team well-being, and the user's perception, you solve the friction points that usually drain the energy out of a project group.

Product is made of hundreds of everyday decisions. Therefore, the greatest value is found in the craft of honing judgement. This involves asking the hardest questions about definition, scope, return on investment, and risk in every project, no matter how mundane. When applied consistently, these habits create the velocity and quality needed to deliver products that earn enthusiastic use.

Product sense is a practice, not a trait

Jules Walter, a Google product leader, defines product sense as “the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users.” It is often described as one of the most valuable skills a PM can have. But the framing is misleading in two ways: it sounds intuitive, and it implies you can build it once and keep it forever. Both are wrong. Markets and customer needs shift constantly. Product sense requires ongoing cultivation through empathy, creativity, and craft—and the humility to keep improving all three.

Start with the customer problem, not the solution

The urge to jump straight to vision or solutions is strong, but resist it. Diagnose the customer problem first. As Tony Fadell, former Senior Vice President of Apple’s iPod division and co-founder of Nest Labs, puts it: “A PM’s superpower is empathy.” You build that empathy by treating customers like team members. A simple exercise: spend an hour—or a day—using your product exactly as a customer would. That perspective is the foundation for everything that follows.

Only after diagnosing both customer and business problems should you think big. Don't rush into day-to-day execution. Huddle with your team to brainstorm blue-sky ideas and shape the mission, vision, and strategy. Prioritize, then land on a simple solution—say, a three-step plan—that best serves customer needs. Be ready to make trade-offs and shift priorities as you learn more.

The value of quality can mean missing a milestone

Quality often demands hard trade-offs. In one past role, Peter’s team had an OKR to improve a metric by shipping a feature within a quarter. Customer conversations revealed that adding an extra feature would significantly improve the experience—but there wasn’t time to hit the original deadline. They chose to miss it. That extra feature turned out to be what customers cited as making all the difference.

This is where craft comes in: going the extra mile, obsessing over details and trade-offs, and treating stakeholders as partners who understand that short-term misses can serve long-term success.

Sometimes the right call is to change direction entirely. At Reddit, Peter worked on Reddit Talk, a live audio product with millions of devoted users. But when the economy turned, the project was cancelled because it didn't move the metrics that mattered to the company. That requires stepping outside the product bubble to ask, “Is this the most important thing for the company to work on right now?” Looking back through Coda co-founder and CEO Shishir Mehrotra’s PSHE framework, Peter acknowledges he had the solution, execution, and customer problem right—people genuinely want to gather live—but missed the business problem.

Let AI handle the busywork

A PM’s job is not to craft the perfect OKR doc or product review deck. Those are means to an end. When you spend as much time on intermediate artifacts as on the product itself, step back. Delegate or automate. AI won't produce original thinking, but it excels at synthesis and summarization. Peter uses FigJam AI to clean up brainstorms and AI to condense customer feedback and sharpen product requirement docs.

PM work is, in many ways, prompt engineering already—communicating in ways that empower teams and stakeholders. AI just makes that easier.

Small teams and broad skills are winning

Between tighter budgets and AI-driven productivity gains, the job market increasingly favors builders over managers. That favors PMs who can work across functions: write copy, prototype, and understand growth. The individual contributor PM—someone who delivers without managing reports—is gaining importance, much like technical architects on the engineering side. Smaller teams move faster. Large teams are out of fashion.

Your superpower has a shadow side

Meta’s Vice President of Product, Nikhyl Singhal, notes: “Every superpower also has a weakness that needs to be addressed to advance your career.” A great storyteller may avoid details. A natural entrepreneur may struggle to delegate. These are the shadows of your strengths, and left unchecked, they can stall your career.

You can’t fully eliminate a shadow—it's part of what gives you your edge. But you can be public about it. Own it openly in front of your team: “I’m not always right, and you should disagree with me.” This transparency invites direct feedback instead of behind-the-scenes critique, which helps you manage the trait rather than let it manage you.

Bring customers into your workflow

The most direct path to customer empathy is making customers part of your team. Recruit a few dozen early adopters, mixing beginner, intermediate, and advanced users, who will give passionate feedback and eventually evangelize the product. Then put this community-led framework to work:

• Create a community. Announce your product early and invite these customers to an online channel—Slack or Discord—where they build trust as they introduce themselves.
• Build in public. Share designs and ideas early. Ask about pain points, run demos, and show how feedback shapes the roadmap.
• Build a casual environment. Make it easy for customers to talk about anything. Off-topic discussions often surface the most useful product insight.

Decide asynchronously to protect craft time

Great async decisions save teams from meeting fatigue—nobody dreams of a day full of Zoom calls. Peter’s approach:

• Identify key people. One decision maker, a couple of stakeholders.
• Use one decision doc. Keep all discussion in the doc or a dedicated Slack channel, and tag the relevant people.
• Set context. Describe the decision, your recommended option, and trade-offs in under two pages.
• Number the discussion. Numbered lists let people say “I prefer option three because…”.
• Push for a decision and share it broadly. Something like: “Sounds like people prefer option one. Any strong objections?”
• Meet when necessary. If the decision is ambiguous, hard to reverse, or the discussion stalls, it’s meeting time.

Remember the original why

Most PMs entered tech to craft experiences that exceed customer expectations. Yet competing demands—stakeholder pressure, OKRs—can obscure that goal. Not everyone needs to manage a 200-person org or climb to the top of the ladder. Peter's reminder, speaking for many in the field: he joined tech to build products customers love, and he never wants to lose sight of that.

Shared tools beat shared opinions

When a whole team can gather around the same artifact, debates stop being about who argues best and start being about what the work actually shows. Figma does this well because it puts the source of truth in one place: the design file.

The practical benefits go beyond pretty mockups. With Figma, you do not need to export screenshots, re-upload them, or worry about whether someone is looking at the latest version. Everyone works from the same link, which means feedback is anchored to something real.

How that changes collaboration

Product teams often struggle not with a lack of opinions, but with opinions that are stuck in different formats: a PDF here, a slide deck there, a whiteboard photo from a workshop. Each format creates friction. Figma removes the format problem by design. What you see in the browser is the actual source file, not a flattened copy.

That single-file model has ripple effects. A developer can inspect a layout and pull spacing, colors, and type values directly. A PM can leave comments on a specific element rather than describing it in a wall of text. A founder can jump in, react, and steer the direction without waiting for a formal review meeting.

The result is that collaboration moves from a meeting-centric rhythm to a continuous, artifact-centric one. The artifact becomes the shared language, and the team travels at the speed of trust in that file instead of the speed of availability on a calendar.

This holds for more than screen design. Figma handles prototyping and design systems in the same ecosystem, so the file that starts as a simple layout can grow into a living specification. The tool scales with the team’s ambition, not against it.