Alpha of commercial opportunity ​

Describing the concept of transitioning from needs (what we want from the supra system if we include an unknown target system) to describing the target system with its usually unknown properties at the beginning of the project is challenging; it essentially involves inventing: proposing such an affordance for the construction of the supra system for a known need in a function within this supra system as a "transparent box" as the target system. For example, our target system should serve as a "hammer" for nails in some supra system (carpentry workshop). We go to the "market" and look for what could serve us - a microscope is expensive, a stone is fragile and inconvenient, pliers are too light to transfer energy to the nail. Okay, let's use something heavy and easy to hold (pliers are good, but they need to be weighed down). Let's call it a "hammer": the hand interacts with the heavy hammer, accelerating it, and the energy is then transferred to the nail, driving it into the board. Let's add a scenario: we are not hitting a nail, but something fragile to break. For the nail, a flat surface is needed for easier access, and for breaking, the same principles apply, but it would be good to have a small surface area upon impact, allowing more energy to be transferred through a smaller area. So, we need a heavy object (presumably metal) with large and small areas, set in motion by hand. And it will be not only a "hammer" in the workshop but also a "breaker" when needed.

This idea appeals to two companies. They come up with more or less the same system concept (a heavy metal part equipped with a convenient wooden handle). But one company specializes in the "hammer" function (not excluding the ancillary "breaker" function) and calls their product a "hammer" with a flat striking face and a sharp wedge in the hammer head:

The other company focuses on the "breaker" function and enters the market with an "axe", where the wedge is made thin (the blade) and further sharpened to create a blade with minimal area, while a sledge is used for the "breaker" function:

The "simple" problem of proposing a system lies in the fact that for a clear set of functions of the system (referred to a known system conception), its construction from subsystems needs to be offered (synthesize the concept of each subsystem, and so on to multiple levels down). In the case of needs, constructive solutions are not usually obvious; rational assumptions must be made about them, and then a system concept (at least at the idea level) that could meet the usage concepts must be proposed. This work interlaces two unknown probable (entrepreneurial hypotheses!) descriptions of two different systems (a supra system with a usage concept and a target system with a system concept) and eliminates different unacceptable options like a wild goose chase (suggesting a usage concept is easy, suggesting a system concept is not) or cheap ("it shouldn't cost more than a plane ticket, otherwise our marketing department objects!") passenger transport to Mars. This also rules out the option of "our engineers have made Glukla, it is very cleverly designed and makes funny sounds (giggles) when rotating in water, now we don't know where to use it - where could such a service be useful? Nobody knows where such a function is needed?".

While ensuring the minimum number of types of descriptions in the usage concept for the supra system as a transparent box (functional, constructive, placement/composition, cost-related), avoid stating the obvious, widely known truths - such as "the system should be inexpensive". This can be tested by replacing the system's name with "shoes". For example, if "Glukla should be inexpensive" is stated - "shoes should be inexpensive". This sounds good and does not lead to ontological quibbles. Therefore, it means that a well-known truth has been stated, which can be left unsaid, "thanks, Captain".

In any case, let's reiterate one more time (as all students ask this question ten times): there is no algorithm for formulating an entrepreneurial hypothesis as a project idea; it is purely a creative act. It is like the "search for affordances in a niche", as design specialists say following biologists (and affordance is a synonym for opportunity, in Russian, it will all be "opportunities").

The Alpha of a commercial opportunity is essential for tracking throughout the project the feasibility of the execution/modification of the target system, the possibility of its implementation not vanishing during the project - assuming that the system will continue to evolve. The target system will be developed, manufactured, used, and constantly evolve/modernize during this time only if:

• Someone needs it, and they can pay for it - there is a requirement that can't be met without the target system, and they are willing to pay a reasonable fee (today, this usually means not only paying once but also funding development).
• Some org-unit (individual, team, enterprise, production cooperative) can create the system and further develop it for a reasonable fee.

It may be argued that not all projects are related to commercial opportunities (e.g., political projects), but this is not the case. If there is no money to feed the team, the team will not work - they will engage in other activities to survive. If people work without demanding payment and even pay for the work of their equipment (including computers and communication), it means that they are paying for it themselves (as they hold a dual role: members of the project organization and external project roles). Here we are talking about roles, not specific individuals. This is important because in "non-commercial projects," the feasibility still needs to be evaluated, resource needs determined, and a "commercial/resource/business opportunity" planned. Therefore, caution is needed: for example, if you are assisting the hungry in Africa, the clients::"external project roles" are the sponsors/donors, and the beneficiaries::"target system"! The clients are not the hungry ones but those who pay for their satiety! The hungry are the beneficiaries, not the clients of charity! And if there are no benefactors, but many people are hungry, then there is "no commercial opportunity to feed someone," and the project does not exist. One must be very attentive when discussing the Alpha of a commercial opportunity in "non-commercial projects"! Such discussions often involve very counterintuitive reasoning. For example, if you want to start a small war as a project, some people may think that your project will not bring profit but loss to them, and they will be willing to pay money, other resources, or their own labor to prevent your project, resulting in a resource-based collapse at the end of a "minor victorious war". This applies regardless of a hot war, a cold war, or a trade war. The Alpha "commercial opportunity" is about whether the project will be feasible or not; it should not be forgotten during the entire project (like all the others). And remember, it needs to be monitored throughout the project: systems are not only created in their first version as MVPs, but they continuously develop, participating in techno-evolution.

The Alpha of a commercial opportunity is mainly addressed by the following roles (which are discussed in detail in the System Management course in the sections on strategizing):

• The Visioneer in the target system engineers' team - he/she ensures that the commercial opportunity is not missed, evaluates the future: assesses whether system development provides an opportunity to generate income from product sales.
• The Business person in the management team - they ensure that realizing this commercial opportunity does not lead to a decrease in the firm's value (for example, the project may not align with the firm's strategy, investors may believe the firm will decrease in value due to reputational risks, etc.).

The Alpha of a commercial opportunity is a crucial Alpha (if there are no resources available for the project, the team should not undertake it, even if they are very eager), like all Alphas, it changes its states (including rolling back states!) throughout the project. Engineers of the target system and even managers often forget about this Alpha right after signing a contract, "come back in a year and a half when the system is ready" (often, it's a contract for producing one version of the system, based on outdated "requirements"), and this is often a fatal mistake. The opportunity to execute the project can disappear during the project execution but the project organization continues to expend resources on creating the target system, which in the end turns out to be completed in the first version but not financially justified, as the commercial opportunity for a profitable project had vanished long ago.

This is one of the most intricate Alphas; it reflects the interdependence of decisions made by various project roles, both internal and external. It is significantly tied to time: the market situation changes each day, and so does the development environment. Therefore, the state of the Alpha of a commercial opportunity must be assessed frequently.

The state of the Alpha of a commercial opportunity can be characterized by a variety of documents: a "business plan," a "concept," an "investment rationale/investment memorandum," a "project budget," a "market research report," a "project proposal," etc. These documents, in turn, reflect the state of the "usage concept," the "system concept," various models developed during the strategizing (three such models are thoroughly analyzed in the System Management course - a business model, an org-development model, and a goal-setting model). So, the Alpha of a commercial opportunity can have a range of different sub-Alphas, each belonging to different other Alphas.

The commercial viability of a project execution is an active initiative; entrepreneurship is essentially the prediction of the future, pure inventiveness. The methods/practices for working with this Alpha are hardly formalized; here, it is rather fundamental thinking "from first principles" that prevails - as it is about solving problems never encountered before and often in obscure subject areas that do not exist yet (if the company is the first to enter the market in hopes of capturing it before competitors arrive). Working with this Alpha primarily involves the ability to foresee the future, based on excellent generative models, i.e., the best general understandings of the world's structure (in particular, our fundamental courses in the intelligence stack provide such a model, the meta-meta-model of the world - an abstract multi-level description).

Throughout the project, the Alpha of a commercial opportunity passes through the following states/milestones, but they need to be understood not just as milestones in releasing the first version of the system (often this is MPV, a minimal viable product) but also as increments in enhancements - some new features of the system, some modernizations of the system itself, improving its ability to meet needs, be an affordance in a niche addressed by external project roles^[1]:

• Identified: the idea is found; at least one executor of a project role willing to make an investment in understanding the commercial opportunity is found; other project roles are identified.
• Solution needed: needs are identified; problems and their causes are determined, there is a usage concept; the target system/solution is approved by external project roles as needed, at least one system concept variant approved by internal project roles is proposed.
• Value established: the value^[2] of project realization was quantitatively determined; the impact of the solution/system on external project roles is clear; the benefit of the system is understood by external project roles; success criteria are known; results are clear and expressed quantitatively.
• Viable: the target system is feasible considering all known constraints; risks are acceptable and manageable; the project is profitable; reasons for creating the target system (or its increment/features/modernizations) are understood; it's clear that the project is viable as an implementation of a commercial opportunity.
• Addressed: the commercial opportunity is addressed; the target system is put into operation; external project roles are satisfied.
• Benefit accrued: the project has brought benefits; the return on investment is acceptable.

Each state of the "opportunity" Alpha is verified by passing the checklist mentioned above and is evidenced by artifacts (documents of various models reflecting the supra system, target system, and systems in the creation chains), but we will not cover these details in our course. This is the subject of system engineering and system management, separate courses.

The commercial opportunity Alpha does not move itself; the commercial feasibility does not reveal itself; project initiatives do not lead to commercial success by themselves. "Mad inventors" undertake crazy projects, but these projects often do not result in profit; there is no work with the Alpha of a commercial opportunity! The commercial success attribute of a project is quite slow to transition to the state of "benefit accrued"; often taking several years. Persistent project team effort is required for this transition, conducted according to some method's practices, including working with the opportunity Alpha and using the foundational thinking practices (transdisciplines supported by modelers) from the intelligence stack (physics, ontology, rationality, research, ethics, rhetoric, methodology, system engineering among them), as well as the organization's need to structurally formalize the project (systems management).