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.
We now had two professional 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.
Once both groups were established, we started seeing occasional friction on projects where the same part of a specification sat naturally in both disciplines. Stronger specialists brought clearer professional judgment, which made unresolved ownership boundaries more visible.
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 make sure different parts of the work came back together coherently and decide how ownership should work when legitimate perspectives overlapped.
Then I established and began leading the Systems Analysis function.
The initial team of six came together in two different ways. Three were veteran employees moving internally from development and customer relationship management roles, while three others joined with established analysis experience.
The internal transitions required much more than assigning people to projects. I coached them through learning the discipline: how to structure a problem, ask the right questions, turn ambiguity into something a project could act on, and gradually become trusted advisors to project managers and customers.
The experienced hires brought more of that craft with them, but the group still needed a common way of working. I created templates, checklists and a shared analysis process that moved from understanding the current state and business goal through process and system mapping, solution alternatives and technical alignment, then internal and customer review. The aim was to make strong analysis repeatable rather than dependent on which analyst happened to be assigned.
Leading the function made my own output a smaller part of the job. The team had to produce strong analysis consistently, and people needed enough judgment and structure to keep moving without routing every difficult question through me.
The ownership questions we were seeing with UX therefore mattered directly to the team I was building. Analysts needed to know where they were expected to lead, where another discipline led, what they could resolve themselves, and when an overlap genuinely needed to come back to the project owner.
Clear boundaries made delegation possible. They gave analysts enough room to make progress without waiting for me to sit in the middle of every conversation.
The answer depended on the project
There wasn’t one allocation that made sense everywhere.
We eventually documented several models in Netwise’s methodology. 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?
We learned to establish the split when setting up the project rather than wait for friction to expose an unclear boundary.
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, and the project manager remained accountable for resolving them.
That structure gave specialists room to work independently without leaving the overall decision ownerless.
That progression changed how I thought about ownership.
A specification can have many contributors, but the product decision it represents needs one accountable owner.
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.