I fully agree with Chris Coyier’s main point in Other People’s Busted Software is an Opportunity:

If you make software that does work reliably, you’ve got a leg up. Even if your customers don’t tell you “I like your software because it always works”, they’ll feel it and make choices around knowing it.

It feels like so many teams prioritize “innovation” over quality, so we end up getting stuck with products that have an overwhelming number of features but they all barely work—or the whole thing is slow and cumbersome. At some point we seem to have forgotten that product quality is not optional, and that it should be built in from the start.

Not only that, but in a “project” mindset teams just continue to move on to the next feature without taking the time to learn and improve what they shipped, as Marty Cagan points out in From Projects to Products:

Most efforts lose all hope of providing real value, and just try to get something shipped. Then as soon as they do finally ship, it’s not like they can iterate to improve the product. Instead, the people usually scatter off to their next assignments; nobody owning the outcome, and any important learnings from the effort likely lost.

This seems almost silly to point out, but a feature is not going to help your business if (1) it doesn’t add value and/or (2) it doesn’t work well. And yet somehow lots of teams put validation and quality on the backburner while they rush to get more features out. So Chris is right in his post: focusing on product quality is a huge differentiator in today’s software market.

Ask Questions, Repeat The Hard Parts, and Listen →

Michael Lopp’s latest is an excellent reminder of what good leadership is all about:

Earlier in this piece, I wrote I was disappointed when you asked me to decide. I’m not disappointed in you; I’m disappointed with myself. See, my primary job as your leader is to give you the skills and experience I’ve gained over the years. If I cannot guide you toward making the decision, I’m reminded I’ve not yet achieved my primary goal in our professional relationship.

My job is to teach you not to need me.

The Creators of Disney’s New Platformer Explain the Hard Lessons of Making Games for Kids →

Patrick Klepek writes about making games for kids, but there are some great generalizable product lessons throughout. Like this reminder not to drift toward the “average” user:

“We have this phrase internally, we say ‘don’t make a rosé,” said Grand-Scrutton. “And it’s because one of my friends in the industry, one of my mentors, he said this phrase to me, and he said that if you go to a restaurant and you’ve got someone that loves red wine, or someone loves white wine, you don’t give them a rose because no one’s happy. You gave them an awesome red or an awesome white. So we say that internally, when we are riding this line of only half doing something, we say ‘it’s too rosé.’ Rosé is a perfectly fine wine choice, but we felt we were rosé-ing it.”

Failure →

Mike Fisher writes about a really interesting tool to get teams comfortable with taking risks, called the Failure Workshop:

One strategy to familiarize team members with failure is to conduct a Failure Workshop. Think of it as a tabletop exercise on failure in a safe environment. The workshop’s objective is to “stay in the failure” while fostering a supportive space for peer interaction. This is similar to a pre-mortem but it keeps the participants thinking about possible failure scenarios instead of brainstorming solutions. 

Reality has a surprising amount of detail →

I missed this 2017 piece by John Salvatier, and it’s so good. He talks about how easy it is to get intellectually stuck in our ways, and how to break out of that:

The direction for improvement is clear: seek detail you would not normally notice about the world. When you go for a walk, notice the unexpected detail in a flower or what the seams in the road imply about how the road was built. When you talk to someone who is smart but just seems so wrong, figure out what details seem important to them and why. In your work, notice how that meeting actually wouldn’t have accomplished much if Sarah hadn’t pointed out that one thing. As you learn, notice which details actually change how you think. If you wish to not get stuck, seek to perceive what you have not yet perceived.

Fitness Technology and the Templated Body →

In today’s example of “technology is not neutral” Audrey Watters talks about how depressing fitness tracking can be:

Fitness technologies shape how we think about fitness; they shape how we think about our movement — why we move, how we move, and so on. We covet the gadgets that promise to give us more and more data and deeper and better insights about ourselves, supposedly to learn more about ourselves. And yet, we are simultaneously un-learning to trust ourselves (or trust professionals — our teachers and coaches), waiting for the “nudge” and the badge to compel us move.

Related, also see Lukas Mathis’s Streak Redemption about what happens when you break a streak in one of these apps:

Conversely, losing a streak can be so demoralizing that it can be difficult to start from scratch, and get going again.

The Slow Productivity of John Wick →

You’re going to have to trust me that this is actually really good:

John Wick may be shallow entertainment, but the story of its success highlights some deep lessons about what the rest of us might be missing in our pursuit of a job well done.

A Practical Guide to Executive Presence →

Some great advice here:

If you take nothing else away from this post, it’s this first point: Don’t freak out. Visibly losing control of yourself is one of the most damaging ways that leaders self-sabotage. Seeing the person who’s supposed to be in charge lose control under pressure is confidence-destroying and can take a very long time to recover from.

Also:

You only sound as smart as the dumbest thing that comes out of your mouth. The more you say, the more dumb stuff that you have the chance to say. Consciously try to have a timer going in your head that tells you to wrap it up after you’ve been talking for ~30 seconds, unless there’s a specific reason that you need to speak for longer (e.g. a presentation).

There’s a sentiment I started to see in the agile development world that advocates for deleting old/stale items off a backlog completely. A good recent example is Jason Knight’s latest newsletter:

The backlog becomes a dumping ground for every single customer support query. Every account manager and every salesperson has something in there from conversations with customers and prospects. […]

It’s tempting to see “length of time in backlog” as some kind of vector for prioritisation, but it really isn’t. It’s quite the inverse, in fact. So let’s all try to get comfortable, embrace the idea of getting rid of old stuff in our backlogs, and give people a “no” rather than a “one day”.

I’m not trying to pick on Jason—his work is great and it’s another very good edition of his newsletter! I am just using it as an example that got me thinking about this a bit more deeply.

My take is that we should absolutely keep all customer feedback around in our backlogs, because that is continuous discovery data that would be a shame to lose. Instead, my proposal would be to normalize the backlog as a place to build organizational memory and a customer feedback knowledge base—not as a list of things that all have to get done.

Two tactics can help with this approach. First, a Now/Next/Later roadmap keeps the focus on the list of current priorities. The entire backlog doesn’t go into the “Later” column—only things that are currently prioritized to start within the next few months.

Second, have a standard process that the entire company (especially the customer success team) can use to collect user feedback and attach it to features. In our case that’s Productboard, and our success team can easily add and process customer feedback via a browser extension.

I guess our list of features in Productboard is technically our “backlog”, but it doesn’t cause us stress in terms of feeling like we need to work on everything that’s on there. However, as part of our planning cycle we can go through this list and figure out if anything is important enough to pull into the “Later” column of our roadmap. An added bonus: if/when we start to work on any of those features we have access to lots of customer data about each feature, and we can reach out to those customers to have more in-depth conversations with them about their needs.

So instead of deleting old issues off our backlogs, let’s rather remove the pressure and stigma around what backlogs are for (maybe we should rename it to “customer needs knowledge base”?). And then let’s use our actual roadmaps for the list of things we know we’re going to work on.