Somewhere right now, a product team is maintaining two versions of the same feature.
One of them, nobody decided to build.
It’s an AI chatbot, bolted onto an analytics product. Ask it anything about your data and it’ll build you a chart. A dashboard. A whole report, if you want. It can do almost anything, which turns out to be the problem, though it’ll take them a year to say that out loud.
For now they just know the engineering standup has a recurring item nobody enjoys: chatbot – legacy mode. The version kept alive for a handful of customers who, if you asked, couldn’t quite tell you why they wanted it.
How the team got here is a more interesting story than how they’ll get out.
It started, the way these things do, with a customer who mattered.
Not just any customer. The kind whose logo goes on the homepage, whose renewal shows up in the board deck. They wanted a chatbot, an AI you could talk to about your data instead of clicking through dashboards yourself. Ask a question, get an answer.
The team was thrilled. This was the fun kind of work. So they built the most capable thing they could imagine: a chatbot that could generate any chart, any view, any report you asked it for. Anything at all.
Nobody minded that it shipped a quarter late – it was genuinely impressive. You could ask it for anything!
The question nobody asked was what the customer actually wanted to do with it. They saw no reason to. The customer had told them exactly what they wanted.
The first week was everything they’d hoped. Usage spiked. People logged in, asked the chatbot to build them things, watched it work.
The second week was lower. The third, lower still. By the end of the month the line had flattened near the floor, and the people who’d been so excited on day one simply weren’t coming back.
Nobody could explain it. The thing worked. It did exactly what they’d promised: you asked, it built. They’d watch a brand-new user open it, type one question, get back a flawless chart…and then nothing. They never typed a second.
So the team did what teams do. They added suggested prompts. A carousel of “try asking me…” examples. Tooltips. They redesigned the empty state.
The line didn’t move.
Eventually, someone talked to the users. A handful of them who’d tried it once and never come back.
The answers were almost embarrassingly consistent. They hadn’t wanted to build anything. They’d opened the chatbot hoping it would tell them something – what was going on in their data, whether it was good or bad, what they should do next. They wanted a read. A recommendation. “Here’s what I’d look at if I were you.”
What they’d been handed instead was a blank box and unlimited power. And a tool that can build anything is also a tool that asks you to know exactly what you want built. It gave the work right back to the person who’d shown up needing help.
That was the second question nobody ever typed. There wasn’t one. They hadn’t come to build a chart. They’d come to be told what the chart meant.
The team would only see this part in hindsight.
The customer had asked for a chatbot. But “a chatbot” was never the real need.
The real need, the one nobody on the team had thought to ask about, was what the chatbot was for. Was it meant to build things for you? Explain things to you? Tell you what to do?
Those are three different products, solving three different problems. They share a text box and almost nothing else. Pick one, and you’ve designed a tool. Pick none, and you’ve built a blank box that can technically do all three and actually helps with none.
The team thought they were shipping a feature. What they were really doing – without knowing it – was making a decision. They just made it by accident.
But the problem isn’t really about chatbots.
Every prioritization method we reach for (ICE, RICE, the scoring spreadsheet a team argues over every quarter) does the same basic thing. It ranks the options already on the list. It assumes the hard part is choosing between things someone has already thought to name.
But “build” vs “explain” vs “prescribe” chatbot was never on that list. There was nothing to score, because the decision had quietly already been made by whoever first read “build a chatbot” as “build a thing that builds charts.” The most rigorous RICE score in the world can’t rank an option nobody put on the board.
Which is the trouble with picturing a backlog as a list of features. It’s closer to a list of decisions – most of them already made, most of them by default, most of them never deeply discussed or questioned.
So how does the decision ever make it onto the board, where it can actually be weighed?
Someone has to go looking for it. And that turns out to be a specific job.
Most of an organization is built to move fast inside a decision that’s already been made. Engineering asks how to build the thing well. Sales asks how to sell it. Prioritization asks how to sequence it against everything else. All of them, reasonably, take the thing itself as given.
The work of asking whether the thing is even the right thing – whether “build” should have been “explain” – is design and research. Not the part where someone picks the fonts. It’s the part where someone sits with a confused user, watches them open a blank box, and asks the question no one on the team had thought to ask: what did you actually come here to do?
That question doesn’t make the backlog longer. It changes what’s on it.
Which brings us back to the two modes.
After the research, the team built what users had wanted all along: the “explain” version that looked at the data and said what to do about it. Engagement recovered. The story could have ended there.
But the original chatbot was already out in the world. A handful of customers had wired the build-anything version into their workflows, and they weren’t giving it up. So the team kept it alive. Two code paths, two sets of bugs – one of them maintained indefinitely, in service of a decision no one ever actually made.
That’s the real cost of a skipped decision. It doesn’t stay skipped. It gets shipped, and adopted, and then it hardens into something a team maintains forever – a little slower on everything else they might have built instead.
The backlog never warned them. It couldn’t. The most important decision of the whole project was the only one that never appeared on it.