The current product has dozens of known minor issues that cause significant user pain and have remained unresolved for months due to poor methodological execution. We receive constant user feedback — our North Star and our anchor to reality — and to improve user outcomes and satisfaction, we need an efficient process that channels collective thinking and structured argumentation into fast, reliable task execution. Enhancement Notes will serve as the decision-making funnel for system improvements, and the expectation is to handle them with the same speed as bugs.

Process

Hypertuesday: Surfacing User Pains

Each Hypertuesday, we review User Feedback as a team. User Feedback becomes part of our knowledge repository and exposes conflicts within it. A core task of the Seed System is to, as knowledge emerges, identify and resolve these contradictions and shape better solutions.

Labeling the User Pain

Every User Pain must be categorized as one of the following:

Bug: broken behavior.

Project: large initiative requiring discovery or multi-step planning.

Enhancement: small/medium improvement to an existing feature.

Distant-Future User Story: valuable but not actionable yet.

Writing the Enhancement Note.

If labeled as an Enhancement, a Team Member writes an Enhancement Note explaining:

The pain or problem.

The context.

Any relevant user comments or examples.

Enhancement Note

Argumentation & Review

The Enhancement Note is reviewed by relevant peers. Through argumentation structures, conflicts are resolved and clarity emerges.

Argumentation on an Enhancement Note

The Note is then updated with the agreed-upon solution.

Creating a Linear Task

Once a solution is agreed-upon, a Linear Task is created and assigned to a responsible person. It is prioritized alongside:

Active Bugs.

Ongoing Projects.

Other Enhancements.

This forms the Linear list of Issues the team executes against.

Linear list of Issues

Enhancement Notes Statuses

Inspired by Request for Comments from Internet Engineering Task Force and Wikipedia's RPC process.

The authors of the first RFCs typewrote their work and circulated hard copies among the typewrote researchers. Unlike the modern RFCs, many of the early RFCs were actual Requests for Comments and were titled as such to avoid sounding too declarative and to encourage discussion. The RFC leaves questions open and is written in a less formal style. This less formal style is now typical of typewrote documents, the precursor step before being approved as an RFC.

RFCs follow a lightweight, discussion-driven lifecycle:

Draft: The document is written but still evolving.

In Review: The proposal is open for comments, objections, and alternatives.

Accepted: Consensus is reached; the proposal is approved.

Implemented: The proposal has been executed and is now active.

Rejected: The proposal will not move forward (usually documented with reasons).

The key principles are: transparent stages, argumentation-first review, consensus-driven decisions, and implementation only after approval.

What is the difference between a Project and an Enhancement

A Project is a larger, higher-uncertainty initiative that requires discovery, design, or cross-team planning.
An Enhancement is a small, well-scoped improvement to an existing feature, where both the problem and solution are clear and can be executed quickly.