“I'm not here to tell you what to build.
I'm here to ask better questions about why.”
Product and systems thinker. Background in information systems. Writing at the intersection of problem definition, AI, and how teams understand the space they're working in.
“Irving Space is not a personal brand play. It's not a portfolio. It's a place to navigate through ideas, because exploring is how I figure out what I actually believe.” — John Irving
I came up through information systems, which taught me something most product education skips: the tool you reach for picks the problem before you do. By the time you've named the problem, built a framework, and assigned a sprint, you've already made dozens of assumptions. Most of them invisible. Some of them wrong.
For most of my career I was inside startups. Watching smart people move fast. Usually in the right general direction. But almost always past the point where a harder question would have changed what they were building, saving them six months.
IrvingSpace is not a personal brand. It's not a portfolio. It's a place to work through ideas because writing things down is how I layout what I actually believe. The three ideas below are the lenses I keep returning to. They're not a framework. They're more like a standing question I carry into most situations.
If something here makes you slow down and reconsider something you thought was settled, that's the whole point.
The problem space
There's a point in every project where the team shifts from asking "what's actually happening here?" to "how do we fix it?" That shift is almost always premature. And it's almost never noticed.
The problem space is everything that happens before solution. It's the diagnostic work: the uncomfortable period where you resist the urge to act and instead keep asking what you're actually dealing with. Most teams spend about ten minutes here before reaching for their preferred tool.
Knowing where you are on the problem-to-solution spectrum changes everything. It changes what questions are useful, what role you're playing, and what "done" means. The teams I've watched struggle most are usually ones who believed they were in the solution space when they were still very much in the problem space, and had no shared language to name that.
Systems thinking
Every black box is a set of choices someone made a long time ago, for conditions that no longer apply. The feature that doesn't make sense, the process nobody can explain, the constraint that "just has to be" this way: these are decisions made by people who aren't in the room anymore, solving problems that may have already changed shape.
Systems thinking is the practice of seeing structure under behavior. Not "what is this doing?" but "why is this built to do that?" And more importantly, "what feedback loop keeps it doing that even when we'd rather it didn't?" Most organizations have more of these invisible loops than they realize. Incentives create behaviors. Behaviors reinforce structures. Structures outlast the rationale that created them.
When you understand how something actually works, you stop accepting it as a given. That's not the same as wanting to change everything. It's just no longer being surprised when the same problem keeps reappearing in a new hat.
Tracking results
Most teams define success after the thing is already built, and the definition lands on whatever the thing happens to be doing. That's not measurement. That's retroactive justification.
Success metrics are a thinking tool, not a reporting exercise. Reached for early enough, they force a specific kind of clarity: what behavior change, in whom, over what timeframe, will tell us this worked? That question is hard. It's supposed to be hard. The difficulty is the point: it surfaces misalignments, unstated assumptions, and scope creep before anything is built.
Very few teams can finish the sentence: "we'll know this worked when…" Not because they're careless, but because finishing it requires making a call on what actually matters, and making that call early, before the work tells you what to say. The teams that do it anyway build differently. They argue differently. They stop building differently, too.