principles /
Product Management
product management

The 5 top principles I've learned PM'ing at my own startup. Developed from interviews, plenty of reading, and heaps of personal experience (hint: making mistakes).

Eyes on the Prize

In my experience, the first responsibility of a Product Manager is to make sure that all decisions lead back to first principles. In other words, resources—whether they be time, effort, or passion—are finite. They've got to align with the things that matter most.

Eyes on the prize

Most organizations live by a set of first principles, ranging from poetic to performative. For example:

  • Google's mission statement is to "organize the world's information and make it universally accessible and useful."
  • Amazon's core values are 1) customer obsession, 2) eagerness to invent, and 3) long-term orientation.
  • Facebook's "north star" goal was to have people add 7 friends in 10 days.
  • A common startup KPI is: increase the DAU/MAU ratio for each cohort.

Whatever your organization is, your team should be able to draw a string through every decision, through shared objectives, back to your first principles.

Threading the decisions

Of course, underpinning any company's values, whether they be poetic or scientific, is a fundamental goal: market success. So it goes without saying that any PM should intimately understand the customers and advocate on their behalf. I've listed some methods for doing this here.


OK, we've done our best to align our decisions with first principles. Now we've got to prioritize our tasks to make sure that the important stuff makes the cut, gets built on time, and gets built well. For this I've learned a few rules of thumb:

Start with "Nope!"

In the beginning Rod created a feature idea. Now the new feature was formless and empty, hot pink was over the surface of the sticky note, and the Spirit of Rod was hovering over the table. And Rod said, "Let there be nope! NNNOPE!!"

No no no

Start with "Nope!" and set a super high bar for what gets specced. One thing I learned the hard way was how impactful new features could be. Not only do they have ripple effects across the system (complexity multiplies, like rabbits), but they must also be supported indefinitely.

Features are like children. They're conceived in a moment of passion, but you must support them for years. - David Golden

Plus, designers like to say, "your first idea is probably your worst idea." There are a dozen bad ideas for every good one—and your challenge is to invest in the great ones. Having tough and well-defined criteria for evaluating them is your bulwark against costly decisions.

Find the Key Variables

You might have heard of the Pareto Principle, or the 80/20 Rule. It's a simple heuristic drawn from the tendency for things to be unevenly distributed. For example, 80% of the effects come from 20% of the causes, or 80% of the user satisfaction comes from 20% of the features. It's imperative to find these key variables and give them the attention that they deserve.

Define Your Criteria

Your prioritization criteria will be different depending on the focus of your organization and the phase of its development, so I won't be able to get specific here. But I've made you a couple of charts below (I ❤️️ charts) for inspiration.

This is the first PM-related chart that I came across when building my startup. You simply plot prospective features along its axes and go with the ones in the upper right.

Easy + core value proposition wins

Intercom's Product Management document provides some great insight on how to evaluate the nuts and bolts of your product. The following depicts a standard features audit:

Features audit (inspired by Intercom)

Features that are used all the time, by all people are fundamental. Even marginal improvements to them yield considerable results. Most interesting are the features that are used all the time, by only a few people. Clearly, they're important to someone, though not at enough scale to keep supporting. But there's potential—these features might just need a few tweaks to unlock mainstream adoption (or even unlock an untapped market).

I love how this one buckets features into quadrants:

Inspired by Intercom

"Delightful Features" in the lower-right quadrant, such as chat stickers and photo filters, are easy to build and make customers happy. They can be scheduled out at regular intervals (particularly when doing behind-the-scenes work like refactoring) to keep the positivity going.

Once you've figured out what to prioritize, the act is pretty simple to do. Simply rank each feature must have, should have, or nice to have, then sub-rank them in each group from one to n.

  • Must have - 1) If I don't have this feature I will die, 2) I'll die without this, too, but less painfully
  • Should have - 1) This would make a huge difference but I'll probably live
  • Nice to have - 1) Awesome but not mission-critical, 2) Bees knee's, 3) Neato mosquito

And of course, if something isn't earning its keep, don't be afraid to cut it.

Mad Communication

The third key role of Product Management is to promote good communication between all people involved.

The first principle of communication isn't articulation, it's listening—it's figuring out how each party thinks and feels. So I try to approach every interaction with a mindset of humble inquiry, knowing full well that I can learn from the person sitting across from me.

Always a beautiful answer who asks a more beautiful question. - E. E. Cummings

Plus, the more I understand someone, the more I can speak to them in their own language, which leads to better outcomes when I do have something to say. Below are are three spectrums of communication that I believe should be cultivated:

Between You and the Team

Clear, concise, and comprehensive is the name of the game here, with the primary focus on the "whats" and the "whys" of the matter:

  • This is why we're here
  • This is what needs to be built, and this is the experience it should create
  • This is why it needs to be done
  • This is the customer for whom its being done
  • This is the timeframe in which it should be done
  • This is the context we need to know
  • These are the dependencies, constraints, and obstacles, etc.

...Are all in the domain of the Product Manager. Less so are the "hows," which are the domain of the engineers and designers that you work with (who are 100x better than you at their jobs, anyway).

Over time, I've gained a stronger appreciation for writing as a medium of communication, whether it be a Product Requirements Document (PRD), FAQ, wiki, or blog post. It's consistent across parties, raises accountability—and most importantly, promotes clear and structured thinking. Just write in a way that people will tolerate reading 😛 (hint: in their own language, starting with "human"). Here is a handy guide for writing a good PRD.

Between Teammates

PMs serve as communication "conduits" between disparate parties—gathering all the insights and perspectives, extracting meaning from them, and disseminating it in ways that people can understand (this is called sensemaking in business terminology).

This is quite valuable, but I think PMs can go a little further; they can promote shared understandings not just about business concerns, but about each other, too. What makes the folks with the different job titles tick? How does the person sitting next to you prefer to work? How can we help make each other's lives easier? The answers to these questions can make a huge difference.

Also, sometimes sensemaking breaks down when novel or ambiguous situations come around, and faith in one another will be all you'll have to work with.

Between the Team and Customers

In technology companies, the vast majority of decision-making is done autonomously, among the highly competent product builders. So the more understanding you can cultivate between them and customers, the better your outcomes will be.

There's so much more you can do than just paste personas in a document, such as involving teammates in the user research process. A few companies have even gone further, mandating that every employee spend a percentage of their time on customer support. Somewhere in there is a healthy approach that can be found.

Process Matters

A mid-level manager once told me, "I'm not a process guy. I just go with the flow." Balderdash, I say! There's certainly merit to adaptability—but if you could build good habits that improve your team's likelihood of success, why wouldn't you?

There are two categories of systems that I generally focus on: operational excellence and better decision making.

Operation Excellence

These are the systems that help you get things done faster, more efficiently, and more intelligently.

Being part of a startup, my team and I automatically fell into an "Always Be Shipping" mentality (ABS, as coined by Seth Godin). Time was money, and if we ran out of money we died—so we were always in a hurry to build something, to get more traction, to justify another round of financing. We didn't have the luxury to sit around writing research papers.

By far the best results we've gotten are from Scrum, a framework for implementing the philosophies of Agile Development. The rationale behind Agile is pretty simple: since most of today's problems are complex and unpredictable, you've got to iterate quickly and empirically to succeed. Scrum is a process that helps you do just that. Here's a quick rundown:

Instead of taking boatloads of time to plan and ship product releases, you ship at regular intervals called Sprints. Sprints are maximum one month long, and a usable product improvement, called an Increment, needs to be delivered at the end of each one.

To begin, simply divide a whiteboard into three columns:

  • Product Backlog - A list of everything the Development Team needs to build for the product, ordered by importance (be sure to include details such as "estimated time" and "value" for each item). This list constantly evolves as time goes on.
  • Sprint Backlog - A list of the items the Development Team will tackle during the Sprint, broken down into simple tasks.
  • Product Increments - All the Backlog items that are finished and usable.

Then pick a few roles:

  • Product Owner - The person accountable for keeping the Product Backlog well-defined and well-prioritized. She determines "what" needs to be built.
  • Scrum Master - The person who makes sure the Scrum process is well-understood and well-followed (if any parts are ignored, the whole process might break down).
  • Development Team - The butt-kicking creators of the product. All the functions (e.g. design, engineering, marketing) are in a single team, ranging between 3 and 9 members. They get the last say in "how" things are built.

Then just follow this simple process:

  • On the first day of each Sprint, have a Sprint Planning Meeting - Define the goal of the Sprint, then figure out which items from the Product Backlog can be delivered within the Sprint's timeframe by moving them to the Sprint Backlog. Once this is done, break down the Sprint Backlog items into manageable tasks (can be completed within one or two days).
  • At the beginning of each day, have a Daily Scrum (sometimes called "stand-ups") - A quick, 15 minute meeting where each team member says 1) What they did yesterday to help meet the Sprint goal, 2) What they will do today, and 3) What impediments or dependencies are in the way. They might then edit the Sprint Backlog in response to new insights.
  • At the end of each Sprint, have a Sprint Review - Demo the new increment to all stakeholders, discuss the broader context of the product (such as market changes, user feedback, and company direction), and update the Product Backlog accordingly.
  • Then right after that, have a Sprint Retrospective - Discuss the process itself—such as how people, relationships, tools, and techniques could be improved. Then prioritize and plan how such improvements could be made during the next Sprint.

That's it! Rinse and repeat! You can download the official Scrum guide here for further reading.

Better Decision Making

These are systems that help you and your team make better, more informed decisions. This area is a bit fuzzier than the above—it does require tailoring to the specific people and situations involved. However, a few bases are frequently covered:

  • Adopting multiple perspectives - There are many forms of this. The customer's perspective can be adopted through ethnography, user interviews, or customer service (or at the very least, the proper use of personas and user journeys). Role-playing is a fantastic way to step into the shoes of competitors—or even colleagues with different points of view. And inversion, the mapping of "what not to do" (similar to pre-mortem analysis) is excellent for minimizing failure.
  • Generating good ideas - The best way to generate good ideas is to generate many ideas. A system should be in place for the free, non-judgemental sharing of ideas—no matter how wild or contrarian they are. They should also be treated in a way where biases (particularly confirmation bias) and personal attachments to them are minimized.
  • Promoting high-quality debate - Ideas aren't useful without a good system for evaluating them. Yes, they should be tied to core principles and stress-tested in the real world. But they should also be poked and prodded via healthy, constructive dissent. Known as dialectical inquiry, this promotes a more balanced and thorough understanding of any given idea. Some common techniques include: devil's advocate roles, bringing in outside experts, and splitting into temporary subgroups that are focused on different variables.
  • Facilitating a fair, legitimate process - One where everyone is heard, well-informed, and part of a common goal. All too often folks are either left out of the decision-making process or subject to a symbolic process that only has the appearance of involvement. But people can see right through this. Without buy-in, execution (the other 90% of the work) suffers.
People Matter Most

Ideas and people should never be conflated. While the former should be twisted, torn apart, tested, and tossed away—people should be treated with an unwavering standard of tolerance and care.

No idea is above scrutiny and no people are beneath dignity. - Maajid Nawaz

I still feel like a newbie when it comes to people, and I'll spend the rest of my life learning, bit by bit, how to treat them better, but here are a few thoughts I can share:

Different People are Different

This seems like common sense, but it's sometimes surprising how different people can actually be. Some tire out from raucuous social interactions, others feed off of them; some are spontaneous and risk-taking, others prefer rules and predictability. It's just so important to notice and be responsive to the idiosyncratic needs of your team.

For example, if you've got an introverted teammate who easily gets drowned out by her A-type colleagues, you might consider giving her the meeting agenda a day before the meeting itself, then let her present first when the meeting begins.

Productivity needs can be different between people as well. Paul Graham once compared "manager schedules" and "maker schedules," with the key difference being that managers change what they're doing every hour or so (as they juggle meetings and tasks), while engineers and designers need 4 to 5 hours of uninterrupted time to do any significant work. Scheduling something in the middle of a maker's concentration period can really harm her productivity. You're in the meetings, representing the folks who aren't there, so they don't have to be.

With all this being said, I still believe it goes a long way to start with a good team composition—folks who are culturally in sync while still bringing diverse dispositions, perspectives, and skillsets to the table. And sometimes, despite your patience and attention, you might find that a bad apple is just a bad apple. Bad apples can spoil the entire bag, so you should remove them as quickly as possible (or at least minimize the damage).

Tend to Emotions

In the previous point, I wrote about promoting constructive dissent to evaluate ideas. This is referred to as cognitive conflict and can greatly improve decision-making. Yet lurking in the shadows is its evil doppleganger: affective conflict—the kind where people hold grudges against one another. Sour emotions can be very dangerous and should be tended to right away.

Watch out for affective conflict!

Let's say your team just had a particularly heated discussion: You might take everyone out to lunch right afterwards, paying attention to the people who were most bruised. Or perhaps a 1-on-1 in the afternoon might be more appropriate. Whatever it is, the key is to be prompt.

On the flip side, positive emotions should absolutely be nurtured. Be sure to distribute the credit and celebrate the wins, however large or small.

Trust is Everything

Ah, my final and perhaps most salient point: Paramount to any team is a shared sense of safety. In other words, a trust that enables each and every person to take risks, admit they don't know, and speak with candor without fear of denigration.

This was confirmed several years ago by Google's Project Aristotle, which ranked psychological safety as the most important determinant for team success, above other factors such as dependability, structure, meaning, and impact.

A wonderful exercise to help build trust is the Reciprocity Ring, developed by Wayne and Cheryl Baker (from U. Washington and Humax, respectively). It's super easy to do:

  1. Draw a circle on a whiteboard, then scribble a dot along its circumference for each participant (or sit in a circle formation for a more informal session).
  2. Then go around one by one, having each participant express a specific goal to the group—ideally, something that isn't easy for the participant to do themselves. For example, someone may state "I'd love to start learning piano" or "I'm looking for a new apartment." The group then tries its best to help fulfill that goal.

Reciprocity Ring

The purpose is not to have your goal fulfilled, but to help your colleagues achieve theirs. This builds altruism and reciprocity while also combatting the stigmas that frequently come with asking for help.

Most of us wear fears upon fears, like layers against the cold, so getting to safety takes time. - Chris Voss

This kind of trust is cultivated bit by bit, one good interaction at a time, but can be torn down in an instant. As leaders of any sort, we are the stewards of this fragile bond—and thus we must not only keep a watchful eye, but also do the internal work to ensure that we embody the values that we preach.


That's all I've got for now. If you made it this far, thanks for reading...and huge props for your patience! Hopefully you found something useful 😀.

This page, like all of my Principles pages, is a living document. I'll update it as I continue to learn and would love to hear any feedback you might have. Feel free to get in touch (for any reason) at Cheers!