A product designer can own sprint planning, customer feedback and release coordination, but the work will fail if the team does not give her authority over priorities, decisions and follow-through. A new title helps only when everyone knows what she can decide, what still belongs to the founder and what happens when someone ignores the plan.
Consider Abena, an invented composite of designers I have worked alongside. At 10:17 on a Tuesday morning in Accra, she left stand-up holding her sketchbook and three new responsibilities. The founder had asked her to plan the next sprint, organise feedback from two pilot customers and coordinate Friday’s release.
Then the lead engineer added one sentence: “I may need to move the release if the integration takes longer.”
Nobody answered him. The founder had already joined another call.
Abena now owned Friday without having the power to protect Friday. If engineering changed scope, sales promised another request or the founder inserted an urgent fix, she could update the board and send reminders. She could not make the trade-off that kept the release intact.
Responsibility arrived before authority
Early-stage teams create roles this way all the time. Work gathers around the person who can see the gaps.
A designer notices that customer feedback has no owner because every new request changes the interface. She starts grouping the feedback. That exposes contradictions in the roadmap, so she begins preparing sprint options. Once she knows what should ship, release coordination follows.
The progression makes sense. The mistake comes when the team treats visibility as authority.
Abena could see that one pilot customer needed a simpler onboarding flow while another wanted a reporting feature. She could explain why adding both would push the release beyond Friday. But could she reject one request? Could she remove a founder’s idea from the sprint? Could she ask the lead engineer to stop an unplanned task already under way?
If the answer was “she should discuss it with everyone,” then the team had assigned coordination, not product operations. Every contested decision would still climb back to the founder.
That arrangement can survive a quiet week. It breaks when the options carry real costs.
Friday needed one decision owner
By Wednesday afternoon, Abena’s release plan was already under pressure. Sales wanted a customer request added before a scheduled demonstration. Engineering had discovered that the integration needed more work. The founder wanted the original onboarding fix to remain in scope.
All three requests sounded reasonable in isolation. Together, they made Friday doubtful.
The bad ending was specific: the team could ship a release containing three partially tested changes, then walk into the customer demonstration explaining defects that had not existed on Tuesday. Abena could see that outcome coming. She still had no agreed right to stop it.
This is where a title such as Product Operations can create false comfort. The title makes the ownership chart look complete while leaving the decision path unchanged. The person doing the work becomes accountable for a release assembled from choices other people can override at any moment.
I have seen the same authority gap beyond product work. A changed clause, an unsupported engineering request or a late approval can turn a named owner into a messenger. The underlying issue is the same one explored in Ama’s authority gap: responsibility becomes dangerous when the person carrying it cannot pause the work.
With one working day left, Abena put three release options on a call. The first protected onboarding and moved the customer request. The second protected the demonstration and delayed onboarding. The third kept everything and moved the release.
Then she asked the question the title had avoided: “Which of these can I decide without bringing it back to you?”
A useful mandate names the boundaries
The founder gave Abena authority to choose sprint scope and release readiness within the agreed product goal. Commercial commitments and changes to that goal still required his decision. Engineering could challenge her plan with technical evidence, but nobody could quietly add work after sprint scope was set.
That was the turn. It arrived late enough to matter.
Abena chose the second option. She documented what moved, why it moved and which customer feedback would return to planning the following week. Engineering now had one release target. Sales knew what the demonstration would include. The founder knew which decisions would still reach him.
The mandate did not make disagreement disappear. It gave disagreement somewhere to end.
A practical authority note can fit on one page. It should name the decisions the role owns, the decisions it recommends and the decisions it escalates. It should also state who can change sprint scope, who can delay a release and how customer commitments enter the roadmap.
Without those boundaries, Product Operations becomes the place where everyone sends unfinished decisions.
The next Tuesday looked different
At the following stand-up, Abena still had her sketchbook open. The lead engineer raised a new request that could affect the sprint.
This time, he did not announce that the plan might move. He explained the technical risk, offered two options and waited for Abena’s call.
She removed a lower-priority task and kept the release date. The founder did not need another meeting. The team moved on to the next item.
That small change is the real test of a new operating role. Watch what happens when two sensible priorities collide. If the new owner can make the trade-off and the team acts on it, the authority is real. If everyone waits for the founder to return, the title has changed and the operating system has not.
Comments
No comments yet.