By Design — Before You Fix It, Understand It

Hi Reader,

At some point in my career, I was assigned to a project that was generally considered to be in shambles.

A handful of leaders knew the project team's purpose and where they wanted the workstream to go, but the problem was that the knowledge lived entirely in their heads. No documentation, no shared knowledge base, no common team picture of where the project actually was.

So, they did what made sense to them in the moment: feeding the work to the team piece by piece as it occurred to them.

The result was painful for everyone.

Leaders spent entire work sprints hand-holding, clarifying, and re-clarifying, watching the rework pile up because context was missing from the start. Their time, the most finite resource on the project, was being consumed by problems that should never have existed.

The team's POV was much worse. They didn't know why they were working on what they were working on. They couldn't see how their piece fit into the bigger picture. Whenever they hit bottlenecks, they spent more time waiting for a leader to surface and clarify something than doing the actual work. And perhaps most damaging of all, there was no sense of ownership. How do you own work you don't fully understand?

The leaders had a diagnosis ready: they needed a Scrum Master. Someone to help them manage their time better.

They weren't wrong that time was a problem, but they were reaching for a solution before they'd done something more fundamental.

A few weeks ago, I wrote about the Five Whys: the practice of asking why, repeatedly, until the real issue surfaces beneath the obvious one. It's a powerful diagnostic tool. But there's a step that precedes even that.

You can't diagnose what you haven't first documented.

Before you can find the root problem, you need to understand what you're actually working with. The leaders on that project couldn't have run a meaningful Five Whys because they didn't really have a good grasp of the state of affairs. What actually existed? What was working? What was broken? What the team was actually carrying before anyone decided what to do next.

A Scrum Master couldn't fix that. That's like hiring a traffic controller before you've built the roads.

This is something I see repeatedly in projects and organizations, and, if I'm honest, even in my own life.

I identify that something isn't working, I feel the friction, and then reach for a solution. Maybe some new productivity system, a better morning routine, more sleep, more water, or sometimes complete avoidance. I'll deal with it later. Can you relate?

Many skip the step that actually makes any of those solutions useful: understanding the current state of what we're working with.

In product thinking, before we recommend any solution, we conduct a current-state assessment. Not just problem identification but a full picture of what exists, what's functioning, what's load-bearing, and what's quietly failing.

The reason this matters is often misunderstood.

A current state assessment isn't just about finding what's broken; it's equally about understanding what's working — because the strengths of your current design are assets you can leverage in the redesign. Tear them down without understanding, and you might lose a crucial part of your system.

It's the difference between a renovation and a demolition.

Over the past few weeks, I've introduced two archetypes: the Cathedral Builder and the Maintenance Architect (I'll introduce more over the next few weeks). People recognized themselves immediately, which told me something important: the friction is real, and it's widespread.

But here's what I want to add to that conversation this week.

Knowing your archetype is the beginning of the current state assessment, not the end. It tells you something about how you're wired — your natural mode, your default cycle, where friction tends to show up. That's valuable.

What it doesn't tell you is the full picture of what you're currently running. It doesn't tell you what you've accumulated or what you're maintaining, by choice or by default. It also doesn't tell you what's working or what's been draining resources like time, energy, and mental capacity. That full picture is what makes the redesign effective.

Without it, you're doing what those leaders did — introducing solutions piece by piece, mid-sprint, hoping something sticks.

So, my product thinking hack for you today is this: before you reach for a new system, a new habit, or a new version of yourself, pause.

Do you actually know what you're working with right now? Not what you wish existed. Not what you think should be there. What's actually there.

That audit, honest and necessary, is where real renovation begins.

Not with a better tool. Not with more discipline. Just more clarity about where you actually are.

---

What's one thing in your current design that you've never stopped to properly assess — that might be either a hidden asset or a quiet drain?

Intentionally,

Dami