Menu

Posts tagged “product management”

Product management doesn’t require in-person collaboration to be effective

Remote product management is something I’ve written about before, so I read Julie Caprio’s Four Keys to Successful Remote Product Management with interest. In general I agree with the advice she gives in the article, but there is one section that I wanted to respond to briefly:

Product management, on the other hand, was more of a struggle. A PM needs to set strategy and come up with a vision for the product. Without the potential for spontaneous in-person conversation and even inspiration, this part of the job gets a bit harder. Creating a vision for a product is a collaborative effort involving several stakeholders; when the team is distributed, it’s more difficult to align on goals, tasks, and project ownership.

It’s a common criticism of remote work that it’s more difficult to collaborate remotely. But I think this is the conventional wisdom only because we try to recreate the office experience for remote work. Since offices rely on synchronous interactions, we use the same lens to try to make remote work effective, and that’s just not going to work.

If we optimize for asynchronous communication instead — which is what remote work is so good at — collaboration can be extremely effective. Perhaps even more effective than office collaboration, because everyone can provide thoughtful responses on whatever topic they are discussing on their own time. As Brian de Haaff points out in Remote Workers Are Outperforming Office Workers — Here’s Why:

Without being able to lean on physical proximity, remote workers must reach out to one another frequently and with purpose. This leads to stronger collaboration and camaraderie.

As counterintuitive as it sounds, this has been my experience as well. As long as we shift the way we think about collaboration away from the office mentality, and use the right tools, I don’t think remote collaboration is less effective than in-person work at all.

Limiting the downside of negative impacts by focusing on product resiliency

In The Misunderstood World of Product Growth Joe Van Os makes some great points about the importance of focusing on making your product resilient to negative impacts:

Since it is impossible to forecast when positive opportunities will appear, it is important to be in a position to take full advantage of them when they do. If a product team is in fire-fighting mode (dealing with the fallout of negative circumstances), opportunities with plenty of upside may be missed.

Limiting downside (technical debt, red-tape, etc) allows a product or business to quickly recover from negative impacts, as the negative impact will be contained. It is building a tough product.

The Rise of Product Ops

Product ops builds a foundation for excellence by reinforcing product strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.

— Shaun Juncal, The Rise of Product Ops: Supporting Product Excellence at Scale

The product manager’s battle between ego and customers

It’s a bit of an uneven piece, but Peter Krmpotic’s What’s the Secret to Becoming a Great Product Manager? makes some good points about ego vs. customer focus:

The ultimate goal for product managers and product leaders is to instinctively focus on the customer and not their own egos. This is hard since it is natural to be self-centered and unnatural to be customer-centric.

In Scott Belsky’s recently published book “The Messy Middle”, he highlights how we are hardwired to prefer short-term rewards, because delayed gratification causes anxiety and discomfort. Thus, I think the main career-long objective for product managers is to reprogram themselves over time from being self-centric to customer-centric, to get the urge of acting on their own ideas out of their system. Or as Belsky puts it, “to hack their reward system”.

The power of “why now?” as a prioritization technique

I imagine that if you made one of those pull-string dolls of a Product Manager, it would just say “Why?” over and over1. We love figuring out the real reason behind an idea or a customer problem — as we should. But I think we often miss an important follow-up question: “Why now?”

We have so many methodologies for prioritizing problems and features, but I’ve found that this one question is able to cut through all the complex reasoning and (rightfully) stop unneeded projects in their tracks. Most things we could work on in a product are important. But going through the thought process of why it’s important to work on something right away is really helpful to separate the truly worthy projects from the ones that can wait.

The problem is that “Why now?” is not always an easy question to answer. It’s too vague, too broad. But if you flip it around and ask it a different way, things start to become clear very quickly. So here’s a question I recommend you ask yourself and the team the next time you debate a project:

What is the danger of not doing this project right now?

If we don’t solve this problem or add this feature right now, what do we lose? Are sign-ups going to drop? Are we going to lose customers? Are we going to miss a major shift in the market? If so, then, yes, now is a good time to work on it. But if the room suddenly falls silent and everyone comes up short on the downside of skipping over the idea — or if the downside is something like “this one customer will stop sending us angry emails” — that’s a pretty good indication that this thing can wait for later.

I say “wait for later”, and not “forget about for forever and ever”, because it’s quite possible that a few months from now you’ll answer that question differently, and suddenly now becomes the perfect time to work on it. The point is that we should never do something now if later is a better option.


  1. Like Woody but for Product Managers? I want one! 

Embracing the deadline: How engineers benefit from delivery dates

This is a good summary of the “healthy pressure” we strive towards on our team as well:

While working without the pressure of explicit deadlines can feel liberating, it also increases the chance of distraction. Deadlines help us stay focused, aligned and driven – and can be used to keep project scope in check.

Finding the right balance with product onboarding

There are some great product tips in Scott Belsky’s How to Shape Remarkable Products in the Messy Middle of Building Startups, but this part about onboarding particularly stood out for me:

You can’t expect new customers to endure explanation. You can’t even expect customers to patiently watch as you show them how to use your product. Your best chance at engaging them is to do it for them — at least at first. Only after your customers feel successful will they engage deeply enough to tap the full potential of your offering.

One of the hardest things to figure out with onboarding is the right balance of selecting defaults (“doing it for them”) and having users learn by doing things themselves.

For example, within Postmark’s onboarding a continuing debate is whether or not we should auto-create a user’s first “server” for them, or help them understand the concept better by making them do it themselves. Finding the appropriate amount of friction to introduce is an ongoing and important challenge for any product’s onboarding.

Product teams exist to serve customers

Empowered Product Teams is another gem of a post from Marty Cagan. This part stood out to me:

In most companies, technology teams exist “to serve the business.” That is very often the literal phrase you will hear. But even if they aren’t explicit about it, the different parts of the business end up driving what is actually built by the technology teams.

However, in contrast, in strong product organizations, teams exist for a very different purpose. They exist “to serve the customers, in ways that meet the needs of the business.”

The distinction is subtle, but important. If you only serve “the business”, you’re going to make decisions without asking whether something is user-hostile or not (see, for example, scroll-jacking, or Twitter’s tendency to “forget” that you prefer a timeline that shows latest tweets). Bringing customer needs into any conversation about business needs is the way to build something that’s profitable and sustainable.

Data-driven vs. data-informed decision-making

The Netflix Data War is a very interesting post about the internal discussions that happen between Netflix’s content team and their data team. In short, data isn’t everything:

[…] in almost any decision-making situation involving data, there is some non-zero percentage of the process that involves “gut”. The reason is because not all information about a process can be incorporated into a data analysis, and it’s important for data analysts to realize that.

That’s an important point to reflect on. It doesn’t matter how complete a data model is. There are some variables that simply cannot be included, because it’s impossible to know what should be included in any particular model.

Apart from that, it’s also just a fascinating look at the internal workings of Netflix.

How team structures are like bands

You might think that A rocker’s guide to management sounds like one of those “What X can teach us about Y” articles. And it is, I guess, on the surface. But it’s just so well done. As an intro:

The history of rock groups can be viewed as a vast experimental laboratory for studying the core problems of any business: how to make a group of talented people add up to more than the sum of its parts. And, once you’ve done that, how to keep the band together.

The article is less about management, and more about the different ways that teams can be structured, as well as the good things and pitfalls of each approach.