Progress Resolution

When building software, we’re surrounded by unknowns, assumptions, and risks. Yet we fool ourselves into thinking we can assign a fixed quantity to the status of work. If we just plan enough, talk enough, or ask enough questions, then we’ll turn the unknowns into knowns, the assumptions into validated truths, and the risks into sure things. Right? Sadly, no. And the best preventative measures are often paradoxical in nature:

• Focus on the problem, not the solution.
• Reduce the fidelity of design.
• Modify scope as you go.

When you let go and trust the process by building resilient teams of product builders, you create an environment where progress is measured by the quality of work. Because progress in software development isn’t about quantity or linearity. You’re not moving a pile of rocks from one spot to another. If it were, you could reliably measure progress in percentages:

I know we’ve moved 10 out of 20 rocks, which means we’re 50% of the way there!

Now imagine your team is building a new feature. The engineers are writing code, answering unknowns, and working towards a solution. There’s a list of 20 tasks identified and tracked, and 10 are complete. Does that mean they’re halfway to completing the work?

Absolutely not!

Why? Because the quantity means nothing in absence of quality. Context matters.

• How large is the effort of those tasks?
• Has all the work been identified?
• What unknowns are left?

You could have 99 of 100 engineering tasks complete and it doesn’t mean you’re 99% complete. Unless you have a clear understanding of the entire scope of work, you’re flying blind until you answer unknowns and create working software. It’s like trying to make out the details of a low-resolution photo. You need to increase the resolution to see clearly. And progress needs resolution, too.

This idea is called Progress Resolution, which lives in the Clarity Codex of the Claritorium and Value Creation of Equilio.

Uncertainty Variables

Progress Resolution is fundamentally about how much you know:

1. Unknowns: What you don’t know yet.
2. Assumptions: What you think you know.
3. Risks: What you fear could go wrong.

I call these Uncertainty Variables, the foundational elements you must manage to understand progress. You move from the problem space to the solution space to the build space, uncovering unknowns and increasing your fidelity of knowledge.

Each stage of progress is a conversion:

1. Unknowns → Knowns
2. Assumptions → Answers
3. Risks → Mitigations

Progress Resolution increases as uncertainty decreases.

The three pillars of Progress Resolution are:

1. Problem Definition: You know what you’re solving and why you’re solving it.
2. Solution Definition: You know how you’re going to solve it and deliver value.
3. Build Definition: You see the work in a tangible form in the real environment.

Each pillar defines progress in key stages as you increase certainty in the work. And each stage is inversely proportional to fidelity. As you decrease certainty, you increase fidelity.

1. Problem: Open / Focused / Defined
2. Solution: Conceptual / Structural / Interaction
3. Build: Uphill / Downhill / Finalizing

You diverge and converge continuously as you move through the funnel of uncertainty.

Problem Definition

You shouldn’t think about the solution before you define and understand the problem. You stay in the problem space until you have high certainty in:

• What the problem is.
• Why it’s important to solve.
• Why it’s important to solve right now.

This is the discovery space where you frame the problem through the right context. I like the term framing, but often communicate this externally as discovery. It’s more common nomenclature in the product space.

The three progress stages are:

1. Open Discovery (high uncertainty)
2. Focused Discovery (mid uncertainty)
3. Defined Discovery (low uncertainty)

Open Discovery

Stephen King believes in an idea he calls pantsing, where you create your characters, put them in situations, and let them define how they’re going to act. The story naturally unfolds with the surrounding context.

That’s exactly what Open Discovery is.

You are in exploration mode, collecting context from a wide range of sources. This is divergent. You don’t know the problems to focus on, so you’re just gathering inputs:

• Talking to stakeholders.
• Talking to the team.
• Talking to users.
• Reviewing usage and feedback data.
• Using the product yourself.

At this stage, you don’t know which problem you’re going to focus on. You’re open to whatever unfolds in the process.

Focused Discovery

Once the lines of the problem begin to emerge, you start to connect the dots. It’s like those bulletin boards with pictures, documents, and threads connecting them. You know, the ones that are in every show or movie where they’re investigating someone: “the board”.

This is Focused Discovery.

You collected the context, and it pointed you in a specific direction. Now, you can zero in and start defining the angles of the problem.

Defined Discovery

In Defined Discovery, you narrow the problem further, while expanding the context to increase your fidelity of knowledge. You know what problem you’re solving, but now it’s about finding the slice of the problem you should address right now. Knowing all the context of the problem creates contrast against other problems, making comparison easier.

Fight the urge to increase the scope. Keep subtracting until you define the core essence of the problem. Doing so not only increases your certainty, it makes it easier to validate assumptions and mitigate risks. Less surface area, less complexities.

Solution Definition

You know what problem you need to solve, but you don’t know how to solve it. The fun part of software development is the myriad ways you can solve any problem. But it’s also what makes it so challenging. Also, the fact that, despite designing a solution ahead of time, it doesn’t remove the unknowns from the work.

It’s all guesswork until you do the work.

I like the term shaping here, but I often use design for the optics. And when I use design as the terminology, I’m referring to it in its most fundamental sense—the Design Levels:

1. Surface: How should this look?
2. Structure: How should this flow?
3. System: How should this function?

Defining the solution should be highly collaborative. You’re missing a huge opportunity if you don’t bring designers, engineers, and strategists together to collaborate on the solution. You should even expand to other stakeholders, too. I talk to sales, marketing, and success teams early in the process. Product work shouldn’t be a black box. It’s like LLM models exposing the thinking steps, detailing the progression of thought. When you get good at translation, information becomes your most valuable asset. Think out loud and share your work to crowdsource divergent ideas.

The three progress stages are:

1. Conceptual Design (high uncertainty)
2. Structural Design (mid uncertainty)
3. Interaction Design (low uncertainty)

Conceptual Design

Each progress stage starts wide and gets more narrow. Conceptual Design is intentionally rough and high level. You don’t sweat the details just yet. You’re having conversations, exploring possibilities, and finding the language. Doing so surfaces patterns:

• You hear the same words.
• You see similar solutions.
• You see the shapes.

Patterns define the language of the solution. And, if you’ve learned anything about me, I am obsessed with language. The right words, collectively understood, separate seamless solutions from disjointed experiences.

This progress stage is about words and shapes, but nothing concrete emerges just yet.

Structural Design

Structural Design is when the shapes begin to get clearer and tighter. The language you defined takes form as sketches and structural diagrams. The lines of the solution emerge and move you closer to understand how the pieces connect into a unified whole.

Again, everyone should be involved here: designers, engineers, and strategists sketching, naming patterns, and considering the technical feasibility of the solution. Since you’re still at mid-fidelity and mid-uncertainty, the artifacts should stay at that level. It’s too early to let technical feasibility constrain the solution, but you should consider it. Start looking at the code and layering in technical context.

Interaction Design

Interaction Design is when you define how the parts of the solution fit together:

• The core flows that define how the user will move through the solution.
• The low-fi sketches connected into a unified flow of value creation.
• The language of the solution viewed as technical components in the codebase.

Through continued collaboration sessions, the work is shaped into a written artifact. The purpose is to shape the solution at the right level of fidelity. Too rigid with high-fidelity mockups and you box the engineers in; too loose with low-fidelity thinking and you miss key information to help during the build. The written document helps you:

• Frame the problem clearly.
• Set constraints on the build.
• Define the shaped solution.

You create an artifact you can shop around and solidify alignment with. The document serves as a representation of the work—a shared mental model with language, definitions, and the shapes. It includes all the language of the work, including words and visuals that express the purpose of the project.

Build Definition

You’ve now progressed to the build. This is where the engineers take the shaped doc and start building it. But you might think they know exactly what they need to do, so they can just execute. Right? Not exactly. Remember how building software is not a linear process of known quantities? And that, no matter how much you think you know ahead of time, the unknowns will still be there. All the work you did in the problem and solution space was in service of setting the appropriate intention for the work. It’s not a list of requirements.

In the military, there’s something called the Commander’s Intent. It’s a clear and concise statement of purpose for an operation and the desired end state. The core idea is that the commander explains “what we are trying to achieve and why,” not just “what to do.” While the commander considers everything that could go wrong in the operation, there are simply too many variables to account for. So they focus their energy on upstream context to equip the team who will execute the operation. They will be making decisions and changing the plan in real-time using the intention as their guide. If the team knows what success looks like, they can architect different paths to get there. The intent is the guide.

Military operations are a matter of life and death—building software is not. But the underlying principle of defining the work remains the same: give enough context to enable the team to make decisions when things happen differently than expected.

I call this phase development, but you can also call it building. Use the naming conventions best fit for your team and organization.

The three progress stages are:

1. Uphill Development (high uncertainty)
2. Downhill Development (mid uncertainty)
3. Finalizing Development (low uncertainty)

Uphill Development

The Hill Chart is a useful conceptual model for understanding development work. Even with all the high-fidelity thinking—the framing and shaping work—you still start the build at the bottom of the hill. Why a hill? Because, to get to the top of the hill, you have to answer unknowns to figure out how to build the solution; then you can execute as you move downhill against known work. Instead of tracking issue-completion counts, you think about the work in terms of figuring things out and making it happen.

Uphill Development is when you’re figuring out how to implement the solution:

• You’re looking at documentation, the code, and reviewing the shaped document.
• You’re spiking prototypes to test out solutions in the living codebase.
• You’re validating the individual scopes of work you broke the project into.

Engineers don’t think of writing tasks this way. They’re used to requirements and user stories, not writing their own tasks when the work begins. It’s perfectly normal to write a task that says Look into third-party API. You’re not writing any code, but you are trying to figure out how to, which is part of the uphill work.

To make progress in Uphill Development:

• Focus on the riskiest scope and answering the unknowns as quickly as possible.
• Validate the lines of the work—the scopes—to get a full picture of the surface area.
• Write every issue as you discover them, and use that to dictate the scopes.

Downhill Development

You’re at the top of the hill when you have a plan for implementation. You can define that in a lot of different ways, but the best way is with a working, unpolished prototype that proves out the implementation. This approach is what I call Reverse Refinement, and it pairs nicely with Infinite Iteration.

When you come down from the top of the hill, you’re in Downhill Development. You know how to execute the work, and you’re moving with higher certainty and confidence. You still encounter unknowns, but nothing that will derail the planned implementation.

This is where the Hill Chart as a conceptual model for progress is useful. I used to leverage it when using the Basecamp software because you could drag the dots (each scope) as you make progress. And they didn’t lock into place or represent percentages. It was just a gut feel of where the work stands in terms of the uphill (figuring it out) and the downhill (making it happen). When something was wrong, you knew it because tasks were being checked off, but the dot wasn’t moving. Typically, it was a sign that one scope should split into two or more separate scopes. Once split, you could reposition the scopes and instantly see where the work really was.

I don’t use the Hill Chart as a regular tool anymore, but the model is still useful. The most effective way to determine progress in this stage is to just talk about the work. Use natural language, ask questions, and describe where you think it is. Through the discussion, you can translate that back into the represented work to make sure it’s accurate.

Finalizing Development

There’s a spot when the work feels complete, but there’s a lot of detail work left. I call this The Last 10%, and I think it’s what separates a good feature from a great one.

The Last 10% is the Finalizing Development stage, and it’s when you:

• Update the small design details and interactions that level up the experience.
• Refine the code quality and write tests to make the solution more robust.
• Make sure all the analytics events are wired up and tracking key metrics.

You keep asking yourself, how could this be better? You get the feature fully ready to release and capture feedback from users. But you also need to be mindful of endlessly polishing without finishing. Compare to what exists today and, if what you have is better, ship it.

Integrating Stages

So how can you use these progress stages to increase the understanding of progress? The language is helpful context, but you can also track project status by stage and sub-stage:

1. Discovery / Framing
   1. Open
   2. Focused
   3. Defined
2. Design / Shaping
   1. Conceptual
   2. Structural
   3. Interaction
3. Development / Building
   1. Uphill
   2. Downhill
   3. Finalizing

Increasing the fidelity of knowledge while decreasing the uncertainty frames the work as a clear progression. Map your projects to these stages, and use shared language:

We’re in Focused Discovery, narrowing the problem down before defining it.

We’re in Conceptual Design, exploring rough sketches and ideas for what the solution could be.

We’re in Downhill Development, executing against known work and tracking progress in isolated scopes.

Project IO

When you zoom out and think about the mechanics of a project, it’s a simple input-output process:

• You define the problem, constraints, and solution as inputs to the project.
• You take the inputs and use them to track and execute on the work.
• You deliver the solution and measure success and impact of value as outputs.

Project IO is the expression of Progress Resolution in three components:

1. Intent: Creating an Intent Brief to outline the work and execute the project against.
2. Execution: Where you actually track and manage the work in the project space.
3. Impact: Creating an Impact Brief to report and measure the project’s success.

Intent → Intent Brief

Like the Commander’s Intent, the Intent Brief is where you outline the problem (the why), the constraints, the solution (the how), and other key elements to align the team on the work.

In Shape Up, they call this the pitch. I prefer this reframing around intent, and how it pairs with the output artifact. A pitch implies selling work; an intent implies setting a clear intention of goals, creating space for the team.

There are five key parts:

1. Problem: A clear definition of what problem you’re solving and why.
2. Constraints: A clear understanding of the constraints to limit the project to.
3. Solution: A clear definition of the solution, which includes words, sketches, and deep thinking about the technical feasibility.
4. Measurement: A clear definition of how you’ll measure success in terms of qualitative and quantitative data.
5. Release: How you’ll release the feature strategically and efficiently.

View the Intent Brief template →

Execution → Project Space

Once the work is handed off to the team to execute on it, you’re in the project space. This is where you organize and track the work to make sure there’s visibility. Linear is my tool-of-choice currently, but this structure maps to most project-management software:

1. Parameters: Defines the boundaries, accountability, and intention of the work.
2. Resources: The supporting information that informs execution. This includes research, technical docs, Figma files.
3. Scopes: The independent slices of work where you group tasks and plan milestone checkpoints for weekly iterations.
4. Progress: The real-time state of progress, expressed as Progress Resolution stages.
5. Updates: The weekly updates to demo working software and write context with a status of on track, off track, or at risk.

View the Project Space template →

Impact → Impact Brief

Something I never liked about the pitch document was how it became a stale artifact once the work changed and was delivered. There’s so much value in understanding how and why the scope was changed. And this is especially valuable when you’re working with sales and marketing teams. They expect certain functionality, so you need to close the loop and explain what changed and why. I also found that measuring success and following up was easy to lose track of.

While you could just update the pitch, it feels in conflict with the name. And, now that we have the Intent Brief, we can create a sibling artifact to define the impact like a report.

I call it the Impact Brief. It’s made up of:

1. Solution: A clear explanation of the solution as it was implemented.
2. Adjustments: A description of what changes were made as deviations from the original intention (the Intent Brief).
3. Result: Screenshots, demos, and a write-up of the solution. This is like the blog post announcing the feature.
4. Signals: Early signs of success, such as key metrics or customer feedback.
5. Next: Known updates and next steps to improve the feature. If you hammered any scope, that scope can show up here.

View the Impact Brief template →

Understanding Progress

Progress is hard to measure. In software, especially, it’s difficult to know where the work stands. But you can lean into the unknowns, assumptions, and risks, using them to move through the progression of uncertainty.

Use language to define the shape of progress. Think about the stages of work, and express progress with shared mental models your team understands. It’s often the open discussions that help most. When I want to know where the work is, I just ask the engineers to think out loud and describe the work. As they talk about it, the story develops. I ask questions and share my screen to make sure the story I’m hearing matches the project space:

Are we representing the current state of work?

Progress is about movement. But it’s also about direction. You need to stay in motion, but always in the right direction. Move from discovery to design to development, chipping away at uncertainty along the way. Use clear labels to define the status, and create inputs and outputs to protect the work. Create space to organize the work, and use Progress Resolution as the lens for forward motion.