Early in my career, writing specifications was a large part of my job.
I started as a Senior Systems Analyst at Nia, working on enterprise systems and portals. A specification had an important dual purpose: it needed to make sense to the client approving what we were building and to the engineers who would eventually build it.
As the systems analyst, I was generally the one leading that work.
I would spend time understanding the customer’s processes, turning them into functional behavior, working through business rules, integrations and technical constraints, and then pulling those decisions together into a specification that could serve both audiences.
At that point, who owned the specification wasn’t a particularly interesting question.
Mostly, I did.
What made it interesting came later.
When two disciplines met
Nia merged with Adwise, a company with a much stronger UX orientation.
As the combined company grew, so did the disciplines around the work. Systems Analysis became a more established practice, while UX brought deeper expertise around interaction, information architecture and how people would actually experience the systems we were defining.
I eventually headed the Systems Analysis group, which meant working closely with the head of UX.
Now we had two established disciplines looking at the same product—and often the same specification—from different directions.
Systems Analysis was concerned with what the system needed to do and everything underneath that behavior. UX was concerned with how people would understand and interact with it.
Most of the time those perspectives complemented one another.
Sometimes they overlapped.
And that raised a new question: who should lead which parts of the specification?
The answer depended on the project
There wasn’t one allocation that made sense everywhere.
Netwise’s methodology eventually documented several models. Some projects were primarily led by Systems Analysis. Some leaned much more heavily on UX. Others were closer to an even split.
The choice depended on the work in front of us.
What did the customer want to achieve? What system were we starting from? Was the difficult part mostly about interaction and information architecture, or were we dealing with complex processes, rules and integrations?
The split wasn’t something to negotiate only after a problem appeared. It was one of the things that needed to be established when setting up the project.
And once it was clear, it usually required surprisingly little intervention.
The Systems Analyst knew where to lead. UX knew where to lead. Both reviewed the places where their perspectives touched.
There were still occasions when an interaction decision affected system behavior, or a functional constraint changed what made sense in the interface. Those overlaps sometimes needed discussion.
But there was an accountable owner for resolving them: the project manager.
That structure is what I remember—not a recurring ownership crisis, but the value of making the ownership model explicit before the work gets complicated.
When I became responsible for the split
My own role was changing at roughly the same time.
I had started inside the work as a Systems Analyst, usually leading the specification myself.
As I moved into project management, my responsibility broadened. I had to establish how the work should be divided, make sure the different parts came back together coherently, and decide when legitimate perspectives pulled in different directions.
Later, heading Systems Analysis added another perspective: I was responsible for developing one discipline while still making sure it worked effectively alongside another.
That progression changed how I thought about ownership.
A specification can have many contributors, but the product decision it represents needs one accountable owner.
Accountability wasn’t about centralizing every decision. In practice, clear ownership often did the opposite: once people knew where they were expected to lead and where responsibility changed hands, they could work with more independence.
The teams are broader now
The teams I work with today look very different.
A modern product decision may involve product, design, engineering, architecture, data, operations, compliance, risk, commercial teams and domain specialists.
Their expertise should remain distributed. Product leadership should not absorb all of those jobs.
But the same kinds of seams still appear.
A better experience may conflict with a technical constraint. A customer need may collide with an operational reality. Two legitimate perspectives may point toward different decisions.
Someone still has to remain accountable for the product decision that connects them.
That is the continuity I see between then and now.
Then: specialist disciplines, with a project manager accountable for integrating them.
Now: product leadership plays a related integration and accountability role across a broader set of disciplines.
The teams changed. The number of contributors grew.
The principle stayed with me.
The split can vary.
The accountable owner cannot.