The Slightly-More-Than-Ten Commandments of Product Management

Over the years I've consumed a lot of Product Management literature and content in order to sharpen my skills and better understand how successful products are built. Not to mention the daily reality of working with different clients and software teams has provided me with plenty of lessons on best (and sometimes worst) practices. As the ideas started piling up I wanted a place to collect all this knowledge and also use this as an opportunity to reflect on my own beliefs about successful Product Management. So think of this page as a Product Management bible or just a list of principles I think are crucial to keep in mind. I'll continue to update this page as I find more meaningful or useful resources in my work, but please reach out if there's anything you think I should include or adopt!

Underpromise and Overdeliver

This rule is important for any job but essential for Product Management. Most people are terrible at estimation, so a good PM accounts for this while doing everything they can to estimate development work as accurately as they can with the information currently available. Underestimating your development capabilities has its own problems, but I believe that is a much rarer problem. Overestimating that workload can lead to strain and burnout for the entire team as well as whatever cost comes from failing to meet the expectations of your leadership team. There will always be more work to do but if you fall behind schedule once it can be extremely difficult to shift the paradigm that your team, both internally and externally, is constantly struggling to catch up.

Prioritization is Hard. Keep in Mind that your Product was Built to Solve a Core Problem

I used to work at a company providing SaaS for restaurants. One of my favorite managers there would always remind us that at its core our software was a printer and a calculator. If our software couldn't reliably send orders to a kitchen printer and add up the bill no one would care what else it could do, regardless of any fancy features, integrations, or add-on products we added. No matter what kind of software you're working on or its complexity, that product was originally built to address a specific problem for its customers. This isn't to say that your product shouldn't solve other problems over time, offer features that don't focus on this core problem, or maybe even shift entirely in its aims. But I think any product development plans should always keep that core problem in mind. It will make prioritization easier. Not easy, but definitely easier.

Avoid Side Quests at All Costs (aka Saying No Strategically)

Every stakeholder and they can run the gamut: major integration needs, niche feature requests, tiny little bugs that have very minimal impact but high visibility. The list goes on and on. You won't ever be able to address everyone's needs, so learning to say no early and often is a necessary part of effective Product Management. I think a sign of a good PM is that everyone is at least partially dissatisfied with your product roadmap. But that being said, a great PM is able to recognize where they can fold as many of these side quests into their roadmap as possible. To do that you need to know and understand your product inside out, from every single stakeholder's vantage point, and stay on top of your product roadmap. Otherwise you'll end up trying to cram needless features or inefficiently consolidated work into your roadmap and the cost will be time you already can't afford to lose.

Treat Your User Stories Like a Data Lake

This tenet is in a similar vein to avoiding side quests, but more about drowning out the noise on a macro level. As a PM you will be inundated with all kinds of user stories for your product coming to you from (hopefully) every department the moment you join a team until the day you leave. It's easy to feel overwhelmed by the sheer volume of tasks and all the competing priorities being communicated by different stakeholders. A good PM drown out all of this noise. One way I've found of doing this is through handling your product management stories like a data lake. The concept of a data lake is pretty simple; you store your raw/unstructured user stories in one central location and then use that to pull what you need when you need it. For Product Management it comes down to having all of your stories in one central location, but being able to segregate what's important or part of your active roadmap from the noise. There are a lot of different ways to accomplish this for varying business sizes, but as a PM the key component is to make sure proper intake procedures are created, whether you're vetting all user stories yourself or simply establishing requirements for others to utilize when submitting their own. Even if some of these stories may never come to fruition, whatever ends up in your "lake" needs to have gone through some kind of vetting for quality and been properly categorized. Otherwise you'll end up with a data swamp of junk that someone, probably you, will end up crawling through and trying to fix constantly.

Standardize Your Development Journey

Anything you're going to be doing as frequently as software updates should be as smooth a process as possible. Releasing any updates to your product should be frictionless, worry-free, and automated wherever it can be. Obviously starting out this will be less of a priority, but just know how to recognize when the strains of a manual bottleneck are starting to cost enough time to warrant process improvements and/or automation.

Create & Maintain Accountability

Any active project needs to have one person accountable to that work at all stages. I've always observed that when multiple people or an entire team are assigned responsibilities that with no clear ownership, that work slows to a halt as a result with either no progress or mired in discussion for far too long. Any ambiguity or uncertainty over who should be doing what will lead to delays and frustration. The bystander effect is real and the same principle applies to project management. Name and designate ownership, otherwise you should assume that task/project/etc. isn't going to happen anytime soon.

Establish a Common Product Language

We all have varying biases and cultural interpretations when it comes to language, and this effects how you talk about your products as well. Establishing (and properly communicating) standards for the terminology you use to describe a product, and the work being done around that product within your company, can make a big difference in avoiding miscommunication and also making it easier to search/sort/analyze your documentation. The earlier this is established the better.

Think as Longterm as You Can Afford To

The truth is you can't avoid technical debt. But I do believe that many companies unintentionally incur a lot more of this debt than they should by overprioritizing speed and a lower cost over quality. Yes resources are always limited and yes having MVP principles is important for software development but I think shortsightedness, especially if we are talking about larger/older companies, can have a compounding negative effect on your product. With every piece of development work as much time as you can spare should be dedicated toward thinking about the longterm ramifications (and of course scaled as appropriate for larger projects or features). At the very least this can lead to novel improvements to your product that would be missed if the only focus was getting X feature shipped out as quickly as possible for as little time spent as possible.

Establish & Enforce Reliable, Scalable Analytics ASAP

In order to prioritize product development work you need to be able to rely on a combination of qualitative and quantitative data. But if quantitative data standards aren't established early this can ruin that data source in the longterm, or end up costing a lot more to fix down the road. I always told clients for an enterprise software when they were first onboarding to really think about what data they want to be able to see five, ten, and twenty years down the road. You want to establish analytics to provide you with that data, even if that means more time is spent initially on setup. Another important piece of this is establishing good habits with all of your departments when it comes to the company's data needs. I can't tell you how many companies I've worked at where tagging/labelling/categorization was never properly addressed by leadership and as a result we ended up with thousands of Support tickets/Account Records/etc. that couldn't tell us anything useful because no one ever defined proper categorization with their teams.

Constant Communication is Essential

As a PM you need to be the megaphone for distributing product information to the entire company, whether that means you're the one doing it or you are working with a Learning Specialist/Marketing/whoever. You need to be confident that everyone on every team knows not only what your product does but also where it is going. And you need to make sure your communication is not only constant, but also concise, clear, and timely. Miscommunications from Product can lead to headaches for any number of departments: Marketing, Sales, Support, the list goes on. And those problems can flow both ways. Avoid all of that by making sure you are constantly communicating your team's work to the entire company.

Understand & Overcommunicate Releases

Publish release notes (more on that later), alert the rest of the company, coordinate with any other departments involved. This doesn't mean you have to communicate every little update or bug fix all the time, but the greater the impact the more you should be communicating with other stakeholders. Especially if there's any possibility of issues or unforeseen complications/bugs from the release of a major feature (aka please tell your Support team ahead of time). The other upside of all this is proper communication also means you're getting feedback in the opposite direction from the rest of the company that will probably only make you're work more impactful. There's no way for any one person to know everything about every corner of the company. You will have blindspots, and in a good working environment those will be addressed by your coworkers.

Changelogs are Good for Everyone

In many places I have worked Release Notes were treated as an annoying necessity that gets tossed to whoever has some spare time to quickly type out passable summaries of the last x months of releases and get them published as soon as possible. They were an afterthought instead of the opportunity for positive marketing and effective customer communication they should be. Investing time and effort into changelogs is worth the cost. This doesn't mean you have to constantly publish release notes for every little update, but communicating all impactful releases is crucial. One effective tactic I've seen is to incorporate writing the release notes as a requirement within your user stories. And I think doing this helps your team better understand their product from the user perspective as an added bonus. But if you're going to publicize this information you might as well make it useful and informative. If you want to see an example of effective release notes check out Givebutter's changelog.

Public Roadmaps are Great (Usually)

Public-facing product roadmaps are a trend I've been seeing more often in tech companies and personally I think it's a positive improvement for a lot of reasons. Typically these public roadmaps are published by smaller software teams or startups, companies in B2C markets that rely on maintaining and increasing engagement, or even companies that have a larger customer base or a more active feedback pipeline than other traditional software companies. But I think as long as they are well-maintained and curated properly they are a valuable source of information for strategizing product development.

One of my favorite recent examples of a well-made public roadmap is from the team at Capacities, a new note-taking app I learned about last year after an article about the fallacy of note-taking apps by Casey Newton went viral. I highly recommend trying out Capacities, I think their system of organization really meshes with my own workflows and it has definitelly improved my work. The software itself is still missing a few major features you can find in any of the major note-taking apps, but I was won over by the software's design as well as the reassurance of their product roadmap. Here's a recent screenshot of that roadmap:


Capacities-Public-Roadmap

I think the Capacities team does a great job of communicating their development plans while keeping everything as simple as possible for their users. Short and sweet, with no specific dates or specifics outside of their overall release goals. A public roadmap like this is great because it creates accountability with your community and improves engagement but doesn't tie you down to specific deadlines or feature commitments. Roadmaps change constantly and you need that kind of flexibility. Keeping your roadmap a complete secret, which I know many companies prefer to do, not only frustrates your users but also your team as well who can't properly communicate (or may not even know) what is changing or being improved within your product. But on the opposite extreme, keeping an entirely public roadmap can also lead to frustration by setting improper expectations with your users who don't understand (or care about) the realities of software development and the changing nature of your work. Really the only caveat here is that if you are going to have a public roadmap I think it's essential that you have a public forum, whether that's a voting system or a Discord channel or a simple feedback form, so users can feel like their engagement has an impact on the roadmap. Without that two-way communication your roadmap will probably feel like bread & circuses to your user base.

 

Constant Feedback is Also Essential

An effective PM should be hearing from their users and stakeholders (which can be two very different groups of people depending on your product) constantly in order. I truly believe that all feedback holds value, and as a PM you want to make sure that you have as many lanes of communication of that feedback as necessary that eventually leads back to you. That means roadmap forums, voting systems, support ticket feedback, direct customer interviews, account check-ins, whatever. As long as you are confident you are hearing from as many customers as possible and that information is being properly received and collected for you, whether it's by yourself or with assistance from other teams, that is all that matters. People know what they want better than you ever will, no matter how much dogfooding you do. As a PM you are inherently biased towards different priorities than your users. And you need to account for that in your decisionmaking. (Bonus: This Lenny's Podcast episode has a great talk about getting feedback from users, assembling key users, etc.)

Miscellaneous Product Management Resources

  • Linear's Product Principles
    • I really admire Linear's ideas around product development and their focus on product quality, something I really value as part of my own product development journey.
  • Lenny's Podcast
    • This is a great podcast that interviews PMs from all over the tech industry, including some international folks as well. It also has a lot of helpful resources for PM work too.