Pre-Module / Module 0 | Decision Framework

Before you build a partner strategy, decide whether partnership is even the right answer.

Most companies do not have a partnership problem first. They have a decision problem first.

This page sits before PROS. It exists for the upstream question teams usually skip: should this be built, bought, or solved through partnership at all? PROS assumes that decision has already been made. This framework helps leadership make that call with more rigor, better economics, cleaner sequencing, and less self-deception.

If the answer is partner, the next step is Module 01. If the answer is build or buy, the right move is not to force a partnership motion where it does not belong.

Problem Statement

Most bad partnerships were bad decisions before they were bad executions.

Partnerships often get blamed later for problems that should have been diagnosed earlier. Teams jump straight to partner selection before deciding whether partnership is the right answer at all. That is how an upstream strategy problem gets dressed up as a downstream execution problem.

What follows is predictable.

  • Partnership gets used as a shortcut. Teams reach for external distribution before they have pressure-tested whether the capability should be built internally or solved through acquisition.
  • Economic logic arrives too late. Time-to-value, cost, payback, and strategic control enter the conversation after enthusiasm has already hardened into a preferred answer.
  • Downstream work gets contaminated. Partner selection, pitch design, and deal structure all become less honest when the original strategic call was never made cleanly.
  • Politics outrun judgment. Decisions start getting framed by executive preference, prestige bias, or urgency theater instead of actual commercial logic.

This framework exists to make the strategic decision explicit before the operating system begins pretending that partnership is already the correct path.

What This Page Does

Make the build-buy-partner decision before the operating system starts.

What this page actually produces

  • A clear statement of the strategic need
  • A recommendation to build, buy, or partner
  • A weighted comparison across the major tradeoffs
  • A basic economic view of each path
  • A list of risks, assumptions, and exclusions
  • A written recommendation memo leadership can review and challenge
  • A cleaner go / no-go point for entering Module 01

What this page does not do

This page is a strategic gate. It is not the partner-selection process or the rest of the operating system.

  • It does not rank partner targets. That belongs in Module 01.
  • It does not design the partner-facing narrative. That belongs in Module 02.
  • It does not structure the deal. That belongs in Module 03.
  • It does not orchestrate launch execution. That belongs in Module 04.

The logic here is simple: if partnership is not the right answer, the operating system should not start.

Framework Overview

The 6-part decision framework

The framework is simple on purpose. Complexity is usually how weak reasoning hides.

01

Define the strategic need

Question: What problem are we actually trying to solve?

Start by naming the real issue: capability gap, market-access problem, speed-to-market pressure, unit-economics gap, or defensibility question. If the need is vague, the decision will be vague too.

02

Define success, constraints, and exclusions

Question: What outcome matters most, and what would disqualify a path?

Get explicit about the timeline, budget, team bandwidth, engineering diversion, legal complexity, board pressure, and operating limits that should shape the decision.

03

Compare build, buy, and partner directly

Question: What does each path really buy us, and what does it cost?

Build can create control. Buy can accelerate access. Partner can compress time-to-value. But each path carries real tradeoffs that should be evaluated comparatively, not politically.

04

Model the economics and timing

Question: Does the math support the story?

Treat this like capital allocation, not relationship theater. Look at cost, payback, time-to-value, margin implications, strategic control, and reversibility.

05

Pressure-test the failure modes

Question: Which favorite lie is hiding inside this recommendation?

Build often hides behind control. Buy hides behind shortcut fantasy. Partner hides behind optimism. The goal is to surface those failure modes before they become the strategy.

06

Write the decision memo

Question: Can another operator read the logic and understand why this path won?

The final output should be explicit about the need, options, economics, risks, recommendation, and next step. If the answer is partner, the operating system begins. If not, it should not.

Proof and Evidence

Why this strategic gate matters

Partnerships should not be treated like vague relationship work. They should be treated like strategic capital-allocation choices that only matter if the economics work and the organization can execute.

That lens helped scale partnership revenue from $300K to $40M ARR in 3.5 years. It also helped generate $3M+ revenue through NerdWallet, create $18 partner CAC versus $67 paid media CAC, and activate a global architecture across 54+ countries.

On the PayPal / Braintree work, the combination of commercial logic and operating design produced an 18% fee reduction, a 12% checkout conversion lift, and $4M+ incremental revenue. Those are not vague BD outcomes. They are operating and financial outcomes.

This page exists to protect that standard before a company enters the rest of the system.

Operating System Fit

Where this page sits in the sequence

PROS begins after the strategic decision has been made. This page is the gate before the sequence starts.

Sequential Core

Pre-Module / 0 Decision Framework 01 Partner Intelligence 02 Partnership Pitch 03 Deal Architecture 04 GTM Integration

This page should make the sequencing obvious. First, leadership decides whether the right answer is build, buy, or partner. Only after that does Module 01 begin ranking partner opportunities worth pursuing.

  • Pre-Module / Module 0 decides whether partnership is the right strategic path.
  • Module 01 selects the right opportunities once that decision has been made.
  • Module 02 turns those opportunities into real stakeholder momentum.
  • Module 03 shapes the deal once the path is real.

If this framework concludes that partnership is not the right answer, the operating system should not start pretending otherwise.

Typical Signals You Need This First

When this becomes urgent

  • Leadership is excited about partnership, but no one has pressure-tested the alternatives.
  • The team is conflating distribution access with actual strategic fit.
  • Internal stakeholders disagree on whether the problem should be solved internally or externally.
  • A “partnership strategy” is being used to avoid the harder build or buy conversation.
  • The company needs a recommendation that can stand up to executive, investor, or board scrutiny.
What the Outcome Looks Like

What good actually looks like

A good output from this page is not “we explored our options.” That is strategic sightseeing.

A good output looks like this:

  • the strategic need is clearly defined
  • the tradeoffs are visible instead of implied
  • the economics are at least directionally modeled
  • the recommendation can survive scrutiny from leadership and finance
  • the company knows whether to enter Module 01 or not
  • downstream partnership work starts only if partnership actually deserves to exist

That is how business development starts behaving like operating judgment instead of hope with a CRM attached.

Request a Conversation

Before you build a pipeline, build the decision logic.

If you want help pressure-testing whether this should be built, bought, or solved through partnership, I can help you make that call with a sharper commercial lens before the wrong path becomes expensive.

The goal is not to force partnership. The goal is to decide whether partnership deserves the next dollar, the next quarter, and the next team commitment.

Primary CTA support copy: Pressure-test the path before the organization starts optimizing the wrong answer.

Secondary CTA support copy: If the answer is partner, the next step is Module 01: Partner Intelligence.