Felipe Soza

I work in the space between commercial strategy and the machinery that is supposed to execute it. That space is where most revenue problems actually live. The strategy deck is usually defensible. The execution layer underneath it is usually a set of tools nobody designed, connected by conventions nobody wrote down, held together by two or three people who remember how it works.

My job is to design the operating system that sits under the strategy: what decisions exist, who makes them, what states a record can occupy, how information moves between stages, what happens when an input is wrong, and how the team learns from what happened last month. Once that is designed, tooling becomes an implementation detail rather than a strategy.

I am not a strategist who hands off a document, and I am not an implementer who wires whatever is requested. Both roles fail for the same reason: they assume someone else owns the connection between intent and mechanism. Nobody usually does. That is the gap I work in.

Commercial strategy, because a system built on a fuzzy definition of the target account will produce fuzzy output at volume. Segmentation logic is a strategic artifact wearing operational clothes.

Data infrastructure, because everything downstream inherits the quality of the record. Sourcing, enrichment, validation, precedence rules between conflicting sources, deduplication, ownership and refresh cadence. Automation cannot be more reliable than its inputs.

Automation and APIs, because the handoffs between stages are where systems actually break. Most of the durable work is unglamorous: idempotent writes, retries, queues, error states that surface instead of failing silently, and integrations that degrade predictably rather than dropping records.

AI, applied as leverage on a defined process rather than as a category of activity. Classification, drafting, research synthesis, summarisation and routing are genuinely useful when the surrounding process has states and thresholds. Giving a model a broken process just means the process can now break without supervision.

Process design, because a process is not a document. It is the set of decisions a person no longer has to improvise. The measure of a good process is how much judgment it removes from the ordinary case so that judgment is available for the exceptions.

Team operations, because a system that only its architect can run is a liability. Ownership, escalation paths, review cadence, definitions everyone agrees on, and runbooks that describe the failure cases rather than only the happy path.

The specific situation I am most useful in is the one where there is no operating model yet. Revenue is happening, but it is happening through effort and memory. The company has grown past the point where individual attention can cover the gaps, and the symptoms show up as inconsistency rather than as a single visible failure. Two similar accounts get treated differently. A number moves and nobody can explain why. A new hire takes a quarter to become useful because the knowledge lives in conversations.

That is not a tooling problem and it usually is not a talent problem. It is the absence of a designed system. Building one requires deciding things that have been left ambiguous, which is uncomfortable, because ambiguity is where disagreements have been quietly stored. A large part of this work is making implicit decisions explicit and getting the people who own them to agree on the wording.

The output is not a dashboard. It is a system that a competent operator who was not part of the design can read and run, with instrumentation that explains its own behaviour, and documentation that covers what to do when the input is wrong.

Systems over tactics. A tactic is something that worked once in a particular set of conditions. A system is something that keeps producing an outcome as conditions change. Most of what circulates as growth advice is tactics presented as principles, which is why it stops working shortly after it becomes popular.

Arithmetic before opinion. Before anything is designed, I want raw exports and funnel math. Volume, conversion between defined stages, median time in stage, and the shape of the distribution rather than the average. The binding constraint is usually visible in the numbers and invisible in the conversation about the numbers.

Constraints, not improvements. A system has one limiting stage at a time. Work anywhere else produces motion without throughput. Finding the constraint is more valuable than fixing anything, and it changes after each fix, which is why diagnosis has to be a habit rather than a phase.

Leverage, not organisation. Tidying a workflow feels productive and often changes nothing. The point of a system is that one unit of input produces more output than it did before, and that the output does not depend on which person happened to be paying attention.

Skepticism about categories. New tool categories arrive faster than the problems they claim to solve. The useful question is never whether something is impressive but what decision it removes, what state it owns, and what happens when it is wrong.