A product-operations salary is worth leaving UI/UX design only when the role expands your influence without quietly ending the craft that made you valuable. Before accepting, test the offer against the work you want to be known for, the decisions you will own, and the path back to hands-on design.
Imagine Amara, a Lagos UI/UX designer who keeps a paper notebook beside her laptop because rough boxes still help her think. At 4:47 on Friday afternoon, an offer appeared in her inbox: product operations, better pay, Monday deadline.
By Saturday morning, the salary had already started spending itself in her head. More room in the monthly budget. Less anxiety when a client delayed payment. Enough stability to stop accepting small freelance revisions after work.
Then she read the responsibilities again.
The salary answered one problem and created another
Amara had earned the offer by doing more than drawing screens. During a difficult product launch, she had clarified requirements, chased decisions, documented edge cases and kept engineering from building against an outdated flow. The company saw someone who could bring order to confused product work.
Recruiters had noticed her for a different reason. Her portfolio showed judgment in the interface: what to remove, where a user might hesitate, and how a rough workflow could become understandable.
The operations role rewarded the work surrounding her craft. It offered no clear promise that she would continue practising the craft itself.
That distinction mattered because Monday’s decision carried a specific bad ending. If Amara accepted and spent the next year coordinating meetings, updating delivery plans and resolving handoff gaps, her salary would improve while her design portfolio stopped moving. She could become more useful inside one company and less legible to the market that had been calling her.
Declining carried its own risk. The next design offer might take months. Her current contract could end before then. There was no safe column in the spreadsheet.
A title cannot tell you where the work leads
The useful question was not, “Do I want to move into product operations?” It was, “What will I be able to point to after twelve months?”
Amara opened a blank page and wrote two possible Monday mornings.
In the first, she accepted the role and owned the system around product decisions. She would identify where customer feedback disappeared, make responsibilities visible and reduce the number of features that reached engineering without enough context. She would stay close enough to design to review flows and test assumptions.
In the second, “product operations” meant taking notes, arranging ceremonies and reminding other people to finish work she did not control.
Both versions could sit beneath the same title.
This is the same trap I see when founders evaluate an integration contract or a senior hire. The offer describes the immediate reward clearly. The cost arrives through the work it displaces. In The Spreadsheet That Revealed Who Really Owns Your Roadmap, ownership became visible only after competing commitments were placed together. Amara needed the same view of her career.
She listed the evidence she would need before saying yes:
- Which product decisions would she own rather than coordinate?
- How much of her week would involve customer problems, flows or prototypes?
- What would strong performance look like after six months?
- Could she keep one live design problem in her scope?
- Who had authority when operations, design and delivery priorities conflicted?
These questions turned a flattering offer into a job she could inspect.
The counteroffer was about scope
By Sunday evening, Amara had reached the part most candidates avoid. She had to ask for something beyond money.
She drafted a short response accepting the direction of the role while requesting clearer ownership. She wanted responsibility for the intake process behind product requests, a defined role in early problem framing, and one product area where she could continue hands-on design work.
There was still no guarantee. The company could decide that the role required a full departure from design. They could withdraw the offer or refuse to change the scope. That possibility sat on the screen while she rewrote the message twice.
The turn came when she stopped treating the offer as a verdict on her identity. She did not have to decide, over one weekend, whether she was now a designer or an operations person. She had to decide whether this particular job would build the next body of evidence she wanted.
That framing also exposed a warning. People who patch broken processes often get promoted into permanent responsibility for those processes. What Happens When Promoting the Person Who Patches the Broken Process? explores why competence can become a trap when authority does not follow responsibility.
Protect the work that keeps your options open
On Monday morning, Amara sent the response before opening her design software. The outcome remained outside her control, but the decision no longer depended on the salary alone.
For a designer considering product operations, the strongest version of the move creates wider decision authority while preserving contact with users, product judgment and shipped work. The weakest version converts visible craft into invisible coordination, then asks you to trust that the title will compensate later.
A higher salary can justify changing direction. Financial stability matters, especially when runway is personal rather than corporate. But the salary should pay for a deliberate trade, not hide one.
Before your next offer deadline, write down the three artefacts, decisions or outcomes you want to show a future employer. Then ask which of them the role will let you produce.
On Monday, Amara still had the same notebook beside her laptop. This time, the page held more than boxes and arrows. It held the conditions under which she was willing to put the pencil down.
Comments
No comments yet.