The Problem With Feature Requests

A feature-request form is an easy thing to provide. A useful relationship with the people submitting it is harder.

From the practitioner’s side, the request often begins with work that should be easier: information entered twice, a missing export, a review step that cannot be recorded clearly, or a correction that is difficult to explain afterward. The practitioner has encountered the same friction enough times to describe a change that might help.

From the vendor’s side, that request joins competing obligations. Tax-law changes, maintenance, security, support, compatibility, and other users all make legitimate demands. The obvious improvement may have consequences the requester cannot see.

Neither perspective is wrong. The problem begins when the only bridge between them is a submission form followed by silence. Professional knowledge goes into the system, but the practitioner gets little sense of whether it was understood, rejected, deferred, or absorbed into a different solution.

PrepReturns grew partly from wanting a different relationship with our tools. Building it has also given me a better appreciation of why a small request can be difficult. Both lessons matter.

The request is often a diagnosis in disguise

Users tend to ask for a change they can picture. “Add a checkbox.” “Let me edit this field.” “Export these rows.” The proposed interface is a way of describing a problem, not necessarily the best design for solving it.

Imagine a preparer asking for an editable field beside a source-derived number. The immediate need may be simple: the source is wrong, or the software interpreted it incorrectly. But an unrestricted field could create a new ambiguity. Is the edited value now the source value, a manual override, or the established fact used in the return?

The underlying requirement may be a correction workflow that preserves the original, records the reason, and makes the authority clear. That is more work than adding a field. It is also more likely to solve the practitioner’s actual problem.

This is a hypothetical example of the general pattern, but it reflects a real design question in PrepReturns. Source review developed beyond accepting imported data into correction, addition, exclusion, and replacement. The important distinction was what each action meant to the evidence, not the number of controls on the page.

A good product conversation starts by asking what happened in the work. What did the preparer need to establish? What did the current software make difficult? What had to be tracked elsewhere? The answer may reveal a problem broader than the requested feature.

“Small” describes the screen, not the system

Building tax software makes this painfully clear. A small visible change can reach calculations, saved history, output, review, and next-year state.

Suppose a user wants an additional owner-specific statement. The visible deliverable may be one page. Behind it sit questions about the facts it contains, the owner it belongs to, when it should appear, how it is selected for printing, and whether a saved package preserves the version that was actually prepared.

An export request has similar depth. Does the export contain current inputs or an immutable prepared result? Does it preserve tax character and ownership context? Are missing values distinguishable from zero? Can the receiving system tell what was established and what is still proposed?

These are not reasons to dismiss the request. They are reasons to explain the design problem. A practitioner may prefer a narrower solution now once the tradeoff is visible. They may also supply an example that changes the implementation approach.

“That touches saved history and owner-specific output” is a meaningful response. “We’ll pass it along” may be courteous, but it does not help the user understand whether a solution is plausible or how to proceed in the meantime.

A backlog is a set of decisions

A backlog is often presented as a neutral list of future possibilities. In practice, it embodies priorities: whose problems are understood, which workflows are central, what the product considers in scope, and which kinds of work can wait.

That is unavoidable. No team can implement everything. A clear refusal can be healthier than an indefinite suggestion that every request is one vote away from development.

If a request falls outside the intended return universe, say so. If it is valuable but depends on foundational work, explain the dependency. If several different requests are being addressed through a broader redesign, connect them to that work. If there is no commitment, avoid language that sounds like a release promise.

This kind of transparency does not require publishing private planning material or letting a popularity contest determine tax architecture. It requires treating the user as someone capable of understanding a tradeoff.

Practitioners routinely make decisions under constraints. They can understand that a vendor has constraints too. What becomes frustrating is having no way to distinguish a considered decision from a request that simply disappeared.

Volume is not the only measure of value

A frequently requested change may deserve priority. Frequency alone cannot identify every important improvement.

Some problems are hard for users to articulate. A preparer may experience a confusing distinction between current and historical output as several unrelated annoyances. Few people may use the phrase “saved-package integrity,” even if many would benefit from a clearer model of it.

Other requests come from sophisticated users who have unusually good visibility into a system’s weak points. An export or API improvement may matter directly to a small group while enabling integrations that eventually benefit many more users.

There is also a difference between a rare workflow and a rare defect with serious consequences. Counting requests without understanding the failure mode can miss that distinction. The cost of confusion is not always proportional to the number of people who report it.

This is where product judgment belongs. Listen to the request, study the work, examine the architecture, and decide what problem is actually being solved. User input should inform that judgment without being reduced to a vote count or treated as an interruption.

Workarounds are product research

When a practice keeps a spreadsheet beside its tax software, the spreadsheet may be doing valuable work. It might reconcile a source, preserve an explanation, compare results, organize owner information, or bridge a missing export.

The existence of that spreadsheet is not proof the tax software is defective. Different tools can appropriately handle different tasks. But repeated workarounds are evidence worth studying. They show where the official workflow ends and the practice’s own system begins.

A useful question is whether the boundary is deliberate. Does the external schedule handle a specialized analysis outside the product’s scope? Or does it compensate for the software’s inability to remember a basic preparation decision? Those situations call for different responses.

Another question is what the workaround knows that the main system does not. If it carries the reason for a correction, that suggests an evidence problem. If it tracks which PDF was reviewed, that suggests a state problem. If it reorganizes output for an owner, that suggests a package-design problem.

Studying the workaround respects the practitioner’s ingenuity without assuming that every spreadsheet should be absorbed into the product. It turns informal practice knowledge into a clearer set of requirements.

Agency should have more than one path

The familiar options for a dissatisfied user are limited: accept the workflow, submit a request, switch products, or build something around the edges. Each can be reasonable. None necessarily gives the practice a way to solve the underlying problem on its own schedule.

Better interoperability adds another path. If information is available through documented, well-designed interfaces, a firm can build a focused tool around a specific need. It may not need the vendor to change the whole product. The extension can be small because the boundary is useful.

Open source could create a further path: inspect the behavior, propose a change, adapt a workflow, or maintain a fork where appropriate. Those possibilities are part of PrepReturns’ intended direction. The project is private today, so they are not rights the current website can grant.

More agency does not mean every practitioner becomes a programmer. A firm can hire someone, work with a specialist, or participate in a shared effort. What changes is the set of possible responses to a problem. Waiting for one vendor’s priority queue would no longer be the only route to a substantive change.

The open-source discussion explains that ambition, including the need for disciplined review of tax logic. Modifiability and professional responsibility have to develop together.

Building for ourselves creates its own blind spots

There is a danger in the practitioner-led story. “We know the work” can become an excuse to assume everyone works the same way.

Our practice supplies a grounded starting point. It does not supply every perspective. Another preparer may organize review differently, encounter a different supported pattern, or find an interaction confusing that has become familiar to the builder. Direct access to the product can make those differences visible.

That is one reason PrepReturns’ development uses separate review roles and actual browser and output inspection. It is also why human testing matters. A system that makes sense to its author still has to make sense to someone who did not design it.

The same humility should apply to incoming ideas. A request can be outside the current scope and still teach us something. A proposed solution can be wrong while its underlying complaint is right. Listening carefully is not a commitment to implement everything.

Close the loop, even when the answer is no

The best response to a feature request is not always a new feature. Sometimes it is a better explanation, a supported way to accomplish the task, a narrower extension, or a clear boundary that helps a practice choose its tools.

What matters is that the response acknowledges the professional work behind the request. Someone noticed friction, spent time understanding it, and tried to make the product better. That is useful information, even when the proposed design cannot be adopted.

I want PrepReturns to benefit from that kind of conversation. The product has deliberate boundaries, and I expect those boundaries to evolve through evidence, engineering, and practitioner judgment. I do not want “submit a feature request” to become a polite way of ending the discussion.

If something in the workflow overlaps with a problem in your practice, let’s compare notes. The most useful starting point is often not the feature you want. It is the work you are trying to do and the place where your current tools stop helping.