Menu

Deep Work and the power of attention

Craig Mod’s How I Got My Attention Back is one of those essays that I think will become a classic. It strikes that rare and difficult balance of talking about technology dependence without falling into the “ALL TECHNOLOGY BAD!” trap we often see in similar pieces. There’s so much that resonated with me, but this part in particular stood out:

The more I thought about my attention the more I thought about the limits to human scale. How technologies inevitably amplify ourselves — the best and worst parts — in a way that is almost impossible for us to comprehend. How that scale is so easily co-opted to attenuate our attention with the worst possible diet of high-sugar, high-carb nothingness.

I also appreciated the point he makes that as much as we tend to blame ourselves for being too “weak-willed” to give up Facebook or Twitter, we have to remember that there are thousands of people on the other side of that product who are trying to figure out new and innovative ways for us not to give it up. He quotes from Bianca Bosker’s Addicted to Your iPhone? You’re Not Alone:

“You could say that it’s my responsibility” to exert self-control when it comes to digital usage, he explains, “but that’s not acknowledging that there’s a thousand people on the other side of the screen whose job is to break down whatever responsibility I can maintain.” In short, we’ve lost control of our relationship with technology because technology has become better at controlling us.

I’ve had my own struggles with this over the past year as I dealt with a huge personal loss. In the end, my re-entry to a more sustainable online presence came from a very unlikely source: a book I would never have read if someone didn’t force me…

Our CEO sent us all a copy of Deep Work: Rules for Focused Success in a Distracted World and asked us to read it. I expected to snigger my way through it but boy, was I wrong. It is a fantastic plea for taking back our attention at work, and it provides some really useful guidelines on how to do that. For my part, the idea of “work blocks” is one I’ve taken to heart, and it’s done wonders for my productivity. I also bit the bullet on RescueTime, and it really is as good and useful as everyone says it is.

Work blocks

For more on work blocks and other non-digital productivity methods, check out Chris Bowler’s excellent resource on Working with Pen & Paper.

So I guess my one recommendation is, read Deep Work. Even if (or maybe especially if?) you don’t usually like business books. You won’t be disappointed.

Product Management for well-established products

There’s a lot you need to get right when launching a new product. There’s figuring out the user needs and the business goals; there’s testing hypothesis and finding product/market fit; there’s prioritizing the roadmap (or more likely these days, deciding not to use a roadmap at all)… the list goes on and on. So naturally there’s quite a bit of writing on this topic. Most product management advice (including, ahem, a certain book) covers this area of fresh or updated products very well. What we see less of is articles and books about how to manage a well-established product.

What do I define as a well-established product? It’s fuzzy, but I see it roughly as a product that has been in the market for more than a couple of years, has a steady and growing revenue stream, as well as a few healthy competitors. The reason I’m interested in well-established products is because, well, Postmark (where I work) is one. We have a product that most of our customers love, and it’s growing in both users and revenue. Of course we have ideas on how to make it better, but we’re in a different stage of our journey. We’re not frantically playing catchup with competitors or trying to complete a bunch of features that aren’t adding value to any customers yet.

This is, I’ll admit, a wonderful position to be in as a product manager. But it doesn’t mean there’s no work to do. I’ll stop short of pulling out the “software is never done” trope (in fact, I’d argue that software can be done). I will say that we’re definitely not done with ours yet. So as a product manager, I learned this year that well-established products face a different set of challenges than newer products. Here’s an incomplete list of my hypotheses about managing such products:

  • Prioritization becomes a much finer art (with a little less science).
  • Roadmaps become more important.
  • Process becomes more necessary.

I’d like to spend a little time discussing each of these issues separately.

Weekend work

Prioritization

When I started at Postmark we went through a full product discovery and prioritization exercise. I wrote a long post about it on our blog: How we built a product vision and roadmap. I also followed that up a few months later with From roadmap to shipping: effective product management for remote teams — a post on how we moved from strategy to execution. Something I didn’t get into in those posts is how my understanding of prioritization evolved as we moved further into the details.

Postmark is a tool for developers. That means that feedback from customers comes in often, and it comes in detailed. Feature requests are usually incredibly specific (and useful), ranging from a field that’s needed in an API, to missing functionality and how that affects their business. Due to the sheer volume of high-quality feedback we get, I learned quickly that I needed an efficient way to categorize and prioritize things as they come in, otherwise everything would just go die on a backlog somewhere.

The biggest shift here was to move to a system where we prioritize themes, not individual problems or features. A theme is loosely defined as a particular customer problem or opportunity we need to solve — similar to the “hypothesis” nomenclature in lean development. Now, when new ideas come in to JIRA (Yes, yes, I know; more on JIRA later) — either internally or from customers — I follow a set of steps to (1) process and (2) prioritize them:

  1. First I do a gut check: is this something we’d ever do? Does it point to a customer problem or business opportunity that would be beneficial for all of us to solve? If so, great. If not, the request gets rejected with a note so we can get back to the customer or internal stakeholder.
  2. If a theme already exists for a particular idea (e.g., Improvements to the Bounce webhook, or Improvements to the Statistics page), I add it there, and considered it processed. It would be too overwhelming to think through the details of every single idea, but I know that when the time comes to work on a particular theme, it’ll be there, and we’ll go through it then.
  3. If a theme doesn’t already exist for that idea, it gets a little trickier. Is this important enough to group together with other things to create a new theme? Do we expand a theme to “make room” for the idea? This is where things get decidedly less certain, and I have to be comfortable with a certain amount of fluidity. I might create a new theme, only to merge it into something else later. That’s ok. As long as it’s somewhere manageable where we won’t forget about it, I’m happy.

During our quarterly planning I don’t make the team go through every single JIRA ticket (to their enormous relief). Instead, we discuss our OKRs (Objectives and Key Results) for the quarter, and then decide which themes to work on that line up with those OKRs. Once our themes are prioritized, I work with the teams to figure out how best to address it — it’s usually a combination of some of the ideas already inside that theme, and a few new ones we come up with.

And this leads me to my next point…

Roadmaps

I’m still quite amazed at how out-of-fashion roadmaps have become. It seems to me that a lot of people got burnt by 2-year corporate plans that weren’t allowed to change, and then decided that the only way to deal with that (admittedly atrocious) situation was to get rid of roadmaps altogether.

I respectfully disagree.

I’ve written about this before, so I’ll just reiterate one bit here:

The purpose of a product roadmap is to set forth a long-term vision for the business, and break that up into smaller, meaningful pieces of work, based on what you know now. It’s fallacy to believe that this is an unchangeable list of dates about where the business is headed. A product roadmap that doesn’t react to day-to-day changes in the market and within the company is a pretty dumb document.

This is, in my experience, especially true for a well-established product. There is a lot more leeway to mess around and see where things go on a new product. With an established product, it’s way too easy to get off track (Evernote, anyone…?). So what I argue for is a flexible quarterly roadmap of prioritized themes. You don’t write down dates next to a long list of features. You don’t make hard commitments for releases that might never happen.

Instead, you put together a list of themes you’d like to work on, in order of priority, based on how closely they align with your objectives and key results for the quarter. And then you meet every week as a core team to discuss a couple of things:

  • Did any new theme arise over the week that is important for us to discuss?
  • If so, and if we should work on it soon, what does it replace?
  • If not, then let’s get back to work.

This keeps the roadmap flexible, and it keeps the team aligned on what the most important themes are for the product and our customers.

Process

Which brings me to my last point… process. I’ll quote Michael Lopp on this until the day I die:

Engineers don’t hate process. They hate process that can’t defend itself.

Considering the sheer number of detailed input we get on the product as well as the amazing ideas coming from inside the team, there’s no way I could just wing it. Maybe there are some PMs who can hold everything together in some kind of virtual kanban board in their heads, but I just can’t do that.

So yes, we use JIRA, and you know what? It works for us. The Customer Success and Marketing teams submit ideas and hypotheses with links to the customers who request it. If and when those ideas make it into a theme, they continue to add more customers to it as we go. They can always see where something is in the development process, and when it gets released they get to go tell a bunch of customers that the thing they asked for is now live. And that is really cool.

I understand why people hate JIRA, I really do. But I think I’m such a big proponent of it because we were able to come up with a way for it to benefit the whole team, and actually make their lives easier, not harder. We have a process that can defend itself. And I don’t think you can work on a well-established product without something like that.


This year has been an enormous learning experience for me. I’ve never worked on a product like Postmark before. It’s a product that is basically universally loved, where feedback comes in from people who are passionate about it and can’t imagine their development lives with out it.

As much as it is a dream to work on a product like this, I feel like I had to learn a whole new set of skills to be effective as a product manager in such an environment. I know I still have a long way to go, but I can tell you one thing — I’m excited to learn more in 2017.

Effective product management for remote teams

A few months ago I wrote a post about how we build a product vision and roadmap for Postmark. It’s now almost 6 months later, and I just published a big post on the Postmark blog about how things are going. From roadmap to shipping: effective product management for remote teams is about how we moved from vision to execution, and how we dealt with the many challenges that remote teams bring to the equation. For example, on communication:

As a remote team we have to walk a fine line between working in private and working in public. We see this as a basic sine wave, where balance is extremely important. Work in private too much and you become silo’d and isolated. Work in public too much and it gets distracting for the rest of the team (and you never get time to focus). So we ran with the sine wave metaphor to create a diagram that outlines our ideal approach to private/public working and how we gather feedback.

You can view the post to see this diagram as well as a bunch of other topics:

  • How we made the transition from an exciting grand vision to the daily grind of working on projects and features to make that vision a reality.
  • What tools we decided to use on a day-to-day basis to keep everything running smoothly — and how our use of these tools evolved over time.
  • The challenges and opportunities of being a (mostly) remote team, and how we try to make sure we communicate enough without overdoing it.
  • Some remaining challenges we haven’t quite figured out yet.

Easy features can be very expensive

James Gill has a good overview of How bad features are born:

Most importantly, does this feature deserve to exist? Why are you working on it?

If you’re embarking on a new feature primarily because you’ve seen a competitor release something similar, then you probably haven’t thoroughly considered or even identified the problem you’re trying to solve. If you’re jumping into a new feature because it seems like “it wouldn’t be too hard to do” that’s great, but does it actually deserve to be built right now?

The biggest danger I see is this “it’s easy to implement” argument. A feature might be easy to implement, but that doesn’t make it “cheap”. The problem with implementing even easy features is that they’ll most likely remain in the product forever. That creates the potential for lots of (expensive) maintenance and support.

Also see How Much Does A New Feature Cost?

Effective remote teams over-share

Joe Tullio has some good tips for remote teams in Distributed UX teams: Early lessons learned. This part, in particular, is something I think many teams ignore because it can feel like busywork:

At Google, we have an internal “snippets” tool for posting regular updates on our work, typically at a weekly cadence. Snippets serve to share the latest mock versions, research reports, study plans, hiring updates, and anything else that feels noteworthy.

To be fair, snippets are a diligence task; I’ve been on teams where these updates were neglected for months at a time. However, my far-flung teammates have been instrumental in encouraging the rest of us to share updates, as they benefit greatly from seeing them. We’ve come up with several ways of reminding ourselves to do them, through calendar appointments, shared compilations, and as a last resort, the tried-and-true email nag.

I’ve written about a similar approach we follow in Useful daily standup meetings for remote teams, and I stand by it. The benefits far outweighs the “cost” of spending a few minutes thinking about your day and updating your team about what you’re working on.

Product managers are consensus managers

Des Traynor shines a light on the unglamorous side of the PM role in Q&A: What does a product manager do?

If you look at how actual product managers work in any company there’s a lot more nitty gritty work. There’s a lot of spreadsheets, wireframes. Google Docs, emails, and oh-so-many Slack channels. And they all exist to research, collaborate, dictate, and document consensus on a direction the product is going. But I think if the role was titled “Direction and Consensus Manager” you might not get as many applicants.

You have a machine voice

Tom Dart wrote a really interesting piece on how we change our accents when we talk to machines. From Y’all have a Texas accent? Siri (and the world) might be slowly killing it:

“Most people have what we would call a telephone voice, so they actually change away from their local family accent when they’re speaking on the telephone to somebody they don’t know,” said Alan Black, a Scottish computer scientist who is a professor at the Language Technologies Institute at Carnegie Mellon University in Pittsburgh.

They also have a “machine voice”, he said. “People speak to machines differently than how they speak to people. They move into a different register. If you’re standing next to somebody in an airport or at a bus stop or something, you can typically tell when they’re talking to a machine rather than talking to a person.”

This part on the design of Siri is really interesting:

Black speculated that “one of the reasons they designed Siri to be fundamentally a polite, helpful agent who isn’t your friend but works for you, is to encourage people to be somewhat polite and explicit to her, rather than being very colloquial. Because speech recognition is always hard when you drop into colloquialisms.”

Good design and positive change

Kashmir Hill writes about How Nextdoor reduced racist posts by 75%. Nextdoor tested a bunch of different approaches:

Some just saw the addition of new language: “Ask yourself: Is what I saw actually suspicious, especially if I take race or ethnicity out of the equation?” Some were asked to say in advance whether they were reporting an actual crime or just “suspicious activity.” Others actually had their posts scanned for mentions of race (based on a list of hundreds of terms Nextdoor came up with) and if a post did mention race, the user got an error message and was asked to submit more information about the person.

This is proof that good design can make a positive difference in the world.

More

  1. 1
  2. ...
  3. 60
  4. 61
  5. 62
  6. 63
  7. 64
  8. ...
  9. 201