When Your Task Management System Accidentally Reveals How Products Actually Grow

I was three weeks into building a client's project tracking system when everything fell apart in the best possible way. We'd designed it around a simple idea: one task, one owner, one completion state. It worked fine until the client tried to archive their first major feature—only to get blocked by some child tasks they didn't remember creating. I remember the frustration in their voice: "But that was the next version. Why can't I close version one?"

That conversation stuck with me. And when I read about FCoP's accidental discovery of the project tree, I realized I'd been thinking about task management all wrong.

The Problem With Linear Task Thinking

Most of us build task systems as if work is a straight line: create task → assign → complete → archive. Move on. But that's not how real product development works, and I think we know this. We just don't design our systems to acknowledge it.

In the FCoP story, the admin assigned a simple task to build a mini-game—Grid Runner. It got completed, tested, accepted. Textbook linear workflow. Then Phase 2 happened, and suddenly what looked like a closed task became a parent. The archive failed because the system discovered something fundamental: products don't exist in isolation. They evolve. They branch. They compound.

The real insight wasn't the mini-game. It was that task systems need to understand product lineage.

How Evolution Looks on Disk

Here's what I appreciate about FCoP's approach: everything lives as files. TASK-*.md files, lifecycle folders, reports on disk. When the archive failed, there wasn't some mysterious database constraint—there was a human-readable explanation that PM could draw as a text tree.

020 Grid Runner initial version
└── 004 Phase 2
    ├── 005–007 implementation, ops check, playtest
    └── 008–009 bug fix and re-check

This is radically simple but profound. The task tree isn't a design feature someone built. It emerged from the natural way work actually happens. Phase 2 references Phase 1. Bug fixes reference the implementation. These relationships are already there in your work; most systems just ignore them.

I've spent hours debugging production issues that traced back to "lost context" between versions. If I'd had this kind of explicit parent-child tracking, a lot of that archaeology would've been unnecessary.

My Take: The Accidental Discovery Matters More Than the Protocol

What strikes me most is that FCoP didn't need to be redesigned to support project trees. The structure was already there—the PM just had to explain it to the admin by drawing what everyone could see on disk.

This tells me something important: sometimes the best systems emerge from observation, not specification. The FCoP team didn't sit down and say "let's design hierarchical task relationships." They built a simple file-based protocol and discovered the pattern when it broke.

I think most of us over-engineer our task systems upfront. We try to anticipate every relationship type, every workflow variant, every edge case. Then we end up with feature bloat and rigidity. What if we started simpler—just ensure everything is recorded, everything is traceable, and let the actual relationships reveal themselves?

That said, I'd want visibility of these relationships earlier. The admin shouldn't have to be told by PM in a chat message. The console could highlight parent-child links, show version lineage, and make it obvious that archiving the parent depends on closing the children. The pattern was hidden in plain sight.

What This Means for How I'd Build It

If I were building a task system tomorrow, I'd lean into this: make parent-child relationships first-class citizens, not emergencies discovered during archive failures.

# TASK-20260613-020.md
title: Grid Runner v0.1
status: done
children:
  - TASK-20260614-004
  - TASK-20260614-004/005
  - TASK-20260614-004/006
  - TASK-20260614-004/007

# TASK-20260614-004.md
title: Grid Runner Phase 2
status: in_progress
parent: TASK-20260613-020
children:
  - TASK-20260614-005
  - TASK-20260614-006
  - TASK-20260614-007
  - TASK-20260614-008
  - TASK-20260614-009

This makes the tree readable upfront. You can see at a glance that 020 isn't closeable until its entire subtree is done. You can understand product evolution just by reading the file structure.

The Question I'm Left With

Does your current task system know when a task is a version versus a fix? Can it distinguish between a natural product evolution and a completely independent piece of work?

I suspect most systems can't, which means we're probably all flying blind to some degree about how our products actually develop.

Source: This post was inspired by "FCoP Grew a Project Tree" by Dev.to. Read the original article