A feature’s true cost includes every support question, edge case, and explanation it creates after launch. A one-afternoon build can become an expensive product decision when the team has to keep teaching customers how it works.
Imagine two founders, Kojo and Mara, at a small table in Accra on Friday morning. Kojo has a cooling coffee beside his laptop. Mara is holding a support export that runs several pages longer than either expected.
The feature took one afternoon to build.
Since launch, customers have repeatedly asked which option to choose, whether changing it affects existing records, and how to undo a selection. One customer’s deadline is now at risk because a setting produced an outcome their team did not expect. If Kojo and Mara cannot explain the recovery path before the customer’s next internal review, the account may cancel.
For one quiet beat, neither founder talks about code.
The estimate ended when the code shipped
The original decision looked sensible. A prospect had asked for the feature during a sales call. The engineer said it was small. Kojo could see how it might remove an objection and help close similar accounts.
By Friday afternoon, the feature was live.
The development estimate was accurate. That was the problem. It answered a narrower question than the founders thought they were asking.
“How long will this take to build?” covered the change to the product. It did not cover the names customers would misunderstand, the old data that would behave differently, or the support reply someone would need to write at 8 p.m.
Those costs sat outside the estimate, so they stayed invisible during the decision.
I have made versions of this mistake while building products. A short engineering estimate creates a sense that the decision is small. Once the code is cheap enough, discussion moves quickly toward shipping. The team spends less time asking what new responsibility the feature creates.
The useful estimate has at least two parts: the work required to release the feature, and the work required to keep it understandable.
Support hours reveal product debt
Mara returns to the support export and groups the conversations by cause. Several came from unclear wording. Others came from customers trying the feature on records created before it existed. A third group understood the setting but expected a different result.
The pattern changes the conversation.
They no longer have a collection of unrelated tickets. They have evidence that the feature asks customers to carry knowledge the interface does not provide.
This is where support time becomes useful product data. A repeated question can point to weak copy. A long explanation can expose a workflow with too many hidden rules. A customer asking how to reverse an action can reveal that the team designed the happy path and left recovery to support.
Counting tickets alone would miss this. Ten quick questions may cost less than one case that pulls a founder and engineer away from a renewal, a launch, or a production issue. On a small team, interruption carries its own price. The hour spent answering the question also breaks the afternoon that was meant for the roadmap.
This resembles the ownership problem in Kweku’s unowned conflict queue. Work becomes dangerous when everyone can see it but nobody owns the decision that clears it.
The feature needed a second owner
Kojo first suggests improving the help article. Mara asks a harder question: who owns the feature after release?
The engineer owned implementation. Nobody owned adoption, exceptions, or recovery. Support had become the default owner because customer confusion arrived there first.
With the customer’s review approaching, they divide the immediate work. Mara rewrites the setting in the customer’s language and prepares a short recovery path. Kojo contacts the customer with a direct explanation of what happened and what they can safely change. The engineer checks whether existing records need different handling.
Then they add a release question for future work: who will own the first month after this ships?
That owner does not need to answer every message. The role is to watch where customers hesitate, connect repeated confusion to a product change, and decide when a supposedly finished feature needs more work.
The same principle applies when a smaller team has to protect its roadmap. In Kojo’s product plan after a senior engineer resigned, the constraint forces a clearer view of what the team can continue carrying. Every feature adds weight after release, even when its first pull request was small.
Price the tail before approving the build
Before approving a small feature, I now want answers to four concrete questions.
What will customers need to understand before they can use it correctly? What happens to data or workflows that already exist? How does someone recover from the wrong choice? Who watches the support pattern after release?
These questions do not require a planning workshop. Ten focused minutes can expose a feature whose code is cheap and whose consequences are not.
By late Friday morning, Mara has reduced the recovery explanation to a few plain steps. Kojo sends it while the customer still has time to prepare for the review. The cancellation remains possible, but the customer now has a usable path instead of another apology.
The next feature estimate on their board still includes engineering time. Beside it sits a new line: first-month owner.
Comments
No comments yet.