Building a Product Without Seeing the Whole System

A few weeks ago, I started building Outcomet. Not as a side project, but as a system I actually wanted to use myself.

The idea was not new. After years in product management, I kept running into the same gap. There is no tooling that truly connects the dots. I used many tools over the years, and some of them are still part of my setup today. But none of them helped me see the big picture. They manage parts of the work, but they do not connect it.

So I started building.

Yes, I started with what people now call vibe coding. Not to build fast for the sake of it, but to explore if the idea is feasible and to test early if it is desirable. Even viability. Although, to be honest, that is rarely the real problem.

In the first weeks, I did not think much about structure. I just built. I set up the core apps, connected the stack, and started coding with AI.

At some point, I had a product app, a website, an admin layer, and multiple AI agents writing and reviewing code. Around 1600 commits and 180 pull requests. Most of it generated or supported by AI.

Everything was moving fast. But something felt off.

The problem you only see when things move fast

The faster I built, the harder it became to answer a simple question: why am I building this?

Not in theory, but in context.

The answer was always somewhere. In feedback I had written down, in experiments I ran, in assumptions I made earlier, or in decisions I took days ago. But never in one place.

Speed exposed the real problem: I could not see how everything connects.

This is not new. It is how most product work operates.

The fragmented product management process

Modern product work is spread across layers. Product strategy sets direction, product discovery explores opportunities, delivery builds capabilities, and product feedback closes the loop.

Each part is well understood, and each part has tools. But they rarely exist in one system.

Instead, we distribute thinking across documents, boards, tools, and meetings. Over time, this creates a subtle but critical issue.

You can see the parts. But you cannot see the system.

You see a product backlog. You see discovery work. You see feedback and metrics. But you cannot move through them as one connected flow.

How product work actually happens

In reality, product work is not a pipeline. It behaves like a loop. A continuous system of learning.

Signals such as feedback, data, and observations lead to understanding in the form of patterns, themes, and insights. These inform decisions about priorities and direction, which then result in execution through capabilities and features. And this immediately generates new signals.

This loop does not run in phases. It runs in parallel. A new signal can change a decision. A decision can invalidate a backlog. A release can generate new signals.

Product work is a learning system, not a delivery pipeline.

But most setups are not designed for that.

What gets lost

When the loop is broken across tools, three things start to degrade.

First, context. A backlog item exists, but its origin is unclear. Was it driven by strategy, feedback, or assumption?

Second, traceability. An insight exists, but it is not clearly connected to a decision. A decision exists, but the reasoning behind it is scattered.

Third, learning. Teams collect signals all the time, but rarely turn them into structured understanding.

Over time, output increases, but understanding does not.

And without understanding, progress becomes accidental.

A different model: connect the loop

The shift is simple, but structural.

Instead of managing artifacts, connect the loop. Instead of tracking tasks, track learning. Instead of organizing work in layers, link it into a system.

In a connected model, signals become structured inputs. These inputs form themes and insights, which connect to opportunities. Opportunities turn into decisions, and decisions become what you build.

The value is not in each element. It is in how you can move through them.

From a signal to what gets built, without losing context.

Building the loop first

This is where I changed how I build.

I did not start with features. I started with the loop.

Give feedback, let AI process it, analyze it, and feed it back again.

This created a working learning system from day one. AI made this executable. Feedback could be structured, signals could be analyzed, and insights could be synthesized. The loop could run continuously while I was building.

What AI actually changes

AI does not just speed up coding. It changes the rate of iteration.

You can generate drafts quickly, test ideas faster, and refine structures continuously. What used to take months now happens in weeks. Not because everything is perfect, but because you can run more iterations in less time.

More iterations means faster learning.

But there is a trade off.

Speed without structure creates noise.

The faster you move, the more you need a system that keeps everything connected.

The real bottleneck shifts

One thing becomes very clear.

Building is no longer the bottleneck. Learning is.

AI reduces the cost of producing output, but it increases the need for coherence. Features get cheaper. Coherence does not.

Where this leads

We are moving toward a different kind of product operating system. One that continuously ingests product feedback, structures signals into insights, connects discovery to product strategy, and links decisions to execution.

The role of product management changes with it. It becomes less about maintaining a product backlog and more about shaping a system of learning. Less about tracking work and more about understanding the system.