The More I Understood, the More Questions I Had

Recently, I had the opportunity to present an early-stage software project to a client.

The project's goal sounded straightforward: streamline several parts of an operational process that had traditionally been handled separately. Different departments owned different responsibilities. Each had its own procedures, terminology, priorities, and, in some cases, its own system.

Individually, those systems worked. Together, however, they did not always behave like parts of a single journey.

My task was to help turn them into one cohesive product.

When I first took on the project, it felt daunting. I was not an expert in the client's industry, and I did not yet understand how the work moved from one department to another. I did not know which decisions happened first, what information needed to follow them, or why certain steps had evolved the way they had.

More importantly, I did not yet know what I did not know.

“All I really had was a problem—and the ability to keep asking questions.”

Starting with the simplest possible version

My first instinct was to reduce the process to its simplest form.

What begins the work? Who needs to act? What information do they need? What does “finished” actually mean?

At first, I assumed that simplifying the process would make it easier to understand. Instead, every answer exposed another layer.

A request could not simply be created; it needed the right context. Assigning someone was not just choosing a name; availability, suitability, responsibilities, and approval all mattered. Completing the work was not merely changing a status; it involved collecting evidence, preparing documentation, reviewing the result, responding to feedback, and obtaining the right sign-offs.

Each department understood its own part of this process extremely well. The difficulty was that no single person or system necessarily represented the entire journey.

I was being introduced to the process through fragments: ideas from meetings, existing practices, individual screens, documents, business rules, exceptions, and different interpretations of what the product should do.

For a while, I struggled to answer a deceptively simple question:

“What is the point of it all?”

When every answer creates another question

I began asking one question after another.

• Who is responsible at this stage?
• What decision are they trying to make?
• What must happen before they can make it?
• Who needs to know afterward?
• What happens if the expected action does not occur?
• How do we know that this stage is genuinely complete?

The ironic part was that the more I learned, the less I felt I understood.

That feeling can be uncomfortable, especially when you are expected to lead. It is tempting to interpret uncertainty as a sign that you are falling behind. But I gradually realized that the growing number of questions was evidence of progress.

“My original understanding had been simple because it was incomplete.”

As I learned more, I began seeing the dependencies hidden underneath the visible steps. I could see why a field that appeared unnecessary to one person mattered to somebody later. I could see why two actions that looked similar represented different business decisions. I could also see how a small change in one part of the workflow could create confusion somewhere else.

The complexity had always been there. I was finally becoming aware of it.

Finding the common thread

Eventually, a common thread began to emerge.

The separate processes were not really separate. They were different stages in the life of the same piece of work.

• Someone initiates it.
• Another person defines what is needed.
• The right people are identified and invited.
• Responsibilities are confirmed.
• Work is performed.
• Evidence is captured.
• Results are reviewed.
• Feedback is resolved.
• Administrative requirements are completed.
• Only then can the work be meaningfully closed.

Once I understood that lifecycle, the project started to make sense.

The challenge was no longer to reproduce several existing systems inside one application. It was to understand how information, responsibility, and decisions should move through the entire process.

That distinction changed how I approached the product.

Instead of treating every request as another feature to add, I started asking where it belonged in the larger journey. Did it help somebody make a necessary decision? Did it remove a handoff? Did it preserve information needed later? Did it help the next person understand what had already happened?

If it did not support the core journey, it probably did not belong in the first version.

Turning many ideas into an MVP

There was no shortage of ideas.

That is normal in an early-stage project. Once people see the possibilities, they begin imagining everything the product could eventually become. Many of those ideas were useful, but attempting to build all of them at once would have made the product harder to understand and much harder to validate.

Creating the MVP therefore became an exercise in filtering.

We needed enough of the workflow to demonstrate a complete and credible journey—not every possible variation of it.

This meant prioritizing the moments where responsibility changes hands. It meant making roles clear, carrying the right information from one stage to the next, and defining what progress and completion actually look like.

It also meant revisiting earlier decisions.

Parts of the project were renamed, reorganized, expanded, restricted, or removed as our understanding improved. Relationships that originally seemed simple became more precise. Separate screens became connected experiences. Actions gained review stages. Drafts, revisions, supporting evidence, notifications, and role-specific views appeared where the real process required them.

These changes were not signs that the original work had failed. They were the visible record of the team learning the problem.

“The codebase did more than grow. It gradually moved closer to the client’s actual way of working.”

Stepping up to lead

My role also changed during this process.

At the beginning, I felt like someone trying to translate a complicated set of requirements into software. Over time, I became more comfortable guiding the conversation itself.

Leadership did not mean pretending to have every answer. It meant creating enough clarity for the team to move forward.

It meant listening to different perspectives without allowing every new idea to pull the product in a different direction. It meant recognizing contradictions, identifying missing decisions, and bringing discussions back to the shared lifecycle.

Most of all, it meant being willing to say:

• This is what I believe the process is.
• This is the goal each stage needs to accomplish.
• This is what we should include in the MVP.
• And these are the assumptions we still need to validate.

That shift—from receiving information to organizing it—was one of the most important parts of the experience.

Presenting the product

By the time I presented the early-stage product to the client, I was not simply demonstrating a collection of screens.

I was presenting our current understanding of their operation.

The product showed how work could begin, move between the people responsible for it, collect the information produced along the way, pass through the necessary reviews, and reach a meaningful conclusion.

It was still an MVP. It did not attempt to solve every edge case or replace years of operational knowledge in one release. But it gave the client something concrete to react to: a shared model of the process and a foundation we could continue refining together.

That is one of the most valuable things an early product can provide.

“Sometimes, stepping up to lead a project does not begin with knowing exactly where to go. Sometimes it begins with being willing to follow the thread.”

What I learned

The hardest part of building business software is rarely the individual screens. It is discovering the invisible thread that connects the people, decisions, documents, and responsibilities behind them. That thread does not appear from one perfect question. It appears through imperfect questions, partial answers, revisions, and moments when an earlier understanding proves incomplete.

How it changed my thinking

I no longer treat uncertainty as a private failure when I am expected to lead. I treat a growing number of questions as progress, use them to organize the shared lifecycle, and keep the first version focused on the journey that actually needs to be proven.