3. Solution Creation Process

Solutions Catalog Governance and Development

Overview

The Solutions Catalog is not just a list of offerings. It is the structured portfolio through which WillDom defines what it is able to bring to market as a repeatable, governable, and scalable solution. Within the broader Solutions Engine, the catalog plays a central role: it is the layer where strategic intent, market signals, network capabilities, and operating decisions are translated into a curated set of official solution offerings. In that sense, the catalog is both a commercial asset and a governance mechanism. It defines what WillDom is prepared to offer, what has been validated, and what has enough strategic and operational consistency to be activated by branches across the ecosystem. Additionally, the Solutions Catalog is managed and made accessible through Wave, where it serves as the central source of truth for all approved solutions.

This section explains how a solution enters the system, how it is analyzed, how it is developed or incorporated, how it is launched, and how it is ultimately either consolidated into the Solutions Catalog or removed from it. The purpose of this process is to avoid ad hoc solution creation and instead ensure that every solution in the catalog emerges from a deliberate evaluation of strategic fit, market relevance, ecosystem feasibility, and performance. The catalog must therefore be understood as a living portfolio, not as a static repository. Solutions can be proposed, developed, adapted, tested, kept, expanded, or eliminated depending on how they perform and how well they align with WillDom’s strategic direction.

At a high level, this process connects three dimensions. First, there is the solution intake layer, where ideas, opportunities, and strategic inputs are collected and translated into a structured backlog. Second, there is the solution creation path, which determines whether a solution should be built internally through the network or incorporated through expansion and external capability development. Third, there is the solution validation and catalog governance layer, where launched solutions are evaluated based on performance and either retained as official catalog offerings or removed. This gives WillDom a disciplined model for expanding its solution portfolio without losing coherence.

Purpose of the Solutions Catalog

The Solutions Catalog exists to provide a single, official reference of the solutions that WillDom can offer to the market. In practical terms, it establishes a common commercial language across branches, reduces ambiguity during pre-sales, and creates a shared understanding of what offerings are recognized, supported, and ready to be activated. The handbook already defines the catalog as the place from which branches can offer official solutions, and this governance process explains how a solution becomes eligible to live there in the first place.

However, the catalog is not intended to be merely descriptive. It is also selective. Not every idea, request, or branch preference should automatically become a catalog solution. If that were the case, the catalog would quickly lose strategic focus and operational usefulness. The function of catalog governance is precisely to make that selection explicit. It helps WillDom distinguish between a genuine, reusable solution and a one-off request; between a strategic capability and a temporary opportunity; between a solution that should be institutionalized and one that should remain outside the official portfolio. This makes the catalog a mechanism for portfolio discipline as much as for commercial enablement.

Because WillDom operates as an ecosystem rather than as a traditional linear company, catalog governance also serves another critical purpose: it allows the organization to orchestrate capabilities across branches and partners in a consistent way. A solution in the catalog is not simply “something a branch can do.” It is something that WillDom, as a coordinated system, is prepared to position, support, and eventually deliver under a repeatable model. That is why the intake, validation, development, and performance-review stages are essential.

The sources of input for new solutions

We recommend that you take a look at the Solution’s engine process first .

The process begins with what the workflow identifies as the solution’s input catalog. This is the upstream layer from which potential solutions emerge. According to the workflow, the primary inputs are the strategic plan, market trends, and complementary offer. These three sources matter because they ensure that solution creation is not random. Instead, it starts from a combination of internal strategy, external demand signals, and adjacency logic.

The strategic plan represents the intentional direction of the company. It answers the question of where WillDom wants to play, what types of value it intends to create, and what capabilities it wants to strengthen over time. A solution that emerges from the strategic plan is usually one that supports a long-term positioning objective. It may respond to a target vertical, a desired transformation capability, a differentiation strategy, or a broader portfolio thesis within the ecosystem. In other words, these are solutions that are not only commercially relevant, but strategically meaningful. This is particularly important in the WDOS context, where Solutions is positioned as one of the core business engines and where WillDom’s evolution is described as a move from staffing toward more outcome-oriented and transformation-driven offerings.

The second input is market trends. This input captures what the market is asking for, where demand is growing, what clients are prioritizing, and which categories of solutions are becoming more valuable or more urgent. A market-trend-driven input may come from repeated client conversations, shifts in technology adoption, emerging industry priorities, or recurring signals detected by branches and solution leaders. This input is critical because it prevents the catalog from becoming disconnected from real market demand. A strategically elegant solution that no client is looking for has limited value; the catalog must remain grounded in opportunity.

The third input is the complementary offer. This refers to opportunities that are adjacent to what WillDom already knows how to do, what it is already selling, or what clients already associate with its value proposition. Complementary offers are especially important because they often represent the most natural and scalable path for expanding the catalog. They build on existing relationships, capabilities, or solution families, which usually makes them easier to position, easier to operationalize, and faster to validate commercially.

These inputs do not directly become solutions. They first feed the Solutions Backlog. The backlog is the staging area where all potential solutions are collected, organized, and made visible for evaluation. It is the portfolio funnel before formal validation. Its purpose is to ensure that solution ideas are not lost, but also that they are not prematurely formalized. The backlog is where the ecosystem can accumulate opportunity signals before deciding whether each idea should move forward.

Branch-driven requests and alignment with the catalog logic

In addition to top-down or market-driven inputs, the workflow also includes a branch-originated trigger: “Branch wants to offer a solution.” This is an important distinction. Sometimes the push for a new solution does not begin with the formal strategic layer, but with a branch that sees an opportunity, has access to a capability, or wants to bring a new offering into the ecosystem.

The process does not automatically accept that request. Instead, the first question is whether the proposed solution is aligned with the solution’s input. This is a critical control point. It means that even when a branch has commercial enthusiasm or technical capability, the solution still needs to be tested against the broader logic of the portfolio. Is it aligned with strategy? Does it respond to a market trend? Does it complement the existing offer? Does it fit the direction WillDom wants the catalog to take?

If the answer is no, the process ends there. This does not necessarily mean the branch’s idea lacks value in absolute terms. It means it should not be incorporated into the official Solutions Catalog at that time. This distinction is important because it protects the catalog from fragmentation. It keeps the official portfolio focused and avoids turning every branch-level initiative into a system-wide commitment.

If the answer is yes, the opportunity is routed into the formal solution backlog and enters the same governance path as any other potential solution. This reinforces a key principle: branches are allowed to contribute to portfolio growth, but portfolio inclusion remains governed by shared criteria rather than by individual initiative alone.

From backlog to evaluation: determining whether there is a new solution

Once an item is in the backlog, the next decision point in the workflow is whether it actually represents a new solution. This may seem obvious, but it is a necessary analytical distinction. Not every backlog item is necessarily a new solution. Some may be variations of an existing one, extensions of a current capability, packaging improvements, or commercial refinements rather than genuine additions to the portfolio.

This stage should therefore be understood as a framing exercise. The organization must ask: are we looking at something genuinely new, with distinct value proposition, scope, and positioning, or are we simply encountering a new expression of something we already have? This step matters because it determines whether the process should move toward solution creation or whether the idea should be absorbed into an existing catalog structure.

If the answer is no, the workflow does not continue into a full development track. The opportunity is effectively stopped as a net-new catalog initiative. Operationally, this means the idea may still inform packaging, positioning, or refinement of existing offers, but it does not trigger the process for creating a distinct new solution.

If the answer is yes, the workflow continues to a second, more structural question: can this solution be developed by the network?

The core build-or-expand decision

The decision point “Developed by the network?” is one of the most important moments in the entire governance process. This is where WillDom determines whether the solution can be created and matured internally using the capabilities that already exist across its branches, leaders, and ecosystem participants, or whether the solution requires an external capability expansion path.

This is not merely a question of technical feasibility. It is a broader ecosystem question. It asks whether the network has enough expertise, leadership, delivery maturity, and strategic ownership to turn the idea into a real, repeatable offering. A solution may be conceptually attractive and commercially relevant, but if the current ecosystem cannot credibly design, deliver, and support it, then internal development may not be the right path.

If the answer is yes, the solution enters the Solution Hub Development Process. This means WillDom believes the network itself can create the offering.

If the answer is no, the solution moves into the Expansion Process. This means WillDom sees the solution as valuable and aligned, but concludes that the required capability needs to be brought into the ecosystem from outside or built through partnership and expansion rather than solely through current internal resources.

This separation is strategically powerful because it allows WillDom to grow the catalog in two ways: by cultivating what it can create from within, and by deliberately importing or co-building what it does not yet have.

Solution Hub Development Process

When a solution is considered developable by the network, it enters the Solution Hub Development Process. This is the internal innovation path through which WillDom turns an idea into a formal market-ready solution offering.

The process begins with the Solutions Backlog, which is the entry point into this path. Once prioritized, the solution moves through a structured progression: Design, MVP, Implementation, and Marketing Assets.

The Design stage is where the solution is conceptually defined. This is the point at which the value proposition, use cases, target client profile, scope boundaries, operating assumptions, and core commercial narrative should be clarified. The goal of design is not only to say what the solution is, but also to make it coherent enough that it can be communicated, tested, and eventually delivered. In governance terms, design is where a raw idea becomes an intentional solution architecture.

The next stage is MVP. This stage is critical because it introduces a practical threshold: WillDom should not aim to fully institutionalize every solution before testing whether the offer works in reality. The MVP stage allows the organization to define the smallest credible version of the solution that can be validated. This may include a simplified service structure, a first commercial package, a pilot scope, a first methodology draft, or a lightweight delivery model. The purpose is to reduce uncertainty before scaling.

The process then moves into Implementation. At this point, the solution is no longer just a concept or pilot package. It starts becoming operational. Implementation involves transforming the MVP into something repeatable and executable, with clearer delivery logic, stronger internal alignment, and more robust operational readiness. This is where the solution begins to resemble a true portfolio asset rather than an exploratory initiative.

After implementation, the workflow includes Marketing Assets. This is a highly important signal in the model. A solution is not considered mature only when it can technically be delivered; it also needs to be marketable. Marketing assets make the solution legible to the ecosystem and to potential clients. They support enablement, positioning, pre-sales consistency, and internal understanding. Without this step, a technically valid solution may still fail to become a true catalog offering because it cannot be effectively activated across branches.

From there, the flow connects directly into the Solutions Catalog. This means that once the internally developed solution has reached a sufficient level of readiness, it becomes part of the official portfolio.

This path should be understood as WillDom’s internal solution-building capability. It is how the ecosystem turns knowledge, expertise, and strategic direction into reusable offerings that can later be sold and delivered under a shared model.

Expansion Process

When a solution cannot be developed by the existing network alone, the workflow routes it into the Expansion Process. This path is designed for cases where the opportunity is attractive and strategically valid, but the required capability does not yet fully exist inside WillDom.

The process starts with Operation Requisitions. This is the formal recognition that a capability gap exists and needs to be addressed through ecosystem expansion. In other words, the company is not just evaluating a solution; it is evaluating the need to expand the operator base that can support that solution.

The next step is Introduction. This is the first structured contact with a potential external operator, expert, partner, or capability source. At this stage, the objective is exploratory: to understand whether there is enough mutual fit to continue the process. This is less about commitment and more about screening the possibility of collaboration.

The process then moves into Vetting. This is where WillDom evaluates the external party more rigorously. Vetting should be understood as a multidimensional assessment of capability, credibility, quality, delivery maturity, cultural fit, and alignment with WillDom’s standards. Since a future catalog solution may eventually depend on this capability, the vetting stage is essential for protecting brand consistency and delivery quality.

Next comes Partner Selection. By this stage, the organization has decided that the external party is worth moving forward with. However, selection is not yet equivalent to full integration. It is the choice of the preferred operator or partner with whom WillDom wants to explore solution-building further.

After partner selection, the workflow moves into Co-create the solution. This is a meaningful step because it shows that expansion is not framed as a mere outsourcing exercise. WillDom is not simply “buying” a capability from outside. It is co-creating a solution with that operator, which implies translation into WillDom’s framework, joint shaping of the offer, and alignment with how the ecosystem packages, governs, and eventually sells solutions.

Once the solution has been co-created, the workflow moves into Explore opportunities. This indicates that the solution still needs to be validated in practical commercial terms. It is not enough to design the offering with a partner; the ecosystem must also test whether the solution can perform in the market.

This leads to the decision point “Performing OK?” If the answer is no, the operator is not elevated further in the system. Instead, the workflow indicates “Keep that operator as a partner.” This is a very nuanced and useful governance outcome. It means that underperformance in this particular expansion path does not necessarily invalidate the relationship. The operator may still remain useful as a partner, but not as the basis for branch-level capability institutionalization.

If the answer is yes, the process advances to a second decision point: “Ideal PPP?” Although the acronym is not expanded in the visual, the logic of the flow is clear: WillDom is testing whether the operator represents the right profile for deeper integration into the ecosystem. This is a more strategic filter. It is not only asking whether the partner can perform, but whether that partner embodies the right profile for becoming part of the branch structure.

If the answer is yes, the workflow leads to Branch. This means the partner is elevated from an external or semi-external operator into a fuller ecosystem structure. From there, the capability can feed into the official solution architecture and catalog.

If the answer is no, the result is again “Keep that operator as a partner.” This confirms that the model distinguishes clearly between two types of successful external relationships: those that should remain partnerships, and those that are strong enough and strategically suitable to become branches.

This expansion path is especially important in the WDOS logic because WillDom is conceived as an orchestrated ecosystem, not just as a closed organization. The company grows not only by building internally, but also by selectively incorporating external capability into the system when that creates strategic advantage.

Adapting the solution to WillDom

Whether the solution comes from external expansion or from a capability that needs formal integration into the ecosystem, the workflow includes a critical step: Adapt the solution to WD.

This is one of the most important governance moments in the process. A capability does not become a WillDom solution just because it exists or because an operator can deliver it. It needs to be translated into WillDom’s language, standards, portfolio structure, and operating model. This means adapting the offer so that it is not simply “a service that someone in the ecosystem can do,” but a solution that WillDom can consistently position and activate.

Adaptation to WillDom should include, at minimum, alignment in value proposition, delivery framing, commercial narrative, operational expectations, governance logic, and catalog structure. The point of this step is standardization without killing flexibility. WillDom wants to preserve the strength of specialized operators while still ensuring that the final offer behaves like part of a coherent system.

Without this adaptation step, the catalog would quickly become a fragmented aggregation of disconnected external offers. With it, the company creates an official portfolio rather than a marketplace of unrelated capabilities.

Launching the solution

Once the solution has either been developed through the Solution Hub path or adapted through the Expansion path, the next step is Launch the solution.

Launch is the moment when the solution stops being an internal concept and becomes a live offering. This does not necessarily mean full maturity or permanent catalog status. Rather, it means the solution is now active enough to be introduced into the market, tested in practical conditions, and observed through real performance.

A launch should therefore be understood as both a commercial and governance milestone. Commercially, it makes the solution available for activation. From a governance standpoint, it opens the observation period in which WillDom can determine whether the solution truly deserves to remain part of the portfolio.

This is an important distinction: launch is not the end of validation. Launch is the beginning of validation under real conditions.

Evaluating solution performance

After launch, the workflow moves to Evaluate the solution performance. This confirms that WillDom does not consider catalog inclusion to be automatic or irreversible. A solution must prove itself after entering the market.

Performance evaluation should be understood broadly. It is not limited to revenue alone. A solution may need to be evaluated based on client traction, sales usability, delivery repeatability, ecosystem readiness, quality of execution, strategic relevance, and overall contribution to the portfolio. A solution that is conceptually strong but commercially invisible, operationally difficult, or strategically distracting may not deserve long-term place in the catalog.

This leads to the key decision point: “Is the performance OK?”

If the answer is yes, the workflow continues to Keep the solution, and from there into the Solutions Catalog. This confirms that the solution has met the threshold required to become or remain an official portfolio asset. At this point, the catalog is not functioning as a draft repository anymore; it is recognizing the solution as a validated, governed offering.

If the answer is no, the workflow leads to Eliminate the solution, and then to End. This is a healthy governance rule. It prevents the catalog from accumulating low-performing, low-priority, or non-strategic solutions simply because they were once launched. Elimination should not be seen as failure in a negative sense. It is a portfolio discipline mechanism. It allows WillDom to experiment, learn, and refine its offer without cluttering the official catalog with offerings that do not justify continued investment.

This keep-or-eliminate logic is one of the clearest signs that the catalog is managed as a strategic portfolio rather than as an archive.

The Solutions Catalog as an output, not as a raw input

One of the most important conceptual points in this entire model is that the Solutions Catalog is an output of governance, not just a starting list of ideas. The workflow makes clear that solutions arrive in the catalog through deliberate paths: either through internal hub development, through ecosystem expansion and adaptation, or through successful launch and performance validation.

This matters because it changes the meaning of the catalog. It is not simply “everything we could theoretically do.” It is the set of solutions that have passed through WillDom’s portfolio logic. They are aligned with strategic inputs, shaped through an intentional process, and retained only if they demonstrate sufficient value.

That is exactly what gives the catalog its usefulness as the official source of solutions that branches can offer. It makes the catalog trustworthy, because inclusion implies validation.

Governance principles behind this process

Several important governance principles are embedded in this workflow.

The first is strategic alignment before portfolio inclusion. A solution should not enter the catalog only because someone can deliver it. It must align with the strategic plan, market trends, or complementary offer logic.

The second is branch initiative with portfolio discipline. Branches can propose or push for solutions, but those solutions must still pass through shared filters and cannot bypass the catalog logic.

The third is dual growth logic. WillDom can expand its solution portfolio in two ways: by building solutions internally through the network, or by expanding the ecosystem through vetted partnerships and capability incorporation.

The fourth is adaptation before institutionalization. Even when a solution originates outside the current network, it must be translated into WillDom’s operating model before it becomes part of the official offering.

The fifth is performance-based retention. Launch does not guarantee permanence. Solutions remain in the catalog only if their performance justifies it.

Together, these principles ensure that the catalog remains coherent, strategic, and operationally credible over time.

Closing statement

The Solutions Catalog should be understood as a governed portfolio of validated offerings, not as a loose list of capabilities. The process described above ensures that each solution is born from meaningful inputs, assessed against strategic and market criteria, built or incorporated through the right path, adapted to WillDom’s standards, launched intentionally, and retained only when its performance justifies continued place in the portfolio. By managing the catalog this way, WillDom strengthens the consistency of its commercial offer, improves ecosystem coordination, and reinforces the role of the Solutions Engine as a true business engine within the operating system.