Your Product Does Not Need More Feedback. It Needs Better Evidence.
Your Product Does Not Need More Feedback. It Needs Better Evidence.
Software companies building for accounting firms often say they want customer feedback.
What they usually receive is a mixture of feature requests, subjective preferences, support issues and reactions to product demonstrations. Some of that information is useful, but it does not necessarily tell the product team whether the software will work in the real world.
That is where a design partner can add value.
A design partner is more than an early customer or a friendly group of beta testers. The role is to help a software company test its assumptions against real workflows, imperfect data and the professional judgement of the people who will eventually use the product.
At Preflight Labs, we have been working with multiple accounting technology companies through this type of relationship. The products are in their infancy, however, the work has reinforced several important lessons for software companies building products for accountants and bookkeepers.
Start with the workflow, not the feature
Product conversations often begin with a proposed feature.
The team may be considering a new report, an automated workflow, an artificial intelligence agent or a different way to display financial information. The temptation is to immediately evaluate whether the feature is useful.
A better starting point is to understand the work surrounding it.
Who is completing the task? What triggers it? Which systems contain the required information? What decisions must the practitioner make? What happens when information is missing? What evidence does the user need before accepting the result?
These questions frequently reveal that the initial feature request is only one part of a larger operational problem.
Accounting work rarely happens entirely inside one application. A single process might involve the general ledger, a spreadsheet, email, a billing platform and a practice-management system. A capability that appears efficient in a demonstration can create new friction when inserted into that broader workflow.
The design partner’s job is not simply to approve or reject the proposed feature. It is to help the product team understand the environment in which it must operate.
Clean demo data creates false confidence
One of the greatest risks in accounting software development is testing products against data that is too clean.
Demonstration files tend to be organised, consistently coded and free of the unusual transactions that accumulate in real businesses. Client files are different. They contain incomplete descriptions, duplicate entries, inconsistent categorisation, legacy decisions and information entered by multiple people with different levels of accounting knowledge.
A product may perform impressively against a controlled dataset and still struggle when introduced to a real firm.
This becomes especially important when software is expected to interpret financial data or recommend an action. The question is not just whether the system can produce an answer. The product must also help the practitioner understand why that answer was reached, what evidence supports it and where uncertainty remains.
In accounting technology, explainability is not a secondary feature. It is part of the product.
Good feedback must be structured
“Looks good” is not useful product feedback.
Neither is a long list of disconnected comments from different users. For feedback to influence development, it needs to be specific enough for the product team to diagnose the issue and decide what to do next.
During a design-partner engagement, findings can be grouped into categories such as:
Incorrect or unexpected outputs
Missed items and false positives
Unclear supporting evidence
Data-quality limitations
Workflow friction
Usability and language issues
Trust and confidence concerns
This structure helps distinguish a software defect from a usability problem or a limitation caused by the underlying data.
It also allows the team to identify patterns. One confusing result may be an isolated case. The same issue appearing across several workflows may indicate a fundamental product assumption that needs to be reconsidered.
The most valuable work happens between testing rounds
A design partnership should be iterative.
The software company develops or updates a capability. The design partner tests it against representative scenarios. The findings are documented and discussed. The product team makes changes, and the revised version is tested again.
Each cycle should reduce uncertainty.
The goal is not to produce the largest possible feedback report. It is to generate enough evidence for the product team to make a better decision about what to build, change, simplify or postpone.
This is also why a design partner should not be overly agreeable. A partner who validates every idea may make the development process feel easier, but they are not reducing product risk.
The useful partner is the one willing to say that a workflow is unrealistic, an output cannot yet be trusted or a feature is creating more complexity than value.
Product validation should shape go-to-market strategy
Design-partner work is often treated as a product-development activity, but it also has a direct impact on marketing and sales.
Testing helps reveal which use cases create immediate value, which require substantial behaviour change and which depend on unusually clean data. These insights should influence product positioning, demonstrations, onboarding and sales conversations.
A software company should market the problems it can reliably solve today, not just the future vision of the platform.
When product validation and go-to-market planning happen separately, companies risk promising an experience the product cannot consistently deliver. When they inform each other, the company can tell a clearer and more credible story.
A design partner should make the product team smarter
The purpose of a design partner is not to act as an outsourced product manager or a permanent testing department.
The objective is to bring a different form of expertise into the development process: knowledge of the profession, exposure to real workflows and the ability to translate practitioner experience into actionable product evidence.
Software teams bring the vision and technical capability. Practitioners bring context, professional judgement and an understanding of how work is actually completed.
The strongest products emerge when those perspectives meet early enough to influence what gets built.
That is the real value of a design partnership. It does not eliminate product risk, but it exposes the right risks sooner, while the team still has time to respond.