As with many distributed teams our approach to tools at Wildbit is to try to strike a balance between making sure everyone on the team knows what’s going on, and not having hours of meetings every day. We are very serious about the ability to have a lot of time during the day for focused work, so we sometimes err on the side of not enough meetings. For this reason the team hasn’t done formal daily standups for a while, instead opting for a weekly meeting to do a roundtable of what everyone’s been working on, and what the plan is for the week.

There are a couple of problems with this approach. First and foremost, it doesn’t always feel like time well spent—we shouldn’t be spending an hour a week just talking about what we’re doing. That’s why we have planning tools1. Another side effect is that it’s harder to respond quickly when issues come up. If a team member is having a problem, or we didn’t realize before that two projects are related somehow, it could take up to a week to find out what the issues are. So we wanted something better. Something lightweight, useful, and more frequent.

We realized early on that synchronous standups wouldn’t work for us—we just work across too many time zones to find a convenient time, and it also doesn’t make sense to have a standup at the end of someone’s day. We also didn’t want this to be just an update for everyone else, we wanted to make it a useful planning tool for individual work as well.

So we started looking for Standup bots built for Slack, and of course there are tons of them. We ended up signing up for Geekbot because it met our most important criterium: it’s asynchronous. We set up Geekbot to ask each team member (product, design, engineering, and QA—we’re all in this…) a set of questions at 9am in their time zone. This means each team member can use these questions to be thoughtful about their day and what they want to accomplish.

In order to make this more useful for us we also changed the questions a little bit. Usually the first question in a standup is “What did you accomplish yesterday?” This didn’t feel right to us—it felt too much like checking up on each other. Instead, we ask the question this way:

Did you work on what you wanted to yesterday? If not, what happened?

This might seems like a subtle change, but it shifts the focus quite a bit. Instead of listing out the things we did, this question allows us to tell each other if something happened that distracted us from the work we wanted to do, which helps us solve those issues as well. So here’s what our Geekbot setup looks like:

Every time someone answers these 3 questions, Geekbot posts a status in our #pm-standup team room in Slack, where we can all read through it on our own time.

There is, of course, nothing groundbreaking about what we’re doing here. But I wanted to write up our process because I know there are many distributed teams who struggle with this. 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 keep an agenda as we progress through 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.

So even if your remote team is against the idea of a standup, I recommend you try something like this. Don’t just do what we did though. Choose your own questions, your own cadence, maybe even your own tool. But do something—start with the question “How can we make frequent checkins useful?” and see what the team comes up with.

---

1. I have a whole other post planned about using Jira in small teams… ↩

I get these weird obsessions sometimes—a thing that starts small in my head until it becomes all-consuming for weeks on end. Maybe you can relate? Anyway, my current obsession is centered around jazz, and how much we can learn from it about technology, how we listen to music, and yes, even design.

If you follow me on Twitter you’ll know that I just finished reading How to Listen to Jazz, a book I thoroughly enjoyed. I shared screen shots of some of my favorite sections from the book here, but suffice to say it is about so much more than jazz, and I highly recommend it not just for music lovers, but for anyone who works in a creative role.

Right on cue, as so often happens on the internet, I came across Ken Norton’s excellent post Please Make Yourself Uncomfortable, about some of the leadership lessons we can learn from great jazz records (especially the all-time best one, Kind of Blue):

Miles, Ella, and Duke were adept at guiding their bands into the optimal anxiety zone, making them restless and opening up a space where they could create masterpieces. Such talent is also needed in product management. So much of what we’ve learned, our instincts, are to do the complete opposite. We’re told to minimize risk, communicate a clear plan, and document every step. As product managers, our most important job is to help our teams find the place of optimal discomfort—the goldilocks zone of ambiguity and uncertainty.

The same day I read Gretta Harley’s The Slow Listening Revolution, about why she still has a vinyl collection:

Why vinyl? Commitment. In this mid-second decade of the 21st century, music is being taken for granted on a collective scale. An entire generation of music listeners will never pay for music, nor do they believe that they should. The long form music medium has taken a back seat to song culture, yet the average person only listens to a song for approximately 24 seconds before deciding if it’s worth their time to continue to listen. I ponder the substantive value of something that our capitalistic, corporate-model culture places on “free.” When we can listen to a whole song, or usually only 24 seconds of a song without paying for it, do we really value the music? I wonder if we listeners are as committed to music as we were pre-internet? I really like the internet, so these words are in no way a complaint or indictment, but merely observation.

All of this—jazz, new music, old habits—came together as I picked up Dire Straits’s 1985 CD Brothers In Arms, which in some versions had this cover:

It used to be that proclaiming “A FULL DIGITAL RECORDING” was a selling point. Now, the first thing I look for when I buy an album is the phrase Mastered from the original master tapes, a sure sign of its 100% no-digital, analog-only experience.

Or, wait, maybe we’re just being anti-technology in our criticisms of digital music? There has always been a reluctance to adopt new things—a longing for the past and how things used to be. Clive Thompson gives us another example of this historical skepticism in That cursed newfangled technology, “electric lights”:

Robert Louis Stevenson penned “A Plea for Gas Lamps” in 1878, hoping to dissuade London’s authorities from installing obnoxious electric streetlamps like those in Paris. “A new sort of urban star now shines at night,” he wrote, “horrible, unearthly, obnoxious to the human eye; a lamp for a nightmare!”

So I don’t think we’ll solve this particular “which one is better” musical argument any time soon. But if history teaches us anything, it’s that it’s not a new argument, so we should just roll with it. And rock with it1.

---

1. Sorry, that’s a really bad joke. I’ll see myself out. ↩

I recently started a new remote role as a Product Manager at Wildbit. And by “recently” I mean I’m on Day 4, so my experiences with full-time remote work is demonstrably limited. That said, there is one thing so far that I appreciate more than anything else about working in a dedicated office space in my basement: The Calm.

I say The Calm with due reverence because I don’t just mean quietness (I have music playing most of the time). I mean the relaxed ability to work focused and uninterrupted for long periods of time. The joy of this kind of work environment is hardly a new discovery, but since I’ve always worked in open offices this is a brand new and extremely joyful thing for me.

I suspect this is also the reason why everyone in our main office in Philly has their own office. It’s not that I (we) don’t like people. It’s that I get so much more done in a day while working in an environment where I’m able to shut everything else out and just work. The problems with open offices are well documented, of course. From The Economist’s Inside the box:

Open-plan offices are noisier and more interruption-prone. Too much noise causes high blood pressure, sleep problems and difficulty in concentrating. And cubicles’ flimsy walls do little to dampen sound. In studies where sound levels were raised from 39 to 51 decibels—roughly equivalent to moving from an average living room to a road with light traffic—participants were more tired and less motivated.

From Maria Konnikova’s The Open-Office Trap:

In 2011, the organizational psychologist Matthew Davis reviewed more than a hundred studies about office environments. He found that, though open offices often fostered a symbolic sense of organizational mission, making employees feel like part of a more laid-back, innovative enterprise, they were damaging to the workers’ attention spans, productivity, creative thinking, and satisfaction. Compared with standard offices, employees experienced more uncontrolled interactions, higher levels of stress, and lower levels of concentration and motivation. When David Craig surveyed some thirty-eight thousand workers, he found that interruptions by colleagues were detrimental to productivity, and that the more senior the employee, the worse she fared.

And yet, despite all the evidence against it, open office plans persist in most companies, and will for a long time to come.

But yeah, it’s Day 4. Let’s see if I go crazy after a couple of weeks…

A few years ago I almost went insane with commute-madness (which I’m reasonably sure is a thing). We lived in Bloubergstrand in South Africa, and I worked in the city of Cape Town. This meant that I had to be out of the house and on the road before 6am every morning (and leave work before 4pm), otherwise I would spend upwards of 90 minutes in traffic, as opposed to the more manageable (or so I thought…) 50-60 minutes.

It’s a little too soon for me to talk about the effect that commute had on my mental health, so I’ll just say this: I didn’t handle it well.

So I, along with thousands of my fellow commuters, rejoiced when the city of Cape Town extended the popular MyCiTi bus service out to where I lived. My joy was short-lived though. It turned out that even though they extended the bus line, the City decided not to provide parking nearby. So unless you lived within walking distance of the bus stop (which I didn’t) you were out of luck.

This seemed really silly to me, so I asked about it, and found out that the City didn’t want to provide parking until they could prove that the bus line was successful. It doesn’t take much to see the gigantic failure in logic here. The City didn’t want to provide parking until they could see that enough people used the buses, but not enough people can use the buses if there isn’t parking.

We ended up moving back to the city.

I tell this story because I recently got into a discussion with Vincent Hofmann, based on this tweet of his:

Cycle lanes in South Africa are a great idea but we’ll need orgs to get ready for healthier commuters with supporting infrastructure.

— Vincent Hofmann (@vincenthofmann) March 7, 2016

I brought up the MyCiTi thing, and then mentioned how different the experience is here in Portland, where I live now. I bike to work every day, and the only reason I can do that is that the end-to-end experience is designed well. It’s not just about the city installing bike lanes. Neighborhoods have to agree to stricter traffic rules. Companies need to provide facilities for safe bike parking and showers. It’s a collaboration between public and private sectors across the city. If anyone doesn’t pull their weight, the whole thing falls apart.

Luckily, in Portland, it all hangs together really well. Here are some photos of my end-to-end biking experience in Portland:

There is, of course, a big product management lesson here. We often spend so much time trying to perfect the experience people have with our products online, and we forget about what happens before and after they get there. And that’s often where the experience breaks down and we lose customers. As an example, I mentioned in my newsletter over the weekend how frustrating it can be if you can’t contact a company after making a purchase:

It sounds obvious, but it is still amazing to me how many companies see support as a liability. Any opportunity to interact with customers is a good thing. Yes, it’s expensive, and “case deflection” is a very effective way for companies to cut costs, but at what cost? A case deflected—either through finding the answer on a forum, or a customer simply giving up when they can’t figure out how to contact the company—is a missed opportunity to build loyalty and get input on your products.

And this, ultimately, is why customer journey mapping is such an essential activity for any product. It forces us to think about designing the end-to-end experience, from long before people get to our site, until long after.

Evidence of the danger of only focusing on the product experience itself is all around us—just look at the way our cities design public transport and bike commutes. Notice the differences between the two examples I shared above—one set up for failure, the other for success. And let that be a challenge to all of us to think about how people experience our products even when they’re not using our products.