A product designer asking to move into operations can signal a clearer view of where they create value, rather than disengagement. The right decision comes from examining the work they already choose, the product judgment the team would lose, and whether an operations role solves a recurring company constraint.
At 4:17 on a Thursday afternoon in Accra, Adwoa closed the prototype on her laptop and asked for ten minutes. She was our only product designer, an invented composite for this story, and she had spent that morning fixing an onboarding flow before a customer demonstration.
“I want to move into operations,” she said.
The request landed badly. We were days from handing a revised build to a pilot customer. Two onboarding screens still needed decisions, the engineer was waiting for error states, and nobody else owned the design system. If Adwoa left design immediately, we could miss the handover or ship a flow we had already watched people misunderstand.
For a few seconds, I heard resignation inside a role-change request.
The work behind the request
My first question was too blunt: “Do you still want to be here?”
Adwoa looked surprised. Then she opened a document she had prepared.
It showed the work she had done over the previous month. The design tasks were there, but half the document covered problems outside the design file: customer questions that had never reached engineering, pilot commitments recorded in three places, onboarding details discovered after builds had started, and meeting decisions with no named owner.
She had been quietly closing those gaps.
When a pilot customer changed the order of its approval process, Adwoa caught the effect before we built the wrong screen. When engineering needed a decision on account permissions, she found the original customer note and brought the right people into one call. Her operations work had reduced product rework, although nobody had named it as operations.
That changed the question. I stopped asking whether she was escaping design and started asking what work had earned her attention.
People often describe their desired role before they can fully explain the pattern behind it. The title may be imprecise. The repeated behaviour usually tells you more.
Three risks hidden inside one decision
Approving the move immediately would have rewarded initiative, but it could also have left a product gap we could not cover. Refusing it would have protected the next release while telling Adwoa that the work she found most useful did not count.
There was a third risk. We could create a vague hybrid role where she remained responsible for every design deadline while absorbing every operational problem. Small teams do this easily. A capable person identifies a neglected function, so the company adds that function to their workload without removing anything.
That arrangement tends to fail quietly. Product work slips. Operational work becomes reactive. The employee carries two jobs and receives feedback for whichever one suffered that week.
I had seen a related problem when a team promoted its strongest designer but failed to protect the judgment that made her valuable. The decision in Esi’s design lead promotion came down to the same constraint: a new role can create value while exposing a capability the company still needs.
By 5:00, Adwoa still did not know whether her request would be approved. Neither did I. The engineer needed those error states before the next morning, and the quickest answer would have been to postpone the conversation until after the pilot.
That would have been a decision too. It would have told her that urgent product work always outranked the role question, even when the role question explained why the urgent work kept appearing.
A transition with an expiry date
We agreed on a four-week trial.
Adwoa would spend most of her time owning three operational problems she had already identified: keeping customer commitments in one place, assigning owners after product meetings, and checking that implementation decisions matched what the customer had actually requested. She would retain one defined design responsibility, the onboarding flow for the current pilot.
We also named what she would stop doing. She would no longer take every internal design request, tidy unfinished screens after meetings, or become the default note-taker because she understood the product.
The trial had measures we could observe without inventing a performance score. Were fewer decisions being reopened? Could engineering find the current customer requirement without asking three people? Did the onboarding work receive enough design attention? Could another person handle routine design changes with Adwoa reviewing only the decisions that carried product risk?
Most importantly, we set a date to choose. A transition without an expiry date becomes a permanent exception.
This was similar to the reasoning behind pausing an engineering offer when customers wanted three different products. Headcount and job titles can make ambiguity look solved. The underlying constraint remains until someone decides which work the company will protect.
What the empty design chair revealed
Four weeks later, Adwoa’s operations work had made ownership clearer, but the design gap was real. Routine screen work moved more slowly. Engineers made small interface decisions themselves, sometimes well and sometimes without enough context.
The trial produced a less comfortable answer than a clean promotion story. Adwoa created more value in operations, and the company still needed product design. Her request had exposed two facts at once.
So we confirmed the move and reduced the design surface we expected the team to maintain. New feature work required an explicit product decision before entering development. Adwoa reviewed high-risk flows during a scheduled session instead of remaining permanently available. The next hire profile changed too: we needed a designer who could work within an existing system, rather than someone expected to repair the company’s operating habits.
On the following Thursday at 4:17, Adwoa was no longer polishing screens after everyone else had left the meeting. She was assigning the unresolved pilot decision to its owner, while the onboarding flow stayed deliberately unchanged until the team answered the customer question underneath it.
Comments
No comments yet.