Running and breathing and problem-solving

I want to tell you a quick story about running. And I know it’s a little weird to make everyday life stories about product design but I can’t help myself, so I’m going to do that at the end. Let’s be cool about it, ok?


I hate running. I’ve always hated running. A couple of weeks ago my friend Jason came over for a visit and started asking me about it. He wouldn’t let up. Bastard kept pressing. “Why do you hate running so much?” Over and over and over. Eventually we narrowed it down to breathing. I’ve always felt uncomfortably out of breath when I run. This is when my wife joined the party, and feeding off each other, they kept at it.

What felt like hours later, through their incessant questioning, we figured out that I’ve been breathing ridiculously wrong during my runs for two decades. For reasons that I am unable to explain, I’ve always timed my in-and-out breathing with every third step. Not second. Not fourth. THIRD. The result is that I’ve basically been hyperventilating through my runs for the better part of 20 years.

Anyway, they coached me for about five minutes on how to breathe. Turns out — and this is going to blow your mind — your body knows when it has to breathe. All you have to do is stop trying to force some kind of rhythm. Just focus on getting as much oxygen into your lungs as you possibly can, and then letting it out slowly. Your body will find its own rhythm.

The next day I tried out this revolutionary breathing mechanism. Not only was it enjoyable, I ran faster and further than usual. Last weekend, not even two weeks after they accosted me, I went for a 10k run. It was my fastest 10k ever, and more importantly, I enjoyed it.

Portland 10k

I keep switching back and forth between being really pissed that I’ve been doing it wrong for so long, and ecstatic that I’ve been able to figure out the issue. I’m still blown away that a change in breathing can have such an immediate and enormous impact. Mostly, I’m thankful for my friend and my wife, who persisted way past the point of annoyance, and gave me a new lease on running (and, not to be dramatic, but life too).

Here’s where we get to the product design bit. This experience taught me another lesson, something that’s already deeply ingrained but I still forget it sometimes:

You cannot come up with a good solution before you understand the problem completely.

I tried that shortcut with the running thing. I switched up the cadence, or tried to just “break through the wall”. It wasn’t until someone pushed me to get to the cause of it all that we were able to find the right solution. So I resolved to be just a little more annoying at work. All it really comes down to is asking Why? a few more times than I think I should. I know that the answers will help us understand what we’re trying to accomplish, and building a better product for our customers.

What we lost when sound systems stopped being furniture

Kate Wagner explores How speakers went from statement furniture to unseen tech:

In today’s wireless age, most want their sound system to be out of sight and out of mind. “If interior designers had their way,” says Scott Orth, director of electroacoustics at Sound United, “there would be no speakers at all.” Orth adds that “the trend among average consumers has been to go smaller for the last thirty years.”

But there was a time when speakers were as essential a piece of furniture as the sofa: The peak of home hi-fi offered handcrafted teak consoles and towering pairs of floor speakers. Today, small, easily hidden speaker systems are the mainstays of home listening. But how did we get from full cabinetry to speakers not much bigger than a tin can?

When we moved into our house we made a conscious decision not to make the TV the centerpiece of our living room. Instead, everything is laid out around this (the TV is banished to the basement):

The family sound system

I didn’t think much of it at the time, it was just something we wanted to try out. But the results have been positive: we watch less TV, and listen to (and argue about!) music more. I think when TVs started pushing sound systems out of the way in living rooms, we lost more than just a beautiful piece of design. We also lost an important connection point within families.

The injustice of the gig economy

Jia Tolentino’s takedown of the gig economy for The New Yorker is so good. From The Gig Economy Celebrates Working Yourself to Death:

At the root of this is the American obsession with self-reliance, which makes it more acceptable to applaud an individual for working himself to death than to argue that an individual working himself to death is evidence of a flawed economic system. The contrast between the gig economy’s rhetoric (everyone is always connecting, having fun, and killing it!) and the conditions that allow it to exist (a lack of dependable employment that pays a living wage) makes this kink in our thinking especially clear.

The ethics of “conquering” other planets

I’ve been knee deep in hard sci-fi stories like Red Mars and Babylon’s Ashes over the past few months, so I have a special affinity for stories about space colonization at the moment. David H. Grinspoon’s The logistics and ethics of colonizing the red planet is a really interesting take on the ethics of colonizing a new planet:

Today on Earth we are grappling with the fact that you cannot “conquer” a planet, even if — especially if — it is your home and your life support system. If we go to Mars with the idea that we can charge ahead and subdue a new world, our efforts are doomed. We should rather study how we might learn to help cultivate a Martian Biosphere that is balanced and self-sustaining, as is the Earth’s.

When video games > work

The Economist has an in-depth and very interesting feature about people1 who forego regular employment to live with their parents and play video games instead. The kicker that Escape to another world closes with is quite something…

A life spent buried in video games, scraping by on meagre pay from irregular work or dependent on others, might seem empty and sad. Whether it is emptier and sadder than one spent buried in finance, accumulating points during long hours at the office while neglecting other aspects of life, is a matter of perspective. But what does seem clear is that the choices we make in life are shaped by the options available to us. A society that dislikes the idea of young men gaming their days away should perhaps invest in more dynamic difficulty adjustment in real life. And a society which regards such adjustments as fundamentally unfair should be more tolerant of those who choose to spend their time in an alternate reality, enjoying the distractions and the succour it provides to those who feel that the outside world is more rigged than the game.

  1. Well, young men… 

Rogue One as a story about engineering and design ethics

Spoilers abound so proceed with caution, but Rogue One: an ‘Engineering Ethics’ Story is so very good:

What Galen Erso does is not simply watch a system be built and then whistleblow; he actively shaped the design from its earliest stages considering its ultimate societal impacts. These early design decisions are proactive rather than reactive, which is part of the broader engineering ethics lesson of Rogue One.

The exploration of how Galen didn’t just walk away but took an active role in the destruction of the Death Star is interesting and highly relevant to what I consider an “ethical awakening” in our use of technology. It’s one thing to #DeleteUber — and those campaigns can certainly be effective, in that case to the tune of 500,000 accounts. It’s quite another to “infiltrate” your company and basically sabotage its technology because you believe it’s ethically dubious. The really complicated question is who gets to decide whether or not a company’s “ultimate societal impact” is good or bad. And, of course, who watches the watchers…

Doing research when you have no time or money

In How to get the most value out of remote user research (without breaking the bank) I write about our research process at Postmark. I know a lot has been written about research, so why add more words? The main thing I wanted to discuss is how we designed a process within a pretty impossible-sounding constraint:

Improve our products iteratively through research without slowing down our development process or increasing our stress levels at work.

So the post goes over the different things we put in place to try to do that. Check it out!

Alexa, make my kids more self-sufficient

I accidentally went to a Best Buy the other day. To make a long story short, after an unplanned but long and pleasant chat with an Amazon rep I walked out with an Amazon Echo. Much has been written about Alexa and how good it is, and everything you’ve read about it is accurate. But I want to focus on a different aspect of Alexa: how it’s making my kids more self-sufficient.

See, the thing about kids is, they need you all the time. And that’s cool, because we’re their parents and we love them and we want to be there for them. But some tasks are incredibly boring and menial. I’ve outsourced some of those to Alexa to the great delight of our kids, who continue to find new things she never gets tired of doing.

Alexa, turn on some music that Mom and Dad are totally sick of

The biggest win for my kids so far has been the realization that they can listen to any music they want to. Right now it’s the Moana and Trolls soundtracks. Over and over and over and over and over and… But that’s ok, because my wife and I can be in another room, and they can listen to Get your hair up as much as they want without driving us insane.

Alexa, help us not fight over the iPad

We let our kids do iPad. Let’s just get that out of the way first. Anyway, it’s usually a choice between TV or iPad, and when they choose iPad it tends to result in a constant fight over whose turn it is. Not any more. Now they each get two turns of 10 minutes, and Alexa keeps score. They use Alexa to set the timer, and there hasn’t been any fighting (well, about this…) since.

Alexa, make us laugh

My daughters aren’t big fans of my jokes. It’s fine, I’m not bitter about it. Anyway, they discovered Alexa tells jokes too. I personally think my jokes are way better than hers, and here’s my proof:

Like I said, I’m not bitter about it.

Alexa, are we bad parents?

This is, of course, the big question when it comes to technology. Should we immerse our kids in it or should we shield them from it? We all find our own way when it comes to parenting, and even though we’re still working on what this technology balance looks like, my current feeling is that voice-activated UI doesn’t have many of the issues that are traditionally brought up as negatives about kids and technology.

First of all, Alexa is inherently social. It’s conversational, friendly, and it never gets tired. We laugh at her together. The Echo is not an “alone” device, and I think there’s something really powerful about that. But second, it’s also really useful. Our kids love asking it questions, and coming up with new ways to trick it into a misunderstanding.

Conversational UI certainly has a long way to go. But I will say that I am so far pleasantly surprised with the natural way in which it integrates with our family life. It’s not a substitute for human interaction and connection, and our kids get that. But as a useful playmate of an entirely “other” type of technology, it’s a winner.

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


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…


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.


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.


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 113