29 April 2019

Why it’s not a good idea to define a fixed project scope

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.

22 April 2019

How product managers can get better at their skill gaps

Marty Cagan posted another great installment in his series on how to be a good manager of product managers. In Coaching Tools — The Plan he describes the different ways he would encourage product managers to skill up in areas where they need to grow.

It’s hard to pick just one quote to post because the whole article is excellent, but these paragraphs on collaboration particularly stood out for me:

Modern product management is all about true collaboration between product, design and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.

The PM does not need to be personally skilled in either design or engineering (most aren’t – although many PM’s think they’re great designers) but they do need to understand and appreciate their contributions to the point where they understand that what each of design and engineering brings to the table is just as essential as what the PM brings.

21 April 2019

Product specifications: our template and process

My previous article on the dangerous rise of “crazy-busy” product managers generated quite a bit of feedback. One part of the article that was a bit of a throwaway, but became a focus of many of the questions I received, is on the way we have our team leads work on product specs. As a recap, here’s what I said:

The point is to think about areas where you do all the work or where you’re a bottleneck and you don’t need to be. In our case at Postmark, I frequently got overwhelmed with spec writing. So we changed that. The lead designer/developer on a project now writes the first draft of the spec (we have a really nice template), and the rest of the team (including me) comes in afterward to ask questions and polish to the doc. The added benefit? Those team leads now have a way better understanding of the work they’re about to do, and they also feel a strong sense of ownership.

I got questions about the template we use, as well as how team leads find the time to do that. So I wanted to give a little more context on that.

What template do you use?

There is no shortage of “product spec” templates out there, so the one we use isn’t particularly groundbreaking or new, but I like it for a couple of reasons.

First, we’re very serious about the “living document” nature of our template. We don’t fill out the whole thing up front, we host it in Dropbox Paper, and everyone on the team has full edit access. We truly work on it together.

Second, I’ve had over 10 years to iterate on this. So yes, there are many product spec templates like it, but this one is mine. I like the focus on defining the problem, the market, the risks, and the success metrics before anything else happens. I like the modular nature of it — just use what’s applicable to the project. And I like that it’s fairly short and focuses only on what’s needed.

You can view the template on Github. Feel free to send me feedback!

Where do your team leads find the time?

I guess saying that our designer/developer leads write the first draft of the spec raised some eyebrows. So let me address that. At Postmark we’re constantly evolving our development process. As of now, we usually plan for 10-week development cycles (which includes multiple smaller releases). This is followed by a 2-week “off-cycle”.

During the off-cycle we don’t take on any new projects. The team uses this time to polish anything they didn’t get to during the regular cycle, focus on some bugs they wanted to get to for a while, respond to customer feedback, etc. But we also use this time for planning. This is when we get together as a team to discuss the problems we want to solve in the next cycle, and work on planning together.

So the answer to the question “Where do your team leads find the time to write specs?” is simply: we give them time. Their “project” during the off-cycle is planning for the next cycle. Thinking through the problem, consulting colleagues, learning any new skills that would be helpful — this is all you are focused on during those two weeks.

This has worked really well for us, because we start every new development cycle with a good understanding of what we want to accomplish. Our teams are fully immersed in the process, and have full ownership of their solutions. And I feel much better too, because I was able to spend quality time on each plan, asking questions, guiding where needed, and making sure we keep our focus on the right things.

Of course this solution won’t work for everyone, so this isn’t really advice. Let’s call it “shared experience.” I’m not saying everyone should work this way. But I will say that it has made us much more productive and efficient.

21 April 2019

Why it’s important to watch (and understand) your product churn

Shaun Juncal has a good overview of the importance of watching your churn numbers carefully in his post Churn: The Most Important Product Metric for SaaS. It’s especially important to figure out why people leave when they do:

But you can also learn something from that lost customer, namely why they left. Were they drawn to a competitor? Did the value your solution offered fade over time? Was a missing key feature causing them to bail out? Answering these questions can inform what should be done to retain your current stable of paying customers and attract new ones.

A simple churn number can’t tell you why someone leaves, so this is data that has to be collected qualitatively. But how? You don’t want to provide a negative user experience to customers on the way out, so putting a giant hurdle in front of them is not a good look. We solve this problem at Postmark by providing an optional text field on the page where you select your downgrade option:

I’m sure we would get more responses if we made this a required field, or turned it into a pop-up. But at what cost to negative perception would we do that? Following someone as they exit a store is creepy. Don’t be creepy.

17 April 2019

How to build trust, and other advice for product manager soft skills

Claire Lew’s article on the 9 mistakes you don’t know you’re making as a new manager is written specifically for people managers, but I found a lot of good advice in there that relates to the product management role as well. For example, on how to build trust with a team:

However, in our survey of almost 600 people, we found that team-building activities were in fact rated as the least effective way to build trust. What was rated as most effective? Being vulnerable as a leader, sharing your intention, and following through on your commitment. In other words, trust isn’t about building rapport – it’s about you making clear why you’re doing something, and then acting on it.

I’ve found this to be 100% true — both in my dealings with my managers over the years, as well as building trust with different teams. This is not your usual “listicle” article — every tip in here is gold.

16 April 2019

Common mistakes less senior product people make, and other good hiring questions for PMs

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.

12 April 2019

The dangerous rise of “crazy-busy” product managers

Over the past few months I have become fascinated by what I like to call “crazy-busy PM” thinking in the product management world. I’m sure you’ve seen a few tweets or articles about this yourself, but here’s a small sample, all from fairly big voices/blogs in the industry.

From 15 Things You Should Know About Product Managers:

It is common to go through the whole day as a PM, and get absolutely nothing done. Your calendar is stacked. The meetings are booked. There is a ton of talk, but nothing seems to have actually happened (outside of a bunch of new items for you to follow up on). Meanwhile your team is sitting there with important questions, you have two-hundred unanswered emails in your inbox, Slack is firing off notifications left and right, and you have a doctor’s appointment at 4:30pm you have to get to (because you’ve missed your appointment three times in a row). It is frenetic.

From The State of Product Leadership 2019:

The best PMs I know are crazy-busy humans who often seem caught in a precarious equilibrium between enthusiasm and frustration.

From Emotional Debt:

Being a product manager can be like riding a bike, except the bike is on fire – you’re on fire, everything is on fire. That’s how our days can feel. We have to take care of our product, our team, perhaps our finances. Our schedules are full from looking after other people or things. And these things invariably drive emotions; we care passionately about our products, we can love and loathe our stakeholders, and we feel an almost parental-like responsibility for our teams.

I think it’s time to have a real discussion about this, and the damage this kind of thinking is doing — not just to the individuals who work in such environments, but also the industry as a whole. In this article I’d like to discuss why I believe this is such harmful thinking, and what we — and you — as individual product managers can do about it.

Why “crazy-busy PM” thinking is harmful

First, it needs to be said that if your days are “frenetic” and “you’re on fire, everything is on fire,” you cannot possibly be doing your job well. That’s not my opinion, that’s just how your body works. There’s plenty of research and science around this, with the most succinct and relevant explanation probably being Cal Newport’s book Deep Work:

Then there’s the issue of cognitive capacity. Deep work is exhausting because it pushes you toward the limit of your abilities. Performance psychologists have extensively studied how much such efforts can be sustained by an individual in a given day. In their seminal paper on deliberate practice, Anders Ericsson and his collaborators survey these studies. They note that for someone new to such practice (citing, in particular, a child in the early stages of developing an expert-level skill), an hour a day is a reasonable limit. For those familiar with the rigors of such activities, the limit expands to something like four hours, but rarely more.

So the first thing to realize about “crazy-busy PM” thinking is that it is, quite literally, making you do sub-par work. In such environments you don’t have time or space to be thoughtful in your questions, feedback, and responses. So you are selling yourself short, first and foremost.

The second way this is harmful is to the future of the industry in general. Who in their right minds would look at a sentence like “it’s like riding a bike, except the bike is on fire – you’re on fire, everything is on fire” and go, “oh, that sounds great, sign me up.” How are we going to attract deep strategic thinkers to the role if that’s the expectation? We are doing the entire future of product management (and, not to be dramatic, but quality products in general) a disservice by perpetuating this myth that to be a good PM, you have to be a “crazy-busy human.”

How to be a more balanced product managers

If you are in a role like this, the first thing I want to say is that it doesn’t have to be this way. It’s possible to change your environment. The way I look at it, your personal workflow is a product just like any other product you’re managing. And if your product is dysfunctional, you have to prioritize making it better.

Let me be clear that I’m not saying product management isn’t a stressful job. I know that it is, and our ability to care deeply about what we make is an essential characteristic of the job. But the irony is that “crazy-busy” works directly against that care. So we have to change it.

How do we do that? By viewing your workday through the same lens you approach all your projects. If a project/feature is going off the rails, there are two, and only two options: increase the timeline, or reduce the scope. A “crazy-busy PM” lifestyle means you are off the rails, and you need to do one of those two things to get it back on track.

Increase the timeline

First, you can increase the timeline. Give yourself — and everyone else — more time to do the things they need to do. Argue for more realistic timelines. Explain how it will result in higher quality products and happier and more effective teams. I often find that teams run at the speed of the product manager. So this might be as simple as just you slowing down. The rest of the team will follow.

Reduce the scope

The other option is to reduce the scope of what you do. There are two primary ways I can see that happening.

First, delegate more of your tasks to the rest of the team. Do you collect all feature request? Set up a system for the team to submit them in a central place (we use productboard, but anything will do), and look at it at a designated time. Are you doing a bunch of first-line support? Great, keep doing that! But also get some developers involved. They’ll understand customers better and lighten your workload at the same time.

The point is to think about areas where you do all the work or where you’re a bottleneck and you don’t need to be. In our case at Postmark, I frequently got overwhelmed with spec writing. So we changed that. The lead designer/developer on a project now writes the first draft of the spec (we have a really nice template), and the rest of the team (including me) comes in afterward to ask questions and polish to the doc. The added benefit? Those team leads now have a way better understanding of the work they’re about to do, and they also feel a strong sense of ownership.

The second way to reduce scope is to split the product, and hire another PM. The best time to hire a new PM is just before they become “crazy-busy”. I want to reiterate that “crazy-busy” is not a sustainable position for a company to be in, and in these environments PMs will burn out (and do sub-par work while they’re at it). If none of the other things in these recommendations is an option where you work, you have to hire more PMs. Your company depends on it.

I understand the need for framing the PM role like it’s a constant rat race that no one except us understands. We want to feel like we do important work, and we want to be valuable to our companies. But I have to say, “crazy-busy PM” thinking is not the way to go about that.

We chose to do a job that requires a very particular set of skills, just like every other technology job. So, with apologies, I submit that we are not that special. The way to prove our value is to build amazing products that customers love. But that shouldn’t be our only metric. The safety, efficiency, and happiness of our teams (and ourselves) is an essential part of that. Let’s not kill ourselves in the name of good product. It’s not necessary, and in fact, it’s extremely counter-productive.

Update on April 21, 2019: Also check out the follow-up post where I share our template and answer a couple of questions I received about this article.

12 April 2019

Pinterest and the value of focus and moving slowly

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.