A competitor shipping the same feature does not automatically invalidate your roadmap. Before changing course, determine what customers hired the feature to do, what evidence still supports your version, and which decision can safely wait until you learn more.
At 6:12 a.m. in Accra, Kojo saw the screenshot before he had put on his glasses. Kojo is a composite founder, but the decision is familiar: a competitor had announced the feature his four-person team planned to release next month. The interface looked close enough that he enlarged the image twice, then opened the competitor’s product page to confirm it.
By the team stand-up, he would have to choose. Keep building and risk arriving second with an indistinguishable product, or stop the work and lose several weeks of engineering while runway kept shrinking.
The screenshot made both options feel irresponsible.
A launch announcement is evidence, but it is incomplete
Kojo’s first reaction was to compare surfaces. Both products accepted a customer request, used AI to produce a draft, and let a human approve the result. The competitor’s announcement made the overlap look complete.
It was not enough information to make a roadmap decision.
A feature announcement can confirm that another team sees value in the same problem. It cannot tell you whether customers use the feature after trying it, which segment values it, what the product gets wrong, or whether the company can distribute it economically.
Kojo had seen the competitor’s answer. He had not yet seen their reasoning.
That distinction matters because two similar interfaces can serve different jobs. A founder in Lagos may need a draft that a small team can review before sending. A German operations lead may care more about audit history and permissions. A US startup may accept rough output if it connects to the tools already inside its workflow.
The screenshot showed what had shipped. It did not show why customers would keep paying for it.
Return to the decision that put the feature on the roadmap
At 7:05, Kojo opened the document from the customer calls that had led to the feature. He ignored the proposed solution and reread the moments where prospects described the problem.
Three patterns mattered. The work arrived unpredictably. A senior person had to review every result. Mistakes became expensive only after the output reached a customer.
His team had designed around that review step. The competitor’s announcement focused on generating the first draft quickly. Kojo’s planned release focused on making approval visible and recoverable when something went wrong.
Now he had a sharper question: were customers buying faster generation, or safer delegation?
The roadmap still faced a real threat. If the competitor added approval controls before Kojo shipped, the remaining difference could disappear. If Kojo accelerated to protect the announcement date, his team might release the exact failure-prone workflow their customers feared.
There was no comfortable choice hiding inside the research.
This is the same discipline behind asking what Monday must prove after Friday’s demo wins the room. Applause, screenshots and polished demos create momentum. The next decision still needs evidence tied to actual use.
Change the next test before changing the whole roadmap
By 8:20, Kojo had stopped trying to decide whether the entire feature should live or die. He reduced the decision to what the team could learn before committing the rest of the build.
They would keep the approval workflow, remove two supporting capabilities from the first release, and put a working version in front of a small set of prospects. The test would begin after the AI produced its answer: could one person inspect the source, correct the output and show who approved it without returning to email or a spreadsheet?
If prospects treated those controls as unnecessary, Kojo would have evidence that his differentiation existed mainly in his own head. If they refused to delegate without them, the competitor’s launch would matter less than it had at 6:12.
This move protects runway because it changes the next commitment, not the company’s entire direction. Kelechi’s decision to prove one working feature follows the same constraint: when time is short, more building can hide the question that needs answering.
A copied feature should usually tighten the test. It should not trigger an automatic rewrite of the roadmap.
The stand-up needs a decision the team can execute
At stand-up, Kojo did not tell the team to ignore the competitor. He shared the screenshot, named the overlap and explained what remained uncertain.
Then he changed the week’s work.
One engineer would finish the approval path. The other would pause the supporting capabilities. Kojo would schedule prospect sessions around a specific failure scenario, not ask whether people “liked” the feature. By the end of those sessions, the team expected to know whether approval was central to the buying decision or merely reassuring decoration.
The competitor still might win. They might have stronger distribution, move faster, or discover the same need. Kojo could not remove that possibility with a morning meeting.
He could stop one screenshot from making the decision for him.
At 9:34, the image was still open in a browser tab. The roadmap beside it had fewer items than it did before breakfast, and one harder question at the top: will a customer delegate this work without the controls we are building?
That was enough for the team to start.
Comments
No comments yet.