Eraser or the Wrecking Ball? Planning is everything

The way you get your work done has a direct impact on how well it gets done, especially when working with teams on problems of increasing complexity. Time spent planning multiplies your productivity.

The title of this post is inspired by a Frank Lloyd Wright quote that became a mantra for my team while I was working at Gymnasium:

An architect's most useful tools are an eraser at the drafting board and a wrecking ball at the jobsite.

Planning is everything.

Building products for real people is a really hard. Even if you've found an audience and a product idea that you're confident in, doing a great job of building the thing is always going to be challenging. I had the great fortune of working at Microsoft in my first job after university, where I was able to work on some pretty incredible teams of experienced engineers.

One of the most important things I learned in that job was a framework for building products in small, iterative cycles, which I've been using ever since. It breaks down each project, milestone, and feature into a few simple phases:

In the envision phase, you're trying to understand the problem. This is where you capture the hopes and dreams of the people who will be using your product. This is where you get your baseline requirements from, in the form of user stories, feature lists, diagrams for workflows, and other documentation.

In the planning phase, your job is to break down a complex problem into smaller parts. Ideally, this is a list of small tasks that can be completed relatively quickly. I usually shoot for no longer than 1 day. It's helpful here to think about inter-dependencies between tasks, and to capture things that aren't strictly code: documentation, updated test cases, API endpoints that may change, UX work that needs to be done, and so on. You'll want to capture dev tasks, too - list out everything that needs to be done to get the feature working, even if it feels pedantic.

This is a critical bit of work, especially if you're working with non-technical people: this list of tasks is your best reference point when someone asks "what's left to do?" or "why isn't this done yet?". Combined with the details you captured during the envisioning phase, you should have a clear picture of what you're going to build, as well as the decisions made to get there.

Most importantly - at this point, anyone on your team should be able to read through this list and understand the work ahead, and even pick it up and run with it if needed. It means you won't have to answer questions in JIRA while you're sitting on your next vacation.

Planning is the step that we all tend to resist; it's easy to do. Fueled by excitement of something new, this step is the most likely to be overlooked. I've absolutely done it, and more often than not it

Skipping this step is a surefire way to miss important details; it's common during planning to unearth requirements that were missed in the envisioning phase - and it's a lot easier to fix them at this stage.

This is the one we're all chomping at the bit to do: coding away furiously to make the feature come to life, and to build out all of the exciting bits that comprise it.

This is the pre-deployment step where you write tests, conduct QA and acceptance testing, and make sure everything is working as expected. It's a good time to check in with the team to make sure everyone is on the same page, and to make sure you're not missing anything (even if it wasn't documented before!).

This is also a good moment to prepare documentation, demo videos, and other materials that will help your launch be a success.

🚀 Launch it!

Get your feature into the hands of your users, share documentation and demos with the world, and start gathering feedback. This is a great time to use product analytics and the telemetry you have available to learn whatever you can from the way people are using your feature, and to plan the next version.

Then go back to the start: the whole cycle starts again.

It takes practice and discipline to get this right, but it's worth it.

Outlier (by Scale AI) is hiring frontend devs to help train cutting-edge AI—no AI experience needed. Work remotely, set your own hours, and earn up to $50/hr reviewing code and UI, with weekly payouts.

Help shape the future of dev tools - apply now

Earlier this week, I came across Debug with Notes, by Tyler Williams on BlueSky. His process involves taking detailed notes while working through a bug; it's a super helpful pattern for tackling situations where you're unfamiliar with the codebase, and to give yourself a point of reference if you get pulled away from a problem before fixing it.

LeadDev has a great article on a tech lead's guide to effective communication that I keep bookmarked. It's a great reminder that communication is a skill which can be improved with practice.

This is normally where I'd shout out the free courses offered by the gang I used to work with at Gymnasium, but I'm sad to say that Gymnasium was shuttered at the end of May.

If you're hiring for UX leadership, marketing or technical learning, my former colleagues from Gymnasium are world-class. Drop me a line, I'd love to set up an introduction.