I received numerous messages about my Product Ops Nano a few weeks ago. For one, it "is about PM'ing the PM experience." Another sees it "encompasses everything from system configuration and admin, to process creation and audits, to training, to OKR management, to data collation and reporting."

Well-known Harvard Business Review blogger Deb Mills-Scofield distinguishes output from outcome well: “Let’s define outputs as the stuff we produce, be it physical or virtual, for a specific type of customer — say, car seats for babies. And let’s define outcomes as the difference our stuff makes — keeping your child safe in the car.” Her summary is the best way to keep these terms straight: “Outcomes are the difference made by the outputs.”

A Product Ops team can ease the burden of busy product managers by making research and product performance analysis easier. This centralized team acts as an enabler, providing tooling or even scheduling an ongoing series of customer interviews.

How do you convince customers to chat with you? At one company I worked at, customer interviews were as easy as asking. They were flattered I wanted their input. At another company, emails and voicemails went unanswered. My pitch was the same, but the customers were different. How do you recruit for key research if your customers and prospects don’t engage?

How do you learn to be a leader? Product is the sort of leadership role that can pull the right team together and get them moving in the right direction. But how do you get those skills? Is it mentorship? Making tons of mistakes? Reading brilliant books? A Product Culture Manifesto? Or just innate ability?

After high-level themes were agreed upon by stakeholders, “we wanted as much autonomy down at the engineering and product team level as possible. Of course, there were some of what we call guardrails and goalposts. Within those guardrails, they could decide what that product looked like or how we were going to go to market.”

This time of year, I tend to pause for a bit of reflection: One lesson of the pandemic for me is that we all have to get out of a reactive mode (as we all were in the beginning of the pandemic) and pragmatically work our problems to get to our desired outcomes, given actual conditions. We have to learn to win races in the rain.

There are numerous ways to come up with a product vision. Hopes and Fears is a simple exercise where each individual writes their hopes for the product’s future on one color of Post-it note or index card and then writes their fears on another color. The objective here is to draw out everyone’s emotional aspirations and fears and see how they align with each other and with the established business objectives.

A feature factory is a team that continuously adds new features to their product without assessing whether those features add to value to the customer or the business. This leads to bloated products that are unusable and often don’t sell well either. Such products are often disrupted by simpler, nimbler products — the kind that they used to be.

When working on vision with stakeholders, I like the Cover Story technique taken from the book Gamestorming. Each stakeholder draws the cover of a magazine (e.g., Fast Company, TechCrunch, Mashable) five years in the future, after the roadmap has been implemented. What impact has this product made on the customer base? What changes has it brought about? Make sure they include a headline, an image, a subheadline, a few sidebars, and a quote.

Product people have to grab stakeholders right and left to get their opinions and their support. Product people have to grab stakeholders right and left to get their opinions and their support. As Emily Tyson, COO at Radix Health, says: “Every product manager actually has their own stakeholder advisory group — cross-functional representatives that they work with to get input on: What are priorities for sales? What are priorities from the clinical team? What does security need in the roadmap? The product team is very much responsible for taking all of the different inputs and saying, ‘This is it.’”

A user journey map is a smart way of understanding the customer needs that populate a good roadmap. A journey map simply described the steps your customer takes to fulfill a need. The steps they take on that journey are opportunities to make the customer’s life better. Those opportunities go on your roadmap as themes.

Some product people act like general managers, even owning profit and loss (P&L) for their product. Even if this is not your situation, executives and board members often want to understand business results and return on investment.

A few weeks back we had a lot of interest in our discussion of Roadmaps Themes. I am a strong proponent of using themes, or customer needs, on your roadmap, rather than specific features that may change as you learn more.

Just in time for Halloween, we have a scary Objectives and Key Results (OKRs) story! In this ghost story, different departments are at cross purposes! Evil cackles all around...

Many products serve more than one customer or user type. If your product is in education, you might consider the student, teacher, administrator, and parent. Furthermore, your users might be different from the actual buyer.

You should be seeking regular input from your stakeholders. Their thinking may or may not align with yours, but the act of listening will help with the buy-in you need.

A whistleblower has released tens of thousands of pages of internal Facebook documents, alleging the company was "negligent in eliminating violence, misinformation and other harmful content," favoring increased profits. The whistleblower was...a product manager.

Public companies who publish their roadmaps have lots of legalese in them: "Don't rely too heavily on this document, please!" But even if your roadmap is only shared internally, a disclaimer is useful

Themes are an organizational construct for defining what’s important to your customers. Roadmaps should be about expressing these needs. Most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.