Namsang Labs
Essay · #ai #product-engineering #decision-making

More Features, Same Product

· Sangkyoon Nam

On a kanban board the DONE column overflows with small cards spilling to the floor. TODO and DOING have their share of cards too, but in DOING the three important cards marked with red stars sit faded, each carrying red DELAY magnets

Sangyun was the engineering lead at an edtech startup, and one problem had refused to go away for two quarters. About six months after AI settled into the company, the Done column on the kanban board filled up noticeably. Yet in the quarter with the most closed cards ever, the product had not grown by anything like what those cards added up to. Sangyun and this company are a composite I built from things I’ve been through and heard about.

What filled the Done column was small features. One coordinator on the operations team used to file a card asking the dev team to pull per-class assignment submissions, then wait a week. Now the coordinator handed the data query to AI, attached a small screen that showed submissions per class in a table, and built the whole thing alone in an afternoon. The coordinator closed more than thirty cards in a quarter. The sales team built a one-button tool that produced the report they used to assemble by hand, and other teams untangled their own annoyances the same way, one at a time. Whoever asked used it right away, and whoever built it picked up the next card. Taken one by one, everything worked.

Then one important card got caught on those tools. When the “Learning Report Revamp” gathered the numbers those tools used, to settle the student count for the teacher screen, each one was different. The same “student” was being counted differently by every tool. With no decision on which number to put on the teacher screen, that card sat in the same spot for two quarters while the small cards kept closing.

#The product has no one to fill the gaps

Inside the company it was bearable. When the operations tool and the sales tool disagreed a little, the people using them reconciled the numbers by eye and kept working. It was annoying, but work got done.

The product that went out to users was different. Teachers knew nothing about the company’s internals and expected the same product no matter which screen they opened. While the revamp was stalled, one small card the dev team closed put an active student count on the teacher screen first. That number came from the operations coordinator’s class screen, and that same day a teacher asked why it differed from the report the teacher had received from a sales rep. The class screen counted students enrolled in the class. The sales report counted students who had submitted an assignment in the last thirty days. Both teams called their number “active students,” and for each team’s own work both numbers were right. Nobody could answer which one belonged on the teacher screen.

Answering a single teacher inquiry meant the sales and operations teams laying out their calculations side by side and reconciling them. Fix one and the other drifted, and meanwhile big cards like the “Learning Report Revamp” kept sliding back. A company of about sixty people had two teams tied up reconciling one number. Two quarters earlier, none of this had existed.

#What a week’s wait happened to protect

Back then the operations coordinator waited a week for an answer from the dev team, and requests about student counts came through that same window. The few people who received them pulled up the query they had used last time and adjusted it. Someone new to the dev team asked a colleague who knew the query before writing one. The company had never agreed on a definition of “student,” but as long as the same people kept editing the same queries, the number was counted one way most of the time. What that week protected was this accidental consistency.

The people who started building tools got a plausible new query straight from AI without going through the dev team. Inside the dev team, too, people asked AI before asking a colleague. Requests stopped passing through the same hands, and once that window was gone, cards touching the same number started counting “student” on their own, all at once. The quarter the window disappeared was the quarter to set the definition. All Sangyun could see at the time was a growing pile of closed cards.

#The small card that closes first becomes debt

The “Learning Report Revamp” started out as a job of settling one definition of a student and building a new screen. But when the team went to settle it, students were already being counted in several places, and picking any one as the shared definition meant also changing the screens and reports built on the other calculations. The decision on how to count an “active student” had been put off that way. Meanwhile the sales team set its quarterly target on the thirty-day number, and the operations team answered schools from the class screen. Both had started as temporary criteria, chosen to get each team’s own work done. The stopgap meant for a short while became the definition everyone leaned on. Small as the scale is, it’s a scene that brings Hyrum Wright’s law to mind: somebody comes to depend on behavior nobody promised.

After a few more teacher inquiries, Sangyun re-estimated the “Learning Report Revamp.” The work scoped at two weeks had grown to two months. The places counting students had grown to seven, and a job that used to mean building one screen now meant finding those calculations, reconciling them, and notifying everyone who depended on them. The shared definition had not even been set, and the ones each team had picked first were already hard to change. Kent Beck, who created Extreme Programming, said that it used to take a hundred people ten years to get code to the point where it was hard to change. With AI, Beck said, one person can get there in a week. What became hard to change in this company was not the code but seven scattered calculations and the work built on those numbers, and getting there took two quarters.

The small cards had borrowed, on a guess, a decision nobody had made yet, and each one that closed added interest to the big card. The borrower and the payer were different people. The operations coordinator saved time that same day and the sales team set its target, but the bill arrived months later, all at once, for Sangyun, who picked up the big card. In the meantime the small tools relieved each team’s pain first, and the reason to push the big card through shrank with it. When the painkiller works, you stop going to the doctor.

#Every number got an owner

After re-estimating at two months, Sangyun went to the CEO first. What Sangyun brought was not a screen design but a single question: who in the company decides how many “active students” there are? The CEO asked whether that wasn’t the dev team’s job. Sangyun answered that the dev team had never decided it, and that the number had simply been counted that way because people kept reworking the previous query.

So every number got an owner. They wrote down the twelve kinds of numbers that went out to the teacher screen or to other teams, and the CEO assigned an owner to each one on the spot. Most of the numbers that went out to the teacher screen, “active student” and “done” among them, went to a single planner, the one in charge of that screen. Sangyun saw the pile-up right there but had no one else to hand them to. Until the owner decided, that number would not be sent out. The CEO announced the assignments at the all-hands. The owner’s job ended at setting the definition. Queries and screens were still built by whoever asked, with AI, as before.

The planner went to each team that used one of the seven calculations and asked what the number was for. It took three weeks to settle that a student who had submitted an assignment in the last thirty days was “active” and a student on the class roster was “enrolled.” Only the cards that sent out one of those twelve kinds had to wait for the owner’s answer. In the quarter the owners were assigned, four of the thirty cards the operations coordinator closed fell into that group, and the rest closed in an afternoon, as before. Once each team aligned the seven calculations to the two definitions, the revamp started moving again. Folding those calculations into one shared set of queries was left for later.

A card used only within a team needed one line left with the owner before it closed. Notes like “sales weekly tally: counting submitted as done for now” gathered under each definition the planner owned. The note recorded who to tell when the definition changed, and which tools to fix along with it.

The next quarter, the planner defined “done” as an assignment a teacher had confirmed. The sales team objected that its weekly tally would shrink, and the planner answered that the number went out on the teacher screen, so only what a teacher had confirmed could count as done. The sales team did not withdraw the objection, and the planner decided it anyway. The day the definition changed, the planner pulled out the notes gathered under “done.” The three cards with notes were brought in line with the new definition by their teams within two days. The one card without a note was not on the list, and the operations team did not find it, still counting by the old definition, until two weeks later.

#Nothing goes out before the owner decides

Kent Beck’s advice was to stop between features and refactor, to restore the room to change the code. In code, the person who built it can be the one who stops. In this company, the first question was who would stop and who would decide. Holding numbers back until the owner decided stopped the debt of guesses, and the one-line note left with the owner kept the room to change the definition later. The questions to ask before closing a card came down to four.

  • What got easier for the customer when this card closed?
  • Did this card borrow a decision nobody has made yet, on a guess?
  • Was this card meant to be used briefly and thrown away, or has it become something other cards lean on?
  • Who decides the definition this card relies on, and who keeps track of the whole?

It would be hard to call assigning owners the answer. For the numbers that left a team, it came closer to making each card’s underlying definition visible and having a person decide it directly. Every time a number appeared outside the twelve kinds, an owner had to be assigned again, and the problem of definitions piling up on one planner was not solved. Sangyun was still looking for something better.

Still, there was now somewhere to ask when numbers disagreed. Adding features had not made a product, and checking how the cards connected and fitting them together had turned out to take time of its own. Anyone can close a card. Someone has to hold on to what it was closed for.

#References

  • DORA: User-centric focus: argues for measuring the value that reached users rather than how many features were built, and explains that AI amplifies an organization’s strengths and problems alike.
  • Hyrum’s Law: Hyrum Wright’s observation that with enough users, every observable behavior of a system will be depended on by somebody, regardless of what was promised.
  • Kent Beck: Software Engineering in the Age of AI (Prodacity 2026): says it used to take a hundred people ten years to reach code that is hard to change and that with AI one person can get there in a week, and points out that stopping between features to refactor and restore the room to change is in no spec, so nobody asks for it.

Share this post