The problem as your North Star

In technology enterprises it’s easy to lose sight of the problems you are trying to solve. We often get lost in concrete detail, very notably so in small decisions of everyday life. Should this button be this or that color? Should this data be stored as state or dynamically computed? In aggregate, these small decisions affect larger outcomes, but the quality of these outcomes ebbs and flows, and they can be fixed as long as other systems and frameworks - related to strategy, design, development, or general thinking - are solid.

But it is precisely when these higher-level systems and frameworks become detached from the problems we are trying to solve that projects derail. Whether you are creating a strategy deck, drawing the high-level architecture for a solution, crafting a design system or choosing a tech stack, executing while disconnected from the problem you are trying to solve can lead to derailment.

This may seem obvious in theory. And yet, in practice, as a deluge of information inputs and potential implementation details get in the way, it is ridiculously easy to lose sight of the fundamental problems you are trying to solve. Your boss, your client or your ego don’t want to hear about it - they want a solution, and they wanted it for yesterday. “Of course we understand the problem at hand”. But do we? Ask “what are we trying to solve” in the middle of an implementation quagmire, and you’ll often find a muddled train of thought. And as French playwright Nicolas Boileau put it: “Ce que l’on conçoit bien s’énonce clairement” (That which is well-conceived is clearly expressed). It follows, then, that that which is not clearly expressed, is not well-conceived…

“Problem-solving” presumes defining the problem concisely, transparently, and on an ongoing basis, as long as it has not been solved. To this end, much like Agile prescribes keeping a product backlog for as long as the product exists, I keep little problem backlogs as long as the problems exist. When I get mired in detail or feel outright lost, I revisit them, groom them, and question whether they are being rightly addressed. And if I feel they are lacking or have become outdated, then it’s time to go back to the drawing board, talk to the right people, and self-reflect until the problems are again well-conceived and can be expressed clearly. The problem list is indeed my north star.

To end with the inevitable note about AI and LLMs: like many others, I find they are outstanding at finding solutions, the more concrete the better (code, text, images, etc). Defining problems nevertheless is such an abstract art, one that needs so much context - including, very often, deep human interaction - that I doubt it will be fundamentally transformed in the shorter term. At least not directly; perhaps we will all use some of the free time unlocked by AI to think more deeply about the problems we are trying to solve, and perhaps this will be one of the factors that will unlock new milestones in innovation and productivity.