Menu

Posts tagged “productivity”

Use asynchronous standups to improve team communication

Ted Bauer and Michael Boykin take on daily, synchronous standups in their article The Daily Standup is Broken, What Should You Do Now?

Asynchronous daily standups or check-ins help to put an end to boundless, traditional standup meetings and get the whole team on the same page with fewer meetings. And corresponding written status updates within a team coordination tool or platform — something that allows every team member to share and review updates from today, yesterday, or even last week — allow everyone to consume updates easily and on their own time.

We landed in a similar (asynchronous) place with our standups, and I wrote about it a while back in Useful daily standup meetings for remote teams:

The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:

  • Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
  • Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week.
  • I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.

Like product management, but for home life

In The Slackification of the American Home Taylor Lorenz and Joe Pinsker look at how some households are starting to operate more like businesses:

Incorporating Trello, along with Gmail, into the Parker family’s life has been a godsend, in Tonya’s view. It streamlined family communication, helped keep everyone organized, and added a layer of accountability to tasks. Now, instead of wondering if her children forgot to do something, Parker says she can ask, “How are you doing on your checklist?”

This is a fascinating trend. I can understand the use of Trello, and maybe even Slack, but… JIRA? That seems like a lot:

Julie Berkun Fajgenbaum, a mom of three children ages 8 to 12, uses Google Calendar to manage her children’s time and Jira to keep track of home projects.

“There should be no guilt for refusing to work hysterically”

Katy Cowan’s interview with Frank Chimero is really great from start to finish, and covers so much ground on design and technology and how to think about our work. Frank’s view on the importance of not overworking yourself is refreshing, and we’ll hopefully continue to see more of this kind of thinking:

It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.

My interview on The Product Experience: “Crazy Busy Product People”

I listen to The Product Experience podcast every week, so it was such a treat for me to be on the show this week to talk about Crazy Busy Product People. At first I didn’t know what to do — I’m so used to hearing Lily and Randy’s voices that it didn’t seem right to talk back, because that’s not how it usually works! But I did eventually find my feet (I think), and I’m overall pretty happy with how this turned out.

We spend most of our time discussing my article The dangerous rise of “crazy-busy” product managers, but we also touch on remote work and our 4-day work week experiment. I hope you can find some time to listen to the episode, and that you like it!

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.

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.

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.

A 2019 manifesto: analog over digital

I’ve been thinking about Cal Newport’s post called Join Analog Social Media all day, especially as we get to the end of another year:

The dynamic at play here is that digital activities that are mildly positive in isolation, combine to crowd out other real world activities that are potentially much more satisfying. This is what allows you to love Twitter in the moment when you discover a hilarious tweet, but at the end of the day fear that the app is degrading your soul.

Understanding this dynamic is critical because it tells you that you cannot improve your life by focusing exclusively on digital tools. Triaging your apps, or cutting back phone time, will not by itself make you happier. You must also aggressively fill in the space this pruning creates with the type of massively satisfying, real world activities that these tools have been increasingly pushing out of your life.

Simply cutting back on social media time is only going to leave a weird emptiness behind if we don’t fill that gap with some real connection time with the people in our lives.

I’m not sure about New Year’s Resolutions, but if I have any, it would be to look at everything through the lens of a new manifesto: analog over digital. Just as with the Agile Manifesto, the word “over” is of utmost importance here. It doesn’t mean I’m done with digital. It just means that I want to look at the things I do, and critically evaluate whether or not an analog approach could be more meaningful. For example, should I stop tracking my runs on Strava, and just enjoy them instead? Should I have a go at hand journaling instead of putting everything in Day One? The answer may very well be “no”, but I’d like to ask the question more in 2019.

Happy New Year, everyone.

Best Practices for Building and Managing a Remote Team

The Doist team makes some great points in their article Best Practices for Building and Managing a Remote Team, including something we’re embracing very strongly at Wildbit as well:

Managing a remote team effectively is not about monitoring the amount of time your team members spend online (in fact, that’s a great way to kill employee autonomy and motivation). It’s about building and supporting a team that doesn’t need to be micromanaged in the first place.

We wrote more about our approach to remote work here.

Real Work vs. Imaginary Work

The key point here is: imaginary work doesn’t count. Get to running code early. Or a rough interface. Or an outline of the copy. Whatever it is, the way to get uphill is to roll up your sleeves. Show evidence that the approach works and seek out the things that might go wrong. Then when you get over the hill, your team can trust that the work is really going to ship as planned.

— Ryan Singer, Real Work vs. Imaginary Work