There’s this local restaurant I go to a lot – it isn’t much to look at from the outside, and truth be told, the inside is kind of dingy. The menu is a mess of misspellings and grammatical mistakes inside a cracked, yellowing plastic sleeve, orders sometimes get lost, and one of the waiters is actively belligerent to the diners. I frequently see people scurrying away after a quick peek inside, and have occasionally even seen customers stand up and leave in the middle of a particularly choice back-and-forth with the problematic waiter. Its sole redeeming grace, and the reason it’s been able to survive this long in an otherwise cursed strip mall, is that the food is inexpensive and excellent.

One of the things about being a parent of young children is that you’re occasionally thrown together in an enforced social situation with a completely random selection of other adults. And so it was, during the interminable, farcical spectacle of first grade soccer practice (in which some kids home in on the ball with the focus and ferocity of otters attacking an improbably mobile clam, while others traipse blithely across the field with little or no consciousness or interest in the ball, other players, or any externally recognizable purpose), that I found myself chatting with the owner of my favorite falafel joint.

He recognized me, of course – he doesn’t have many regulars. And, after lamenting the difficulty he’s been having making ends meet, he started talking about some big upcoming changes he hoped would improve business.

“You know,” I said, “I’m not sure a big ad campaign is really the answer. From what you’re telling me, you’re getting a fair amount of foot traffic already – it’s just hard to make them come in and eat.” I mentioned the menus, the peeling paint, the waiter. “These may seem like small things, but I think they’re what’s driving people away.”

He waved me off. “Of course, of course, I know all that – those are easy to fix, and I’ll get to them, but the Friday night open mic poetry slam is really going to drive some traffic.”

“About that,” I said, “and the petting zoo. I mean, it all sounds great, but the menus, the atmosphere, the waiter-”

“Yes, yes, my friend, I understand! These are issues, to be sure, and have all been appropriately prioritized in our Jira backlog – they’re just not at the top of the list right now. I’ll get to them after we’ve upgraded the bathroom, installed the hedge maze in the parking lot, and taught the waiters to mime.” He paused, eyes alight at the possibilities, then shrugged. “Maybe sometime next quarter.”

Control Rods

There are plenty of terrible products out there. Things that no one wants, no one could understand anyone else wanting, and that surface briefly as “Show HN” novelties before disappearing without a trace. And, while there’s no doubt a fascinating blog post waiting to be written about why we create trivialities, absurdities, and monstrosities, I’m much more interested in thinking about apps that could be great. Your app. That thing you’ve been working on that people actually want, that has a small but happy user-base, but just can’t seem to make it to the next level.

If you have more than one happy user, you know that in a world of infinite possibilities and impossible to find domain names, you’ve discovered something that might have a chance. And yet, and yet. No matter how rabidly enthusiastic your twenty core users, you haven’t managed to expand the pie. Clearly, you need another amazing feature.

No.

No, no, no.

Now’s the time to find and eliminate your control rods. Control rods, for the uninitiated, are bars of heavy metals inserted into nuclear reactor cores to absorb some of the neutrons, and thus slow down and control the overall reaction. When you’re worried about the safety of Western Civilization, control rods are a Good Thing™. For your site, though, they’re death on wheels, or, in project-speak, “friction”.

Seriously. You have a solid product. You’re delivering quantifiable value. But for some reason, the uninitiated aren’t getting it. Now isn’t the time to hire Cirque du Soleil and the Blue Man Group to do a dance fight on your home page. This is the land of P1s – features you think need to be built, that you think will make a difference, and convince users who would otherwise pass on by.

Except they won’t. New users are still going to bounce on the page that’s broken and hasn’t been prioritized for fixing. They’re going to get frustrated at the long load times, confusing layout, and awkward flow from here to there. Bugs that seem like minor annoyances to you are going to feel insurmountable to them, and additional steps won’t just halt one interaction – they’ll poison the overall experience. People are going to squint at the screen, scrunch up their faces, sigh, then leave forever. They have better things to do with their time than play Choose Your Own Adventure with your interface.

When you have a solid core product that people don’t understand, the majority of your effort should be spent on removing steps, fixing bugs, sanding down corners, and improving messaging, not adding new features that only your existing users will see. This can be frustrating. It isn’t necessarily fun to do regression tests, rework existing interfaces, A/B test copy and tweak CSS. It’s so much more exciting to roll out new features and take big swings, than to grind on bugs and minor annoyances.

Let’s be clear – it’s critically important to prioritize. P1s need to come before P2s, which need to be done before P3s, and so on. At the same time, the aggregate P2s and P3s in any sufficiently mature backlog will typically represent a significant barrier to a user’s experience. These are the bugs that weren’t critical to fix before launching a new feature, then were pushed aside and forgotten in the rush to build the next new thing. And unless a user happens to be using the same browser as the developers, on the same platform, with the same screen size, and happen upon the optimal signup, login, and conversion flow, they’re going to run into a low probability bug, broken feature, confusing CTA, or sub-optimal flow. Of course, this is “unusual”, and can be waved away – most users won’t have this exact experience. But the same could be said of anyone who doesn’t run through the optimal flow as laid out and tested in your QA checklist.

Unfortunately, this is hardly prescriptive. You can’t just go to your daily stand up and say, “DanB told me to ditch all my tasks and get to work on the P3 WONTFIXes”* (though if you do, Periscope or it didn’t happen). What you can do is to set aside time for polish, improving flows, reworking messaging, retiring technical debt, and “bug batches” (time-boxed projects with a prioritized list of P2s – depending on the product, team, and backlog, this could be one week a month, or an ongoing rotating responsibility). These are your control rods – individually, they might not seem like much, but they’ll act as dampers that will continually block you from getting traction.

One last note – every engineer, and I mean every engineer, has a private list of crappy, buggy, inefficient, out-of-date, or just plain broken code that they’re itching to fix. They’ll attack something on their own time if its level of awfulness passes a certain threshold, but these mostly hover somewhere between petty annoyances and minor mental anguish. Initiative’s great and all, but as a manager, you should be trying to get these into the open and onto a list, not depending on personal heroics to catalog and prioritize bugs that impact your product.

* For the record, I think “DanB and the P3 WONTFIXes” would be a kick-ass band name.