Find the rework pattern before adding product capacity
-
Moe Hachem - August 3, 2026
Are you about to add product capacity to absorb work your team keeps recreating?
Before you open the role, trace the last three recurrences. If missing decisions, state, or ownership keep reopening the work, the hire will absorb ambiguity rather than add capacity.
The team may still look overloaded. The roadmap slips, engineering keeps returning with questions, support escalates the same customer issue, and the founder gets pulled back into decisions they thought had already been made. Everyone is busy enough to make another hire feel obvious.
Sometimes another experienced person is exactly what the company needs. The risk is treating every form of repeated work as proof of a capacity gap.
A team can be overloaded because it has more valuable work than its current people can responsibly deliver. It can also be overloaded because decisions keep reopening, ownership moves depending on who is in the room, customer context disappears between teams, or a product flow is compensating for an operating rule nobody has settled.
Those failures create activity that looks like demand. A capable hire can carry more of it, though adding capacity does not remove the reason the work keeps coming back.
The first job is to find the rework pattern.
Rework is a signal, not yet a diagnosis
Rework usually arrives disguised as a collection of separate requests.
The requests arrive from several directions: sales wants one more exception for an important account, support wants the interface to explain a state customers keep asking about, engineering wants a firmer specification, operations wants a manual override, and the founder wants the roadmap to stop changing after every difficult conversation.
Each request can be reasonable. The pattern appears when they keep returning to the same product decision.
A checkout exception may reopen because the commercial promise and fulfilment rule do not match. An onboarding flow may keep changing because the company has not decided which customer it is optimising for. A dashboard may be redesigned repeatedly because each team expects it to answer a different operating question. A feature can move in and out of the roadmap because nobody recorded the evidence, constraint, and tradeoff behind the original choice.
The visible tasks are different, but the same unresolved decision is generating them.
That distinction matters before hiring. If the team has not named the recurring decision, it cannot define what the new person should own, which work should disappear, or how anyone will know whether the role improved the system.
The company hires someone into a backlog and keeps the pattern.
When I hear that a product team needs more capacity, I do not start by disputing the workload. I ask the founder to show me what keeps returning. Which decision has your team made more than once? Where did your people have to rebuild context? What work would disappear if the underlying issue were actually closed?
Your answers do not prove that a hire is unnecessary. They give you a better way to define what the person would be hired to change.
Start with the last three recurrences
I would begin with the last three times the work reopened, not with a new job description.
The goal is to reconstruct enough of the route to see whether the work is genuinely new or the same decision returning under a different label.
For each recurrence, capture six things:
- What reopened? Name the feature, workflow, customer promise, policy, or priority that returned.
- What changed? Identify the new evidence, customer condition, commercial commitment, delivery constraint, or leadership instruction.
- What was missing? Look for a dropped decision record, absent customer context, unclear rule, missing owner, or system state that did not travel.
- Who could close it? Separate the person doing the work from the person with authority to decide.
- What had already been promised? Record the customer, sales, delivery, or internal commitment the next decision has to respect.
- Why could the issue return? Find the part of the route that remains unchanged after the immediate task is completed.
Three examples are often enough to reveal whether the team is seeing volume or recurrence. One incident may be noise. The same decision reopening through support, engineering, and sales is a pattern.
This exercise should stay close to the work. Read the tickets, look at the messages, speak with the people who handled the exception, and inspect what the product showed at the time. A clean summary written after the fact can hide the handoffs that made the issue expensive.
The useful evidence is usually found where the official process stops naming steps and the team starts naming people: the operator who remembers the workaround, the founder who can approve the exception, the engineer who knows why the earlier approach failed, or the support lead who keeps the customer promise from drifting.
That knowledge is valuable. It becomes a capacity problem when the organisation depends on those people to reconstruct it every time.
Four different pressures can produce the same workload
Once the recurrences are visible, the work usually separates into four pressures.
1. Decision debt
The team keeps revisiting a choice because the reason behind it was never made inspectable.
A decision was made in a meeting, a task was created, and the work moved forward. The evidence, rejected alternatives, constraints, and owner did not move with it. When the customer condition changes or somebody new enters the discussion, the team has to argue the choice again.
Another hire gives the company one more person who can join the argument. The stronger response is to attach enough decision state to the work that the next person can understand, challenge, or update it without beginning from zero.
2. State loss between teams
The decision exists, but the next team receives only the task.
Sales knows what the customer was promised. Support knows which exception keeps recurring. Operations knows which workaround keeps the service moving. Engineering receives a ticket describing the requested change. Each person holds part of the truth, and the product team becomes the place where those fragments are reconstructed.
This can make product look understaffed even when the main issue is the way information moves. More product capacity may help, but the company should first decide which state has to survive the handoff and where it will live.
3. An operating rule hiding inside a product request
A team can ask for a screen when the unresolved issue is policy, ownership, or service design.
The interface may need to show a refund status, though somebody still has to decide which evidence qualifies, who can approve the remedy, what the customer should be told, and whether the case returns to the normal route. A new product person can design the screen. They cannot compensate indefinitely for a rule the business refuses to name.
The work belongs in product only after the operating decision is visible enough to support it.
4. Genuine delivery demand
The direction is settled, the decision owner is known, the workflow carries the state people need, and the team still has more valuable work than it can deliver.
Only the fourth pressure is unambiguously a capacity gap.
At this point, another hire has a definable job. The company can name the decisions they will own, the work they will take over, the interfaces they will maintain, and the outcomes that should improve. The new person arrives to add judgment and throughput rather than become the memory of an unresolved operating model.
Measure the recurrence before estimating the role
The point is not to turn every product decision into a finance exercise. A small amount of measurement can stop a vague workload from becoming a vague hire.
Track how often the issue returns, how many people have to re-enter the discussion, how long the work waits for a decision, and what planned work gets displaced. Include the time your team spends reconstructing the prior state, not only the time spent making the final change.
If you can show that the same decision reopened four times and pulled five people away from planned work, you have a better hiring brief than a backlog count can provide. You can also see whether the role needs product judgment, operating ownership, delivery capacity, or a mixture of them.
A task that takes two hours to implement can consume several days of the organisation’s attention if support, sales, operations, product, and engineering each have to rebuild the context before anyone can act.
That hidden coordination work is part of the backlog’s cost.
The numbers do not need false precision. Their purpose is to show whether the company is paying for genuine demand, recurring reconstruction, or both. Those measurements are enough to define a better response.
Decision debt needs a record and an owner. State loss needs a stronger handoff. An operating-rule mismatch needs policy or service work. Genuine demand needs capacity. Mixed patterns may justify a hire alongside an operating repair, but at least the person is no longer being hired into a mystery.
Give the next person a job they can succeed in
Before you approve the role, ask what the person will inherit beyond a backlog and a set of introductions.
The new person should be able to see which customer problems matter, which commitments the business has made, which product decisions keep reopening, who owns the tradeoffs, and what evidence changes a priority. They should know where the team expects judgment, where it expects delivery, and where the operating model still needs to be challenged.
You do not need to write a large manual. Give the person a small set of working artifacts your team already uses: a decision trail, a view of the recurring workflow, visible ownership boundaries, a prioritised route, and a record of the assumptions still being tested.
Those assets make a hire more effective. They also make it possible to discover that the company does not need the role it was about to open.
Discovering that the role is unnecessary should remain an acceptable outcome.
I prefer beginning with a focused diagnosis for the same reason. The first phase should leave the team with the failure pattern, the evidence behind it, the decisions that follow, and the open questions still worth investigating. The company can use that result with me, its internal team, a permanent hire, or another specialist.
The work should earn the next phase rather than assume it.
The Dubai startup cost is larger than salary
For Dubai and UAE startups, senior product capacity is expensive, and the cost of an undefined role extends beyond compensation.
A small team gives every senior hire structural weight. The person changes how founders spend time, how engineering receives direction, how customer evidence is interpreted, and where commercial promises are challenged. If the role has no defined decision boundary, the company has added another centre of gravity without resolving the one it already had.
Local operating environments can add more joins to the work. Customer-facing teams may coordinate through calls and WhatsApp while formal state sits in a CRM or ticketing platform. Delivery can cross office staff, field operators, external partners, and regional vendors. The founder may still hold the relationship between those facts in their head.
None of that automatically means your team needs a product leader; it means you should understand the route the role is expected to improve.
The decision can then be specific: add permanent capacity, bring in temporary senior ownership, repair the workflow internally, or inspect the product and operating problem before choosing.
A focused product and UX diagnosis is one way I do that first-stage work. It gives the founder a lower-pressure environment to see how I think, and it gives both sides a useful result whether the relationship continues or ends there.
If the evidence points toward a permanent hire, the work should make that hire easier. If it points toward a workflow repair, a product change, or no build at all, the company should be free to take that route.
The point is to hire for work the organisation can finally name.