Deciding which products to build

We start with work that people already need to do. The problem should not begin with a desire for “more AI” or “more automation.” It should begin with a recurring workflow in which people lose time, miss opportunities, reconstruct context, or make weaker decisions because understanding the companies involved is difficult.

We learn this by speaking with the people who perform the work. We want to understand where the problem occurs, how often it occurs, what teams do today, what happens when they get it wrong, and whether the problem is important enough to change how they work.

A revenue team may repeatedly struggle to determine which companies deserve attention. A partnerships team may need to determine where two companies actually fit together. A team responding to an RFP may need to connect buyer requirements with evidence-supported capabilities. Another team may have an entirely different objective. The first question is therefore simple:

Is there a real problem here even without ASUME?

If the problem exists only because a new technology makes it possible to build something interesting, it is probably not where we should start.

Not every workflow that involves companies requires ASUME. A workflow becomes especially relevant when the quality of the outcome depends on understanding the state of one or more companies: their needs, capabilities, constraints, priorities, relationships, direction, or other characteristics that cannot be retrieved reliably from a single field or source. Some problems can be solved with a database lookup, deterministic rule, form, template, or generic generation. Adding another inference system would only make those workflows more complicated.

ASUME becomes useful when the task requires reasoning across fragmented information, distinguishing evidence from assumptions and claims, maintaining company state over time, and applying that understanding to a specific objective.

The main test is:

Would a better understanding of the company materially improve the result?

If the answer is yes, the objective belongs naturally on top of the ASUME understanding layer.

An objective does not automatically need a dedicated product experience. Some objectives may be handled through Ask ASUME, an API, an agent, or another general interface. A user defines what they want to accomplish, ASUME applies the relevant company understanding, and the result is returned without requiring a specialised workflow. Other objectives occur frequently enough that a dedicated experience creates additional value.

A revenue workflow, for example, may benefit from portfolio-level discovery, prioritisation, evidence review, collaboration, monitoring, and actions designed specifically around revenue decisions. These capabilities can make the objective substantially easier to execute than expressing every step as a new request.

We therefore separate two questions:

Can ASUME reason about this objective?

and

Does this objective deserve its own product experience?

The first is about the understanding layer. The second is a product decision. Products are interfaces to ASUME's understanding, not the boundary of what ASUME can understand.

A meaningful problem and a suitable objective are still not enough to justify building a dedicated product around them. We look for evidence that the people experiencing the problem care enough to change something.

Commitment may appear as willingness to pay, invest time, share domain knowledge, connect relevant information, test early versions, replace an existing process, or repeatedly use the resulting output.

Interest is different from commitment. Many ideas sound useful when described. Fewer problems are important enough for people to change an established workflow around them. When pain, understanding, and commitment come together, we start narrowly. We build the smallest objective-specific experience that allows us to determine whether better company understanding actually produces a better outcome.

Revenue is the first major application of this approach because revenue teams repeatedly need to understand which companies matter, why they matter, where an opportunity may exist, and what evidence supports acting on it.

Every objective-specific product also teaches us something about the understanding layer itself. A revenue workflow may reveal the need for better portfolio comparison. A partnerships workflow may require stronger company-to-company reasoning. A risk objective may require more explicit treatment of conflicting evidence. Agent workflows may require better monitoring, objective definition, evidence-gap resolution, or controlled external actions. When the same capability becomes useful across several objectives, it should no longer belong to one product. It becomes part of ASUME itself.

This is how the system can evolve from a set of opinionated product experiences into a more general understanding layer.

In the future, a user or agent should be able to define an objective that ASUME has not seen before, apply maintained company understanding to it, determine what additional evidence is needed, produce an objective-dependent result, and use that result within a broader workflow.

The direction is:

Company information → company understanding → objective → action.

Models and agents are becoming increasingly capable of reasoning and acting. ASUME is built around the layer they still need in between: a persistent, structured, traceable, and revisable understanding of the companies they are acting on.

That is the longer-term role we are building towards: ASUME as the understanding layer for the agent economy.