Product Management in Practice: A Practical, Tactical Guide for Your First Day and Every Day After

by Matt Lemay

“I will spend no more than one page and one hour working on any document or deliverable before sharing it with my team.” I printed it out, taped it to my laptop, and told my business partners to hold me accountable to it no matter what.

Keep the structure of the template “in play” as well as its content. Templates can be a great way to structure your thinking, but they shouldn’t limit or dictate your thinking. Always be willing to change around the structure of the template if it does not seem to be helping your team achieve its goals. For bonus points, change the structure of the template with your team, to model for them that documentation can always be changed in the service of delivering better outcomes.

Always fill out a template at least three times yourself before you ask anyone else to fill it out. Here’s the thing about templates: they are sometimes really easy to make and really hard to fill out.

if you’re working with a team that is already using a proprietary roadmapping or knowledge management tool, stay focused on how the tool is being used rather than raging against the tool itself. Knowledge management is, first and foremost, a communication challenge. People will generally seek out the information they need regardless of whether it’s stored in a fancy roadmapping platform or a hacked-together Google doc. The challenge is to get people communicating openly and directly enough for them to understand and identify the information they need—and why they need that information in the first place.

Your roadmap is not your road, your product spec is not your product, your user stories are not your users. Stay focused on making a delicious meal rather than crafting the world’s most impressive and comprehensive menu.

the less time you spend searching for the “right” way to set goals and strategy, and the sooner you start working with your team to articulate where you’re going and how you’ll get there, the better.

I’ve found it helpful to reframe “outcomes over output” as “output in service of outcomes.”

if teams truly desire flexibility and leeway around output, they need to get really, really specific about the outcomes they are seeking to drive.

This has been a jarring realization for folks who, like me, have sought to avoid micromanagement by setting open-ended goals for their teams. But it has also helped me understand why every single time I’ve tried to set a broad goal like “increase conversions” or “delight customers,” my team has inevitably wound up scrambling to ship specific features by specific deadlines.

simply articulating your goals as OKRs is no guarantee that they will be any more useful to you or your team. The ultimate test of your team’s goals is not whether they fit a predetermined format or framework, but rather whether they—along with your team’s strategy—help you make better decisions.

My favorite take on strategy comes from product leader Adam Thomas, who describes the purpose of strategy as improving a team’s decision fitness. I love this description, because it makes room for the fact that every team and organization’s strategy can and should look different—but at the end of the day, if it isn’t helping folks on the ground make better decisions, it isn’t really a “strategy” at all.

I have seen many product managers fall into this trap when they are finally offered the shiny prize of stepping up into “strategic” conversations. They go off to their desk, cobble together everything they can possibly find from every google result for “good product strategy,” and try to put together the World’s Most Comprehensive Strategy Presentation. They work on this presentation for days, sometimes weeks, sometimes months. By the time it’s finished, it feels like a highlight reel for all the things a “strategic” product manager is supposed to do well. It’s got frameworks! And financial models! And user personas! And even a few nods to “Jobs to Be Done” for the true heads in the crowd. Surely, nobody could accuse this presentation—or this presenter—of missing anything important.

Each executive’s feedback is thoughtfully incorporated, and the initial 10-slide strategy deck quickly becomes a 20-slide strategy deck.

The real problem occurs when our executive-approved strategy deck makes its way from the rarified air of a super-important meeting into the calloused proletarian hands of the product team. After all, it is ultimately that product team—the same one that our hypothetical product manager has likely been “too busy working on the strategy deck” to interact with—that brings products to the market and, in turn, outcomes to the business. And in the cold light of “What are we actually supposed to do with this thing?” the World’s Most Comprehensive Strategy Presentation can start to look an awful lot like an incoherent, designed-by-committee patchwork of business jargon, confusing diagrams, and wishful thinking.

With our visual hierarchy in place, we were able to put a hold on conversations about roadmaps, staffing, and process while we focused on better understanding company-wide goals and building out our team’s product strategy. Visualizing and prioritizing the different levels of information we needed to make important decisions helped us better manage our own time and efforts, ultimately putting us in a position where we could get unblocked and build momentum.

Everybody on your team can recite your strategy in a sentence or two. My least-favorite answer to the oft-asked question, “What is your team’s strategy?” is “I’ll forward you the deck!” If your strategy is so complicated that it can’t be summarized in a sentence or two, then the odds are very slim that your team is actually thinking about it when they make important executional decisions.

Your strategy helps you decide what not to build. In many cases, overstuffed and overcomplicated strategy is symptomatic of a broader reluctance to commit to any specific user personas or problems. If your strategy can effectively justify building anything for anybody, then it is probably not a very good strategy.

Your strategy starts to feel outdated after a while. If your strategy is truly driven by an understanding of customers and markets, and you are truly doing the hard work of staying close to those customers and markets as they change, then there will come a time when your strategy clearly needs to be updated. This is by no means a bad thing! In fact, if your strategy has remained unchanged for a suspiciously long period of time, odds are it is too disconnected from the broader world to help your team or compa...

And, if the person asking you for a strategy or a vision doesn’t have any examples to share, they may very well be just as unsure about what they’re asking for as you are—in which case you are likely doing them a big favor by providing something specific and tangible.

In order for your team to succeed, you must have a clear sense of where you are going and a plan for how to get there. But if your destination is too vague and your plan is too complicated, you might not get anywhere at all. Keep your goals specific and your strategy simple, and—above all else—work closely with your team to make sure that your goals and your strategy are useful for the folks actually building stuff for your users.

In your product career, there will likely be times when you don’t have access to the data you think you need and times when you have access to so much data that it feels impossible to make a decision. Navigating both these situations requires cultivating a strong point of view about what data matters to you, why it matters, and what specific decisions it will inform.

I’ve often advised product managers to implement a counterintuitive-seeming rule if they want to take a truly data-driven approach: don’t use the word data at all. If you’re discussing a particular set of information, describe that specific set of information. If you’re discussing conclusions that you’ve made based on that information, describe those specific conclusions and how you reached them.

I’ve used in many workshops and coaching conversations: “What decisions could we make if we had all the information we need?” Answering this question often proves surprisingly difficult.

You’d be surprised how often a product manager has told me, “Our single biggest problem is that we don’t have enough data to make decisions,” and then struggled to name a single decision that they are actually trying to make.

In your product management career, there will likely be many times when you can’t get the data you want. But there is always a path forward, and you can often find that path by taking the time to better understand the decision you are trying to make and seeking out any and all information (quantitative and qualitative) that might help you make that decision.

I learned how to start with a conjecture and say, “On this basis, we expect these metrics to be affected.” How do you measure that something is working? Are you expecting an increase in sales? An increase in conversions? If you look at science—which has existed for much longer than product management—it relies upon the initial conjecture to set up the experiment, that first hypothesis or leap of judgment. Truly data-driven experiments often involve following your intuition, then establishing a feedback loop of some sort to test whether your intuition is correct.

If we are not specific about the outcomes we expect to see, we are almost certain to fall back into measuring the success of our work as a function of vanity metrics, whether those are “Look, some people are using the product!” or “Look, we shipped the feature on time!”

in Tim Casasola’s always-excellent newsletter The Overlap, I read five simple words that truly shook my world: “Don’t prove value. Create it”. In other words, don’t run experiments with the goal of proving to your colleagues that something might theoretically provide value to your users; run your experiments with the goal of providing value to your users.

Long story short: nobody really likes having anything “proven” to them, ever. When you create something that is delivering real value to your users, it is much easier to break political logjams and build momentum. And when you create something that fails to deliver value despite your very best efforts, you can work with your team to better understand the assumptions and misapprehensions that might have contributed to a genuinely disappointing outcome.

just because a test yields a “statistically significant” result doesn’t mean it’s significant for the business or for its users. I had been so eager to be “scientific” in my approach that I had completely lost sight of the big picture. I was more focused on something measurable and testable than something that might actually drive the bigger results we needed as a business. Now, I try to start by understanding the size of the opportunity: how many users are actually interacting with this thing, and how meaningful are those interactions? If it’s a really minor thing, then a “data-driven” experiment might be a truly useless exercise.

In practice, though, I’ve often seen this backfire pretty badly. When product managers are held directly accountable for hitting a specific quantitative number, they often disengage when they feel that number is out of reach. If you’re being held accountable for a certain percentage increase in new user growth, for example, and a competitor launches a product that you know is going to chip away at your market share, you might be tempted to just throw your hands up and get ready for an unpleasant quarterly review. In fact, you might be just as likely to disengage if you realize early on that the metric against which you’re being evaluated is on a one-way ride to Successville. Therein lies one of the most uncomfortable and difficult challenges around data-driven “accountability” for product managers: how do you ask people to be responsible for something that is ultimately outside of their control?

I have found it helpful to explicitly reframe metrics-driven accountability for product managers not as hitting a particular quantitative target but rather as prioritizing their team’s efforts to align with that quantitative target.

If the numbers for which you are accountable are moving in the right direction, but you don’t know why or what to do about it, you are not doing your job as a product manager. And, if the numbers for which you are accountable are moving in the wrong direction, but you have taken the time to understand why and develop a plan of action, you are doing your job as a product manager.

you do the best you can. You take a look at all the layers available to you—from high-level company goals to specific user insights and product metrics—and try to take the bite that will be most delicious for your company and your users. You might, for example, look at product instrumentation data and decide that changes to the core product are ultimately much more likely to deliver against both the company’s overall revenue goals and your individual team’s quarterly OKRs.

If you can solve a real problem for somebody, they will tell the story to their boss, and their boss’s boss, and before you know it, you have the whole company advocating for your work.

Nearly every product manager I know has complained to me at least once that their company is an output-obsessed feature factory that only pretends to care about its users. But nearly every product manager I know, myself included, has also contributed to this very problem by prioritizing the features that will be easiest to manage over the features (and nonfeatures) that will be most impactful.

product management is difficult enough when the only stakeholders you really need to align are the designers and developers you work with every day. Once you need to coordinate with other product teams, you will also need to navigate their goals, ambitions, expectations, and internal misalignments. Thanks, but no thanks.

One way to make sure you are living in your user’s reality is to regularly use your own product in a manner that closely resembles the way your actual users do. Rather than doing tightly scoped tests and walk-throughs of your own feature(s), try signing up for a new account and completing the entire suite of tasks or journeys that are most important to a specific user type or persona. You will likely discover that the most meaningful opportunities to improve the experience overall are not definitively scoped to your team’s work—or to any single team’s work, for that matter.

remember that no product organization in the world has this all figured out. Don’t give up if it feels like your particular company’s operating model or org chart seems purpose-built to discourage collaboration across teams. Keep one foot firmly planted in your user’s reality and don’t be afraid to step the other one outside of your team or silo in order to deliver the best possible outcomes.

A two-week prototype probably saved us six months of development time that would not have helped us meet our organizational goals.

In the spirit of product managers making themselves obsolete, I often suggest handling these requests with a templatized intake form. These questions can be a good place to start: What is the issue? Who reported this issue? How many users is it affecting? How does this issue affect our company-level goals, such as revenue? What would happen if this issue were not addressed in the next two weeks? What would happen if this issue were not addressed in the next six months? Who is the contact person for further discussing/resolving this issue?

In an excellent article entitled “Remote Work Insights You’ve Never Heard Before,” engineering leader Sarah Milstein makes the bold claim that

We put our answers to these questions in a one-page document, which we turned into a template that you can access here

Earlier in my career, I figured that remote team members could simply “call in” for our four-hour sprint-planning meetings. To those remote team members, I offer my sincere and belated apologies. Staying engaged for an hours-long remote meeting—especially when that meeting is open-ended and poorly planned—is not something that should be asked of anybody. These days, I try to limit all remote synchronous meetings to one hour and break down longer meetings into multiple one-hour sessions with their own clear inputs, outputs, and goals.

If you are working toward creating a shared document like a roadmap or one-pager, this allows you to keep the meeting’s desired outcome tangible and accessible for everybody involved. It also helps foster a sense of shared ownership, rather than positioning one person—usually, let’s face it, the product manager—as the document’s (gate)keeper.

for every hour of high-value synchronous time you plan to spend with your team, assume that it will take three hours of prep and practice to use that time well. In other words, if you are planning a one-hour roadmapping session with your team, put three hours on your calendar in the days beforehand to really think through what the final outcome of the roadmapping session will look like and how you want to structure each step of that session. You may even want to practice the session a few times yourself or with your colleagues, to make sure it runs smoothly.

Send an asynchronous pre-read at least a day in advance of your meeting. This encourages participation from people who might need a little time to get their thoughts together, and it orients the entire group to the questions and tasks at hand. Facilitate a timeboxed, synchronous meeting where you work together to make a decision, co-create a document, or solve a problem as described in the pre-read. Send an asynchronous follow-up with next steps and action items no more than one day after your synchronous meeting. This keeps the momentum going and makes sure that everybody who participated in your meeting sees and understands its outcomes—even if they were distracted in the moment.

As with any other communication practice, the synchronous sandwich will be most valuable when you collaborate with your team to make it your own. If, for example, you find that participants are not engaging with those asynchronous pre-reads, consider adding 10 minutes of “look at the pre-read and jot down questions” time at the beginning of your synchronous meetings. As always, stay attuned to the specific needs of your team and work with your team to understand and address those needs.