Staying Productive with Progressive Refinement

Getting things done using Agile Principles like "Fixed Time, Flex Scope"

Recently, I had a child, and it changed my life more than anything else has.

I used to think that the hardest thing for me socially is training and managing my junior employees or fresh grads in Monolith. I've probably trained at least 70, all with their own quirks and habits, and I think I have that down at this point.

However, the adjustment I had to make once I had a child is probably 10x more than any of those combined.

One of the major changes that I had to make was my creative process and my planning process at work. Normally, I'd sink perhaps 3-6 hours just working on one thing. I've you've followed me before, you know that I'm a giant fan of detailed long form content.

But I can't do that anymore especially at home as I'd probably need to attend to something every 30 minutes or so.

Despite these constraints, a method that has worked for me is the idea of Progressive Refinement. It's inspired from agile principles such as "Fixed Time, Flex Scope" and "Earliest Lovable Product".

If you're not familiar with the idea, here's how it works:

1. You start with the problem you'd want to solve

2. Define the budget that you currently have, whether it's in time or resources

3. Based on that budget, define a version of the task that fits that budget. An important mindset shift is that there is a complete version that solves the problem whether it's just 10 minutes or 6 hours.

Here's an example for creating a strategy slide deck:

• Let's say you'd want help reduce burnout within your organization

• In terms of time budget, let's say you only have 10 minutes before your next meeting or next task

• For that given 10 minutes, what can you do? You probably can write out headlines of the slide deck (no body), with the key ideas (e.g. Slide 1: Burnout is caused more by social factors in our organization as opposed to overwork or overload, Slide 2: People who tend to get burnt out are managers, Slide 3: Managers observed that some juniors have not yet adjusted fully to the culture, etc.)

Now that's version 1 -- it is an acceptable version as it already has an answer to the problem that you're looking to address. Once you have another 10 minute time block or 30 minute time block, you can expand on some points further, and that would be version 2.

You may not arrive at the perfect version of what you're trying to do, but you know that the slides do not have any gaps and you've covered the full ground of the story that you're looking to express.

You'd see some similar "version ones" as well in another formats:

• For articles, don't start with a full draft, but start with bullet points.

• For design, don't start with Photoshop or Figma, start with a sketch.

• For code, don't start with the actual programming logic, start with the architecture or start with the relationship diagram that solves the problem.

The big idea behind Progressive Refinement is that the format is flexible. So don't think of "hey I need to make slides", but instead, you need to think of "hey, I need to solve X problem, what format is appropriate for this in the given time?".

Here's a final diagram Henrik Kniberg that illustrates this idea.

Do the solution, not the format.

P.S. Here’s my 10-minute version 1 of the above article :)

Bullet points:

- Recently, I had a child, which is certainly the biggest change that I had in my life. I've worked in other countries and with other cultures, I've managed and have had 1:1s with at least 70+ people in Monolith, all with their own quirks, but the adjustment I had to make once I had a child is probably 10x more than any of those

- One major change that I had to make was my creative process and my planning process. Normally, I'd sink perhaps 3-6 hours just working on one thing. I've you've followed me before, you know that I'm a giant fan of detailed long form content. And if you're an employee of Monolith, the first you'll read is a 21 page culture document that I wrote up and I expected you to know by heart.

- But I can't do that anymore especially at home as I'd probably need to attend to something else every 30 minutes and I'd lose context on what I'm working on

- A method that has worked for me despite these constraints is the idea of Progressive Refinement. The basic idea of Progressive Refinement is that unlike the conventional way of working, which is to just have 1 version of something, and get that 1 version done by any means necessary (i.e. either rushing through everything with the given amount of time or extending as much as you need to), your time budget is fixed, and you plan for multiple versions.

- Here's how it works:

1) you start with the problem you'd want to solve,

2) define the budget that you currently have, whether it's in time or resources

3) based on that budget, define the refinement level that you want to use. For an article, for example, it could be just bullet points that encapsulate the idea. For slide decks, you could start with just the headlines of the slides first and put placeholders on the body. For code, it could mean just writing the pseudocode first, and get the data structures right before writing the rest. For UI design, it means building out a layout first before the colors, shadows, and other details.