There are some decent day-to-day work tips in Sierra Newell’s 7 Project Management Principles Product Managers Can Learn From. There’s one principle I wanted to expand on, and that’s “Define the scope and stick to it”. First, from the post:

Product managers should set the scope of their products’ development as early in the process as possible. Learning how to say no to product requests is a valuable skill. But it is also a reactive method of keeping your product’s development on track. Instead, be proactive. Define your product’s scope from the beginning, and keep development within that scope.

I know that “define the scope and stick to it” is fairly common practice, but I don’t think it’s a good way to build product at all. First, that principle tends only to define one side of the spectrum — how not to add scope. It doesn’t, however, talk about the need to sometimes reduce scope. If you define a “fixed scope” and say you won’t go over it, but then things take longer than anticipated (as they are prone to do in software) and you have no mechanism to deal with it, you’re going to get yourself in trouble. Because at that point, you “committed” to a scope that won’t change, presumably saying “no” to a bunch of things, and still you’re “late” in delivery.

This is why I’m a firm proponent of “fixed time, flexible scope” projects. Under that principle, you don’t lock down the scope for forever and ever. You commit to an initial body of work, and an expected timeframe. Then, if something happens along the way — a developer gets pulled into an emergency, or something takes longer than expected — you have a mechanism to deal with it. Since you didn’t lock down the scope, you don’t have to choose between being “late” or the team working themselves to death. You can reduce the scope of your work to fit into the time you gave yourselves to do it in.

There’s another scenario under which I would go even further and advocate for “flexible time, flexible scope” projects. There are instances where increasing scope (and time) is the Right Thing To Do for a project. For instance, if the choice is between a hacky way of implementing a feature, and extending functionality properly with future-proofing in mind, which would add two weeks to a project, I believe it’s pretty much a no-brainer that you need to add the two weeks.

This is why I think fixing scope is a dangerous practice. There are too many unknowns, too many variables, and too many things can change along the way. We shouldn’t let our process get in the way of good product decisions.

Shaun Clowes shares some really good hiring advice in his post Picking good Product Managers - insightful interview questions. He starts it off with a good reminder that “bad product is worse than no product”:

A product manager without a systematic approach to their discipline has less context than the team members so is less likely to make good decisions naturally. Thus a bad product manager is more likely to cause the team to make mistakes than no product manager at all.

The worst part is that many experienced product managers will be convincing since they’re used to influencing organizations. No matter how convincing the vision a product manager might paint, they need to be able to justify it within the competitive environment, the strengths of the organization, the data that proves the market exists etc.

Seth Fiegerman’s history of Pinterest and their approach to business and product is a breath of fresh air. In The anti-Facebook: Inside Pinterest’s slow and quiet rise, Fiegerman describes a company whose motto might as well be “move slow and debate things”:

Pinterest resisted throwing money at its problems, debated product tweaks extensively and did not rush to copy features that helped larger competitors achieve viral growth, employees said. Fond of touting itself as an anti-social media platform, Pinterest never introduced live-streaming or standalone messaging apps, nor did it become a primary hub for news. These features attracted press and users for other companies, but were also later abused by bad actors.

That is such a good example of a company that knows how important focus is. Their approach reminds me of Richard Rumelt’s succinct summary in Good Strategy, Bad Strategy:

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Lenny Rachitsky starts off his article on A three-step framework for solving problems with a really good insight:

Though many factors contribute to a project’s failure, nothing is more certain to cause a project to fail than a misunderstanding of the problem you are solving.

He spends the rest of the article focusing on how to develop and rally around a good problem statement, which is an essential skill to have for any product manager. I really like this framework and am keen to try it on my next project, alongside a version of Marty Cagan’s Product Opportunity Assessment that we’ve adapted for our specific needs.

Hiten Shah’s deep-dive into the history of Evernote is a very interesting read from a product management perspective. Of particular interest is the immense damage they inflicted on themselves due to a lack of focus on their core mission:

It’s hard to understate the damage that the branded products sold through the Evernote Market inflicted on the Evernote brand. It made absolutely no sense. Users didn’t want Evernote-branded tablet styluses or Evernote Moleskine notebooks or Evernote backpacks. They wanted an organizational and productivity product that worked.

The fact that the 2013 version of Evernote was widely considered the buggiest, most unstable version the company had released at that point added insult to injury. Rather than fixing the software problems that users actually cared about, Evernote started selling branded backpacks instead.

This is such a good example of the importance of knowing the core value of your product, and deepening that reach instead of trying to broaden into unrelated areas where you don’t have a core competency.

Emily Tate’s article on the best ways to prioritize bugs comes at the problem with a Scrum lens, but many of the points are more broadly applicable to product management. I particularly like her assertion that there’s nothing “special” about bugs, and as such they should be prioritized just like any other idea/feature:

As product managers, we should always manage our backlog so that the next most important thing is at the top of the list. Many times, the bug you would work on is less important than other things on your backlog. By working on the lower priority bug, you are deferring the more important work that can help you reach your strategic goals.

The flip side of this is also true: sometimes the next most important thing may be five or six bugs that really need to be fixed before adding yet another feature on top of a fragile platform. If you live in a world of separate queues or say you’ll always devote 20% of the team’s time to bugs, you actually lose the opportunity to say “this week, we are squashing these bugs that have been plaguing us before we do another thing.” In reality, you will likely have a mix of bugs and features in your backlog, but the most important thing is that you prioritize strategically and intentionally, not letting a false constraint determine what the ratio of your backlog looks like.

I think most of us know by now that merely copying competitors’ features or business models is a bad idea. Jesse Weaver’s Emulation Is Not a Product Strategy does a very good job of explaining why this approach almost never works, and what to focus on instead. One example:

In focusing their efforts on emulation, product managers stop considering options that could enhance what is unique about the company and its customer base. They miss chances to deliver something powerful and unexpected. Instead, product managers should focus on unique strengths — those things their customers came for in the first place. In doubling down on those, product managers can exponentially increase a product’s value, deepening customers’ connection to the specific magic that makes a product special.

I agree with Chris LoSacco that “Why Not?” is a dangerous questions to ask for any product team:

Often stakeholders assume that if their ideas aren’t bad, they should be on the roadmap. “This isn’t hard; let’s get it in front of the engineers.” But the burden of proof is the other way around — ideas should get turned down unless they clear a high hurdle.

Just because a feature is easy or obvious doesn’t mean you should build it. This is why I prefer the question “Why Now?”:

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, that’s a pretty good indication that it can wait for later.

This is an incredibly brave and insightful post by Erin Chan that I think every product manager should read. In The Hard Thing About Complex Products & How I’ve Grown as a PM she describes a long, failed project at Shopify in detail, and what she learned. The section on creating “tripwires” for complex projects is something I’m going to start using immediately:

A tripwire is a mechanism or an indicator that you define, and when it gets triggered, flags are raised.

For example, you should set the tripwire of ‘time’ when a milestone isn’t completed after a defined period (for me, this should have been two months). When that happens, my recommendation is to have a serious discussion with the team and make your Leadership and stakeholders aware of what is happening. Communicate the changes that you will make to the team or process to get the project back on track. Next, outline what happens if the milestone isn’t completed in three months, then four. These are your tripwires as determined by time, but you can define tripwires in whatever form you see fit for your initiative.