Hard first or easy first?

Written by Signal vs. Noise - - Aggregated on Saturday January 27, 2018
Tags: project-management, product-design, product-management

Accountants have FIFO (first in first out) and LIFO (last in first out). Product designers have HFEL (hard first easy later) or EFHL (easy first hard later).

No matter the project, there are things you’re more confident about and things you’re less confident about. No brainers, maybe brainers, yes brainers. Assuming you have limited time to complete a project (we spend a maximum of 6 weeks on most projects), you have to decide how to sequence the work. Do you pick off the hard stuff first? Easy stuff first? What to do?

It depends, of course. I don’t have any answers for you, but I can share some of the things we think about when deciding what to do when.

First we get our bearings.

Does this feel like a full project? Is it probably going to take all the time we have? Lots of moving parts? Does this work touch a lot of other things, or is it mostly self-contained? Do we feel like we’ve mostly got it down, or are there some material unknowns we haven’t quite nailed down yet?

If it feels big, and full, and challenging with some significant unknowns, we almost always start with the hard stuff first. The worst thing you can do in that situation is kick big challenges down the road because you’ll inevitably run out of time. You’ll either make bad big decisions that way, or you’ll push the schedule out, or you’ll work late or work weekends. All those are big no-no’s for us, so we tackle the hard stuff first.

Sometimes we start with a quick spike. We put a few days into it and see if we’re able to make any meaningful forward process. That’ll reveal if the problem is really as big as we think it is, or we’ve been overestimating the shadow of worry its been casting. But waiting until later isn’t an option. We chip away at the big rock to see if it’s sandstone that’ll break down easy, or granite that’ll require heavy machinery.

Once we have a sense of where we’re at, we think about what we need, as a team. I don’t mean what does the team need as far as tooling or technology goes, but what do we need emotionally? Do we want to slog along without any short-term visible progress, or can we grab a quick win and start to pick up some momentum? It depends — how did the last project go? Are we coming off a high or a low? If a low, maybe we should find some quicker wins to fuel the spirit. If a win, maybe we’re already feeling good enough about ourselves to go heads down without anything material to show for a few more days. The past plays a surprisingly important role in the present.

We’re currently working on some significant improvements to the way our customers work with their clients in Basecamp 3. It’s a big project, and we’ll likely be working on it over two 6-week cycles. There are unknowns — both technical and visual — but the last time we tried to tackle this problem we ended up putting a lot of work in with nothing to show in the end. We didn’t ship what we built because we 1. didn’t finish on time, and 2. didn’t feel great about what we built, and 3. didn’t want to put more time into a bad time. Therefore, this time, we ran easy and hard in parallel. The programmers worked on a hard problem first, and the designers worked on an easy one. It was a nice way pour the concrete foundation and choose the paint colors at the same time.

On the design side of things, we often try to stay away from the details early. Details can turn into quicksand. We never want to get stuck on something early on — that’s a surefire way to burn too much time on something that’s going to change later anyway. Never ever get stuck on something you just know you’re going to change later. So when we start a design project, we typically go from very big to very small. It’s a bit different from choosing hard first or easy first, but it’s still a choice. We still have to decide where to begin.

One other thing I wanted to add, but don’t know where to put: We aim to avoid feeling like we have something to prove. That’s hero language, and we don’t do hero. We do work. We have work to do. Big and small — we’re satisfied by doing good work and getting it done in the time we give ourselves up front. Heros are only satisfied by rescuing things, doing the impossible, or saving the world. We’ll leave those antics to teams that run on fumes. We’ll run on a good night’s sleep.

I wrote this essay without reading it back — a stream of consciousness burst. I’ve had a bit of writer’s block this week, so I’m trying to bust through by just writing raw thoughts and getting my fingers moving again. I hope it was helpful. Any questions?


Hard first or easy first? was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


« Fix PhpStorm Not Focusing When … - colinodell.com - Blog

Digital Inspiration Technology Blog - How to Send Emails with Google Forms … »