When a demo changes every week and runway is shrinking, the designer’s highest-value work may be tracing how customer requests become roadmap decisions. That map shows where evidence gets lost, who can commit the team, and which requests should never reach the build queue.
At 9:12 on a Monday morning in Accra, Adwoa closed Figma with three half-finished screens still open. She is a composite founder-designer, the kind who checks support messages before breakfast and remembers every awkward pause from the previous demo. By noon, the founder expected a cleaner onboarding flow for an overseas prospect. By Friday, engineering needed a stable scope.
Neither looked likely.
The prospect had asked for approval controls. A current pilot wanted downloadable reports. The founder had promised both requests would be considered, and an engineer had already started estimating the approval work. If Adwoa polished the new flow, the demo might look coherent by noon. If the founder treated that polish as agreement, the team could spend another week building for a buyer who had made no commitment.
The runway could not absorb another decorative detour.
The request had changed each time someone repeated it
Adwoa opened a blank page and wrote down the approval request exactly as she had heard it.
The prospect wanted “more control.”
The founder translated that into manager approval.
The engineer heard roles and permissions.
Adwoa had drawn a review screen, an activity log and three account states.
Four people had handled the request. Each had added a decision. Nobody could point to the person who had confirmed the underlying problem, or say what the prospect would do if the feature existed.
This pattern appears often in early AI and SaaS products. A buyer describes a constraint during a call. Someone converts it into a familiar feature. Design makes the feature visible, which makes it feel agreed. Engineering estimates it, and the estimate gives it the weight of a plan.
By then, asking where the request came from sounds like resistance.
I have seen the same thing while building across African, European and US markets. The wording changes by market, but the failure is familiar: customer evidence travels through several people, while decision authority remains vague. A loud request can cross the company faster than a verified one.
Adwoa mapped authority before drawing another screen
She made four columns: who asked, who interpreted, who decides, and what evidence changes the roadmap.
The first row exposed the problem. The person requesting approval controls used the product, but did not control the purchase. The buyer had not joined the demo. No contract depended on the feature. No one had asked whether the existing workflow could handle the same job.
The second row was worse. The downloadable report request came from a paying pilot, but the founder had promised a date before engineering had assessed the work. That request had commercial weight and delivery risk. It deserved attention, yet it still lacked a named decision owner.
Adwoa took the page into the noon call. Instead of showing polished screens, she showed one plain workflow and asked who needed to approve what, at which point, and what happened when approval was missing.
The prospect hesitated.
For one beat, the call could have gone badly. The founder had expected visual progress, and the overseas contract mattered. If the prospect read the questions as unpreparedness, the opportunity might close before the team had another route to revenue.
Then the prospect described the actual concern: staff could send work outside the company before a manager saw it. The issue was narrower than the interface Adwoa had drawn. It also involved policy and process, not only software.
That distinction saved the week.
A request needs an evidence path and a decision owner
Closing Figma did not make Adwoa less of a designer. It moved her closer to the decision that shaped the product.
For a small team, every substantial request needs a short trace:
- Who experienced the problem?
- Who can approve a purchase or renewal?
- What evidence shows the problem is frequent or costly?
- Who can commit design and engineering time?
- What would make the team decline or delay the request?
The answers can fit on one page. Their value comes from forcing the team to separate customer language, internal interpretation and roadmap authority.
This matters most when a contract could extend runway. Revenue pressure can turn a prospect’s preference into an emergency. The safer move is to make the buyer pay for meaningful divergence, a decision explored in why Nii made the buyer pay for the fork. A pilot can fund learning without quietly becoming the product.
The same discipline applies after a promise has been made. Abena’s four executive promises shows what happens when commitments accumulate faster than delivery capacity.
Friday looked different because the decision path was visible
By Friday morning, Adwoa had replaced the broad approval concept with a smaller test around the specific risk the prospect had described. Engineering had not started the roles system. The downloadable report request had a named owner and a review point. The founder could see which commitment affected revenue and which one remained an unverified preference.
Three unfinished screens were still sitting in Figma.
They no longer looked like overdue work. They looked like decisions the team had avoided making. Adwoa left them untouched, opened the request map and added one final line beside the prospect’s name: “Buyer confirmation still required.”
Comments
No comments yet.