principles /
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).
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).
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.
Most organizations live by a set of first principles, ranging from poetic to performative. For example:
Whatever your organization is, your team should be able to draw a string through every decision, through shared objectives, back to your first principles.
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:
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!!"
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.
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.
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.
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 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:
"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.
And of course, if something isn't earning its keep, don't be afraid to cut it.
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:
Clear, concise, and comprehensive is the name of the game here, with the primary focus on the "whats" and the "whys" of the matter:
...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.
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.
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.
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.
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:
Then pick a few roles:
Then just follow this simple process:
That's it! Rinse and repeat! You can download the official Scrum guide here for further reading.
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:
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:
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).
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.
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.
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:
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 hello@scottliang.com. Cheers!
