In some of our early startup screening work, we noticed a recurring problem. The companies could describe their businesses, explain their markets, present financial projections, and outline what they planned to accomplish. But when we looked for the underlying records supporting those explanations, important questions remained unresolved.
Could reported commercial traction be traced to individual customers and transactions? Did the company have a reliable picture of its current financial position? Were product performance claims supported by reproducible evidence? Did the financing plan reflect the actual obligations and constraints of the business?
These observations came from an internal screening exercise, not a representative study of startups. They were also based on the materials submitted for review, which may not have included everything available inside the companies.
I would not use them to draw conclusions about the broader startup market or the quality of the businesses involved.
But the experience raised a question that has stayed with me.
If a company cannot substantiate the information it uses to explain itself to outsiders, how confidently can its management rely on that same information to make decisions?
The answer is not always straightforward. A company may have strong internal systems and simply prepare an incomplete investor package. But when the missing evidence reflects how information is actually managed, the issue goes well beyond fundraising.
It becomes an operating problem.
The information a company needs to understand itself
A growing business produces an enormous amount of information. Customer conversations, contracts, invoices, product usage, operating expenses, implementation records, support requests, and financial transactions all describe some part of what the company is doing.
Yet producing information and being able to use it are different things.
Consider something as basic as the number of customers.
A sales team may include signed accounts, customers in implementation, active pilots, and businesses that have committed verbally. Product teams may count organizations actively using the platform. Finance may recognize only accounts with billable activity.
Each definition serves a legitimate purpose.
The problem arises when those definitions are combined into one number without a clear distinction between them.
Management may believe it understands its commercial position because the company reports a growing customer base. But that figure may not explain how many customers are paying, how many have successfully implemented the product, how much support they require, or how many are likely to renew.
Those are different questions, and they lead to different decisions.
A company deciding whether to hire another salesperson needs different evidence from a company deciding whether to hire an implementation specialist. Both decisions may be justified by customer growth, but only if the underlying information explains where the additional demand is appearing.
Without that distinction, management can respond to growth by adding resources in the wrong part of the business.
Following the customer beyond the sales report
I find account-level records particularly useful because they connect several parts of a company that are often managed separately.
A customer relationship begins somewhere in the commercial process, but its economics develop over time.
A contract is signed. Implementation begins. Employees spend time configuring or delivering the service. Invoices are issued and collected. The customer uses the product, requests changes, receives support, and eventually renews, expands, or leaves.
Each stage produces information, but that information may live in different systems and belong to different teams.
The sales organization knows what was promised. Delivery knows what it took to fulfill that promise. Finance knows what was billed and collected. Customer success knows whether the customer continues to receive value.
If these records can be connected, management can begin answering more useful questions.
Are the fastest-growing customer segments also the most profitable? Which accounts require disproportionate implementation effort? Are certain contract structures associated with more exceptions or delays? Does a product feature that attracts customers also contribute to retention?
These relationships can challenge assumptions that initially seemed reasonable.
A customer segment may appear highly attractive because contracts are relatively large. But the same customers may require extensive customization, long implementation periods, or continued involvement from senior employees.
That does not automatically make the segment unattractive. It may still be strategically important or commercially profitable.
But management needs to understand the full relationship before deciding to pursue more of the same customers.
Otherwise, the company risks scaling a commercial model whose operating requirements it has never fully measured.
Financial clarity is more than knowing the burn rate
Financial reporting presents a similar challenge.
Most growing companies track revenue, expenses, cash balances, and some measure of burn. These numbers are essential, but they do not necessarily explain the economics of individual activities.
A business can report increasing revenue while the cost of serving particular customers rises faster than expected. A software company may have attractive subscription margins but spend considerable resources on onboarding, support, or customer-specific development.
Some of those costs are relatively easy to identify. Others are absorbed into existing salaries, shared infrastructure, and management time.
The distinction matters because the company may be making pricing, hiring, and expansion decisions based on an incomplete understanding of contribution.
Take a company planning to expand into another market.
Its current revenue growth may justify optimism. But whether expansion makes sense depends on more than the revenue forecast. Management needs to understand the cash required before new customers become productive, the cost of delivering the service, the capacity of existing teams, and what happens if acquisition or implementation takes longer than expected.
A monthly financial forecast becomes much more useful when it is connected to operational assumptions rather than treated as a separate finance exercise.
Hiring dates should reflect the capacity the company expects to need. Revenue assumptions should correspond to customer acquisition and delivery realities. Product investment should be connected to the outcomes management expects it to produce.
These relationships will never be perfectly predictable.
The purpose is not to eliminate uncertainty. It is to make the assumptions visible enough that management can recognize when reality begins to diverge from the plan.
Product evidence changes what gets built
Another recurring issue in startup evaluation is the difference between a product claim and the evidence supporting it.
Companies often describe their products in terms of improvements: faster processing, lower costs, better accuracy, higher conversion, or reduced manual work.
Those statements may be accurate. But their usefulness depends on how the results were measured.
If an automation reportedly reduces processing time by 60%, management should understand the baseline, the workflow being measured, the period of observation, and the amount of human intervention still required.
A successful pilot may include substantial manual support that will not be available when the product serves hundreds of customers.
An improvement observed with one customer may depend on operating conditions that do not exist elsewhere.
Without these distinctions, a company can make the wrong product decision even when the reported result is technically correct.
It may invest in expanding a feature before establishing whether the improvement is repeatable. It may underestimate the cost of implementation. Or it may prioritize functionality that appears valuable in demonstrations but contributes relatively little to customer retention or willingness to pay.
Reliable product evidence helps management identify what is working, under which conditions, and where the limitations remain.
This becomes especially important as AI enters more operational workflows.
A prototype may perform impressively in controlled conditions while struggling with incomplete data, unusual requests, or exceptions that require human judgment.
The relevant question is not simply whether the technology works.
It is whether the complete operating process produces a better result once verification, supervision, failures, and the cost of intervention are taken into account.
That requires evidence from actual workflows, not just product demonstrations.
When documentation becomes part of operations
There is a temptation to treat these issues as a documentation problem.
If the company cannot answer an investor’s question, someone prepares a spreadsheet. If the financial picture is unclear, finance produces another report. If a product claim lacks support, the team assembles the available test results.
Sometimes that is all that is needed.
But when important information has to be reconstructed every time management asks a serious question, I think it is worth examining the operating process that produces it.
Why was the information difficult to obtain? Was it never recorded? Does it exist in several incompatible systems? Is there no shared definition? Has responsibility for maintaining the record never been assigned?
Those are operational questions.
The answer does not have to be an expensive new software platform or a large reporting initiative.
In many cases, the better starting point is to identify a small set of records that support recurring management decisions and make sure they are maintained as part of normal work.
For customer relationships, this might mean connecting account status, contract value, billing, implementation effort, and renewal history.
For financial management, it might mean linking cash forecasts to hiring plans, commercial assumptions, liabilities, and delivery capacity.
For product decisions, it might mean maintaining the evidence behind material performance claims, including the test conditions and known limitations.
The important part is not the document format. It is whether the information remains current, traceable, and useful when a decision needs to be made.
A record assembled once for a fundraising presentation has limited operating value. A record maintained through the activities of the business can become part of how that business is managed.
Evidence should influence decisions before they become expensive
One reason these gaps concern me is that their consequences are often delayed.
A company may continue growing while relying on incomplete information. Employees compensate for missing processes. Founders rely on personal knowledge. Managers make reasonable assumptions based on the information available to them.
For a time, this may work.
But as the organization becomes more complex, decisions become harder to reverse.
A hiring plan creates ongoing obligations. A pricing structure shapes the customers the company attracts. A product roadmap commits engineering capacity. Entering a new market requires coordination across functions that may already be stretched.
The cost of discovering an incorrect assumption increases as more decisions are built on top of it.
This is why I think the quality of operational evidence deserves attention before a company reaches a crisis or begins preparing for external scrutiny.
It is also why simply collecting more data is not the answer.
Management needs to know which decisions depend on which evidence, where that evidence originates, and what remains uncertain.
Some decisions will still have to be made with incomplete information. That is unavoidable, particularly in young companies. But there is a meaningful difference between knowingly accepting uncertainty and operating as though an unsupported assumption has already been established.
Building a company that can explain itself
The original screening observations were about the information available to assess investment opportunities.
What interested me more was the relationship between that information and the company being built.
A business that maintains reliable customer records can make better-informed decisions about sales, pricing, product development, and retention. A company that connects financial forecasts to operational assumptions has a clearer basis for allocating resources. A product team that understands the evidence behind its performance claims can make more disciplined decisions about what to build next.
None of these practices guarantees commercial success.
They do, however, reduce the distance between what management believes is happening and what the available evidence can actually establish.
I would not expect every startup to operate with the reporting sophistication of a mature company. The systems should be appropriate to the stage of the business. Some information will remain incomplete, and some assumptions can only be tested through further execution.
But the basic discipline matters at every stage.
A company should be able to explain not only what it intends to accomplish, but also what its operating history has taught it and where important uncertainties remain.
That is useful when speaking with investors. It is more important when deciding what to do next.
The evidence a company needs to explain itself to outsiders is often the same evidence it needs to make better decisions internally.
And when that evidence is missing, the problem may not be the presentation.
It may be part of how the business is being built.