A small B2B company may not have clean customer profitability data, reliable conversion history or consistent cost-to-serve reporting. That limits what can be quantified. It does not make the business unknowable.
Evidence may sit in project notes, customer commitments, repeated exceptions, spreadsheets, emails, CRM history, handoffs and the way experienced people actually get work through the organisation.
Data is one form of evidence
Structured data is powerful because it can quantify frequency, magnitude and change over time. But discovery often starts before the organisation has decided what should be measured consistently.
At that stage, the useful question is not “do we have the metric?” It is “what evidence exists about how this actually works?”
I do not need perfect data to start. I need evidence - and a clear distinction between evidence and inference.
A practical evidence ladder
Recorded. A document, system record or other artefact exists.
Observed. The behaviour or event can be seen repeatedly in practice.
Reported. A stakeholder describes what happens.
Corroborated. Independent people or records describe the same pattern.
Inferred. The evidence supports a plausible explanation, but does not establish it.
Assumed. The business acts as if something is true without sufficient evidence.
Unknown. There is not enough evidence yet.
Why the distinction matters
Suppose a company cannot reliably calculate customer profitability. Delivery managers nevertheless describe the same type of client as requiring repeated senior intervention, additional coordination and work outside the normal delivery path.
That is not enough to conclude that those clients are unprofitable.
It may be enough to justify measuring unplanned delivery effort by client or project type.
The discovery therefore does not replace financial analysis. It establishes where better measurement is warranted and prevents an untested explanation from being treated as fact.
What this changes in implementation discovery
A stakeholder request should not automatically become a system requirement just because it was stated confidently. The implementation team should know whether the request is supported by a record, an observed pattern, a single stakeholder account, a corroborated pattern or an inference.
That makes uncertainty visible. It also gives the future system a better job: not merely to automate the current process, but to start capturing the information the business currently lacks.
ProperBizFix works with implementation partners on account research, commercial discovery, business analysis and requirements discovery.