Promoting your strongest designer into product operations can improve delivery while quietly weakening the product. Before changing the role, decide who will inherit the designer’s responsibility for noticing when the workflow still functions but no longer makes sense.
At 4:40 on a Tuesday afternoon in Accra, Esi was holding a printed sprint plan covered in blue pen. She had spent the morning moving between two engineers, the founder and a pilot customer whose document-processing team needed the next release before Friday.
Esi is an invented composite, but the decision is common in four-person AI teams. She was the design lead, and also the person everyone trusted to rescue work that had stalled between a customer request and an engineering ticket.
That Tuesday, the founder made the rescue permanent. Esi would move into product operations.
The promotion solved the visible problem
The logic was strong. Releases were slipping because nobody owned the space between a decision and its delivery.
The founder was selling and raising money. One engineer handled the model and data pipeline. The other owned the application. Esi already clarified requirements, checked progress and chased the final details before a pilot review.
Giving her formal ownership removed ambiguity. Within two weeks, the team had a cleaner release calendar. Engineers knew which issue came next. Customer requests stopped disappearing into chat threads. The founder could open one document and see what was blocked.
Then the team shipped a document review screen that completed every acceptance test.
It also confused the pilot customer.
The AI extracted the right fields. The confidence indicator displayed correctly. The approval button worked. But the screen placed the machine’s explanation below the action, after the reviewer had already been asked to accept or reject the result.
During the pilot call, the customer’s operations lead paused. She moved the cursor up and down the page, then asked which part she was supposed to trust.
Friday’s release was now in doubt. If the customer delayed the pilot, the team would lose the reference it needed for an upcoming partnership conversation.
Everyone had completed the work assigned to them.
Nobody had asked whether the sequence made sense.
Esi had been doing an unnamed job
Before the promotion, Esi would sit with a build and follow the decision as a customer would experience it.
What do I see first? What am I being asked to believe? What happens if the AI is uncertain? Can I recover after choosing the wrong action?
Those questions never appeared in her job description. They lived inside design reviews, short conversations with engineers and the quiet twenty minutes she spent clicking through a release before calling it ready.
Once Esi moved into product operations, her calendar changed. She prepared sprint notes, followed dependencies and kept pilot commitments visible. The team gained coordination and lost interpretation.
That trade can hide for several releases because delivery work produces visible evidence. Tickets close. Meetings happen. Dates move from tentative to confirmed.
Sense-making leaves evidence mainly when it fails.
I have seen the same pattern when a founder restores manual steps that software had removed. In Kojo’s distribution decision, the supposedly inefficient steps carried the trust required to turn interest into payment. Esi’s design work carried a similar kind of value. The screens were only the visible output. Her deeper contribution was catching the moment when the product’s internal logic diverged from the customer’s decision.
The team had to separate coordination from judgment
With the pilot review approaching, Esi reopened the build and asked the operations lead to repeat the decision aloud.
The customer needed to inspect the extracted field, understand why the AI had suggested it, then approve or correct it. The interface had reversed the middle and final steps.
The team changed the sequence before the next review. The explanation moved beside the extracted field. Approval came after inspection. Uncertain results created a clear correction path.
The pilot continued.
The more important fix happened inside the team. Esi kept product operations, but the founder stopped treating design review as something she could perform between status checks.
Every release now required one named person to test the decision path, separate from the person confirming delivery. That owner could be Esi, the founder or an engineer, depending on the feature. The responsibility could move. It could never remain implied.
This matters even more with AI products because a technically correct result can still ask a person to make an unreasonable leap. A demo may succeed using data production will never provide, as I explored in the gap between demo data and production reality. A workflow may also return the right answer while hiding the evidence a customer needs before acting on it.
Both failures survive ordinary delivery checks.
Audit the work before changing the title
When one person seems capable of fixing every gap, promotion feels like recognition and relief. Pause before moving them.
For one week, write down the questions that reach this person. Mark which ones involve scheduling, ownership or follow-up. Then mark the ones that involve interpretation: deciding what the customer means, spotting a broken assumption or noticing that a usable feature still feels wrong.
Move the coordination work if that is where the bottleneck sits. Assign the interpretation work explicitly before the new role begins.
On the Tuesday after the pilot review, Esi still had the sprint plan in front of her. This time, one line appeared beside the release date: “Decision path review: founder.”
It was a small addition. It meant the team no longer depended on Esi noticing, from the corner of her new job, that the product had stopped making sense.
Comments
No comments yet.