The thesis
A digital opportunity is not the same thing as an idea for an app. It begins with friction: a recurring unmet need, idle capacity, information that is hard to find, or a decision made under uncertainty. The first transformation is not technological. It is the ability to describe that friction precisely enough for the claim to be tested and potentially disproved.
The thesis of this paper is that solving a problem can create a second kind of value: operational knowledge, a structured memory of the conditions in which the problem occurs, the decisions made, and their outcomes. That value does not appear automatically when data accumulates. It depends on purpose, meaningful measurement, information quality, controls, and legitimate use.
This is an exploratory conceptual study of the FT Digital Opportunity framework. It does not report field research, estimated market sizes, observed conversion rates, or demonstrated financial returns.
Friction: where value meets an obstacle
Friction is the point where value meets an obstacle. It is not limited to technical or mechanical resistance. It is the observable gap between a need and the ability to meet it, or between an available resource and the ability to put it to use. It may appear as waiting time, missing information, avoidable complexity, difficult decisions or idle capacity.
Consider, as an illustration, a restaurant with empty tables while some people are looking for somewhere to eat. We cannot immediately conclude that the answer is an app or a discount: the obstacle may involve visibility, opening hours, pricing or a mismatch between demand and supply. Observation is needed to determine which explanation is plausible.
To recognise friction, ask who encounters the obstacle, when it occurs, what consequences it has and how people currently work around it. Friction can be genuine without being sufficiently frequent, solvable or commercially viable. Not every friction becomes an opportunity: its nature and cost must first be tested.
1. From a problem to a testable question
A designer may say: “People struggle to find a reliable service when they need one.” That is a plausible intuition, not yet evidence. To investigate it, we need to specify the person, context, and observable behaviour.
A more useful question is: under what conditions does someone seeking an urgent service abandon the request, which information is missing, and what happens afterwards? This opens up interviews, process events and comparisons without preselecting the answer.
Five elements should be kept distinct: the stated problem, the observed behaviour, the cost of friction, the existing alternative, and the willingness to change. A common need does not necessarily create a paying customer. Technological feasibility does not establish commercial sustainability.
2. Six steps towards a verifiable trace
Friction → Hypothesis → Experiment → Event → Evidence → Decision.
This sequence is an exploratory proposal, not a scientifically validated method. The Trace Method is a possible working title, not a final name. Here, a “trace” does not mean just any data point: it means a record linked to its context, an action and its outcome, so that it can be reconstructed, checked and, if necessary, challenged.
Friction. Record what appears not to work, for whom, where, and with which consequences. Keep description separate from interpretation.
Hypothesis. State the proposed mechanism: “if information X is available at moment Y, some requests may be easier to complete.” The opposite outcome must also be observable.
Experiment. Design a bounded test: a prototype, an assisted workflow, a structured interview, or a before/after comparison. The purpose is to reduce meaningful uncertainty, not to prove an idea right at any cost.
Event. Record what actually happened, rather than what the team hoped would happen. Events require stable definitions: a request started is not a request completed.
Evidence. Interpret the observations with due regard for data quality, sample limits, alternative explanations and bias. An observed association must not be presented as proven causation.
Decision. Close the experiment with a documented choice: continue, change direction, investigate further, or stop. Rejecting a hypothesis can still create valuable knowledge.
The OECD/Eurostat Oslo Manual provides an important reference for defining and working with innovation data. The sequence described here is, however, an operational proposal that still requires validation, not an official procedure taken from that manual.
3. From records to operational memory
An isolated event says little. To become reusable knowledge, it should connect at least the context, problem, action, outcome, observation time, provenance, and degree of confidence.
Consider a hypothetical technical-service request. A minimal record might indicate that the customer described the issue, clarification questions were asked, a solution was proposed, and the work was either completed or not completed. This example is illustrative only; it does not represent a real dataset, and no numerical outcomes are invented.
Given enough comparable cases collected legitimately, a designer could investigate which information helps to choose an appropriate course of action. One episode does not warrant generalization. Without denominators, definitions, missing-value controls and outcome verification, persuasive-looking metrics may still be misleading.
Ikujiro Nonaka’s distinction between tacit and explicit knowledge offers a useful theoretical lens: translating experience into shareable descriptions is work in its own right, not an automatic by-product. James G. March’s distinction between exploration and exploitation helps explain the competing demands of discovering new possibilities and refining known processes.
4. When knowledge contributes to advantage
The relevant value is not the number of rows stored but the possibility of making more accountable decisions. Operational memory may help improve procedures, make constraints explicit, explain choices, or identify the next experiment.
Yet there is no automatic progression from “more data” to “more revenue.” The ability to capture value may depend on distribution, relationships with operators, skills and complementary assets. David J. Teece explored that broader problem of value appropriation in technological innovation.
Three distinctions therefore matter: collected data is not necessarily trustworthy knowledge; trustworthy knowledge is not automatically competitive advantage; and competitive advantage does not demonstrate financial return.
5. Interoperability is a possibility, not permission
Different digital products may learn from their own workflows. Comparing definitions, aggregated patterns or evaluation methods may be useful. But different systems must not automatically pool personal or confidential information.
Any future interoperability requires an appropriate legal basis, defined purposes, data minimization, clear responsibilities, access controls, and risk assessment. Technical interoperability does not override legal obligations or the need for consent when applicable. In many settings it is sufficient to share common schemas or aggregated findings rather than individual records.
AI can support classification, retrieval or recommendations, but must not silently convert a prediction into a fact or make consequential decisions opaque. Generated outputs remain propositions to check, challenge and correct.
6. A protocol for initial validation
A sensible starting point is a narrow pilot on one operational process, rather than a network of products. The protocol should establish:
- Unit of analysis: which event qualifies as one case.
- Decision question: which concrete choice needs improvement.
- Event vocabulary: the meaning of start, completion, withdrawal, error and outcome.
- Traceability: the source and time of each observation; separate reports from verified events.
- Quality: missing values, duplicates, anomalies, sample limitations and dispute mechanisms.
- Protection: only necessary data, limited retention and appropriate access.
- Comparison: a criterion fixed before the test for deciding whether the intervention helped.
- Final decision: continue, reformulate, replicate or stop.
Quantitative thresholds must be specified later, after actual scoping, rather than invented for this paper. No causal improvement is claimed without a suitable evaluation design.
Conclusion
A digital opportunity should not be assessed only by asking, “what product can we build?” We should also ask, “which decision will we be able to make better after using it, and how will we show that?”
A platform can solve a problem. A well-designed system may also retain a reliable record of how it approached that problem. Only when that record is relevant, trustworthy and properly governed can it become an operational asset.
Ideas are not enough. We need traces. And a trace becomes evidence only when it is placed in context, checked and interpreted.
Publish the thesis. Show the method. Label uncertainty.
References and scope
Bibliographic details were checked against publisher and institutional records: OECD/Eurostat (2018); Nonaka (1994); March (1991); Teece (1986). These works provide theoretical and methodological context, not empirical proof that the FT framework is effective. All operational examples are illustrative; no primary data were collected for this paper.