K.Q. Dreger


Practical Productivity

Productivity is a combination of your ability to (a) get things done and (b) remember commitments. If you create and follow a system that helps you do these two things, you will likely be more productive than most of the people you know.

My approach was largely shaped by a combination of the following:

Search long enough and you’ll find guides ranging from the simple to the absurd. Everyone’s is different because everyone is different. Read my guide, read the ones above. Make your own. Just have something.

With that, here’s how I do it.

Stop using your brain

Computers are great at storing and recalling information—your brain is not. You want your brain to worry about the doing, not the remembering. Move your mental checklist into an app.

Whatever app you go with should make it easy to capture tasks on-the-go. It should also let you create different lists. Beyond those two requirements, the app doesn’t matter. (I use Things by Cultured Code.) Just pick the one you like best and commit to using it.

I recommend creating four lists:

  • Inbox: your digital dumping grounds. Put no effort into what you’re capturing here, just get it out of your head and into the app.
  • Next: all the things that, if able, you could work on right now.
  • Waiting on: sometimes your tasks will depend on someone else doing something. Track of those things here.
  • Someday: it’s not always the right time to work on something.

Using the system

Make a commitment? Add it to the Inbox. Remember you need to buy eggs? Inbox. Find an article you want to read later? Inbox. Don’t rely on your brain to remember this stuff. Your brain is not good at that. Stop making your brain do things it’s not good at.

Review the Inbox a few times per day. Move tasks into one of the other three lists. Sometimes the thing you put in the Inbox needs broken into a few smaller tasks—do that and then move them where they need to go. Over the next few weeks, you’ll get to experience the profound relief that comes with knowing your mental state of the moment has zero impact on your ability to (a) get things done and (b) remember commitments later.

Don’t overuse due dates. Only things that MUST be completed by a certain date should have a date. Otherwise you’ll have to think about whether a task’s date is fixed or flexible. Remove the ambiguity—either the date is the most important thing, or it doesn’t matter.

In addition to committing to this system, here are a few other tips:

Morning and evening routines: Every night, reserve 5-10 minutes to review your next day’s calendar events and scrub through your Next list. Highlight (and mark) the 3-5 things you want to work on the next day. Every morning, jump straight into your top task. Ideally you should schedule at least 30-60 minutes of uninterrupted time (especially before even checking email and Slack) to work on your top task. I have to block out the time on my calendar. This is usually 8:30-9:15 for me. I’m trying to extend that to a full hour.

Only check email (and Slack, etc.) twice a day: You won’t miss anything important, I promise. I check them once at 9:00 and again at 16:50. When you do decide to check the various inboxes of your life, always snooze, archive, or reply to every message. Leave your inboxes empty.

Get off your phone: If it’s for work, leave it on work devices. Checking our phones is my generation’s smoke break. Maybe you can’t delete email from your phone (although I’d encourage you to try). But turn off notifications for email, and set messaging to only send you notifications for channels you absolutely need to receive messages for. In general, remove any apps on your phone that aren’t for communicating between real people. This means most social networking apps, games, news. Set aside some time each night to binge those things. I promise you won’t miss them. They’re sucking your time away to the tunes of hours and tens of hours a week. If you choose to keep them, don’t then take to those same tools to complain about how hard it is to find time for your side hustle.

Finally, carry a notebook: I just told you to use an app, but apps require phones, tablets, or computers and I dislike those in meetings or on the go. A small notebook and pen are perfect as a short-term place to capture anything in your head. Write things down throughout the day, and then once a day move all tasks into the app and cross out everything in the notebook. This gives you the benefit of the app when it comes to organization and the speed/social acceptance of paper/pen when you need it.

That’s it. Four simple lists, a notebook, and an app.

Be careful not to let the process become the product. Too much and you’ll spend hours tweaking the system without actually getting anything done.

And remember: productivity for productivity’s sake is pointless. Make sure you’re actually working on things that matter. If you are, then spending an hour figuring out a system like this can be well worth the investment, and pay dividends for years to come.


Lately I’ve been thinking about Elie Wiesel’s quote on love and hate. “The opposite of love is not hate, it’s indifference” he says.

In software circles, we talk a lot about trying to create products people love. Like, really love. Love to the point you can’t wait to tell your friends. You’ve likely experienced this—an app so good you were excited to bring it into someone’s life.

Logically then, if the goal is Love, a product team might try hard to avoid making changes or additions that people hate. But more than hate, I think the bigger risk is making something to which people are indifferent.

Why not focus on hate? For starters, eliciting hate is actually quite hard to do if the product team is competent. Even talking with your customers once a week should steer you clear of danger.

Indifference on the other hand is a product killer. Building something that doesn’t even register an emotional response eliminates the opportunity to learn. And a product team that cannot quickly learn—and then iterate to learn again—is a team that will slowly bring growth and progress to a halt.

So when we think about the big risks of building products, we should consider indifference towards the top of the list. You can learn from love or hate. But the moment you sense indifference from your customers you need to reconsider the core problem you’re trying to solve.

If you don’t, I can promise you’ll hate what happens next—even if your customers don’t care.

Treat pain points as debt

Dave Ramsey has this great method for paying off debt where you start with your highest interest loan, focus all of your extra income on that payment, and then once you’ve paid it off you snowball that payment into the minimum payment of your next highest interest debt.

I think you can do something similar for products and user experience. Let’s call it The Pain Snowball Method.

Start by taking inventory of all the customer pain that’s been reported over the past month. Prioritize it based on what causes pain the most often. Take the top three reported pain points and dedicate time every week to finding solutions. Fix one of them, and then roll that time into the remaining two pain points until all three are resolved. Do it again next month.

As your product grows, not every customer will use every feature. In order to continue adding value for those customers whose needs are met, dedicate time to fixing pain just as you do to adding features.

Hierarchy of product team needs

I was on a run and thinking about Maslow’s hierarchy of needs and how a force ranked list of needs could apply to product teams. Here’s my attempt. Let’s walk through the levels:

Level one: talk with your customers daily.

You simply won’t have enough information to make good product decisions if you’re not talking with your customers every day. Call them. Email them. Ask them what they like, what they don’t like, what they wish your product could do, where they’re indifferent. Would they recommend your product to someone else? Who? Why not?

Level two: build and share prototypes.

You have customer feedback, and now it’s time to create solutions for their problems. A good product team should be able to quickly prototype (code, Figma, whatever) ideas that are Just Enough™ to demonstrate the value and begin to unearth usability issues. Prototypes should be lightweight and shareable with a single link.

Level three: implement lightweight metrics.

You’ve built some stuff and now it’s time to measure whether it worked. The metrics rabbit hole is rife with products and terms and general misdirection about what you truly need. Do a lot of reading, ignore most of it. A maturing product team does need some form of analytics and metrics to shore up what you’re hearing from customers—but you do not need to spend tens of thousands of dollars and two months integrating with one of the huge product analytics players right out of the gate. Not yet.

At this level, you only need to answer two questions: (a) what do we track to tell if our stuff is working and (b) how will we report on this data. For (a), basic things like page views, clicks, and lower level database fields can help indicate behavior (Have they turned on feature X? Set a date field with the date they turn it on.) For (b), you’ll either need to have direct access to the database and some SQL knowledge (it’s not hard to get the basics) or a web-based tool that simplifies the reporting for you. There are a lot of tools out there, just be extremely judicious about giving database access to a third party.

Level four: have a process for team self-improvement.

Ding. Welcome to level four. Enlightenment time. At this point, you should be completing enough create → ship → research cycles that recurring issues become apparent—especially if you’re looking at multiple product teams. Once you’ve identified these problem areas, you need to set aside time for growth and reflection. If you don’t, these small pains will become chronic injuries.

Companies that get stuck at this stage will hemorrhage good people. This is because good product people are used to improving through iteration, and they won’t hang around a company that doesn’t treat the team as its most important product. (Side note: your company is your most important product.) Self-improvement at this level can be as simple as design reviews, a book club, or team retrospectives. Just set aside time and do it.

Level five: refine delivery, release, and marketing ops.

This is the last one I could think of, and it’s all about making sure the people you’ve got doing the things on the bottom four levels are able to spend as much time there as possible. However, once you reach a certain size I think having a team or members of the team assisting in the delivery, release, and marketing of the things you ship can be a big time saver.

Regardless what you call it (product ops, project manager, etc.), it’s the acknowledgment that if you want product people talking to customers, creating prototypes, and looking at the data, then anything they do that aren’t those things is hurting the lower levels of the pyramid.

What’s not here?

A lot. I’m certain this isn’t one-size fits all. But in general, I think if you pour time into one of these levels without an equal or greater amount of effort going into the level below it, you’re setting yourself up for problems later on.