Author: chrisarsenault

  • Market Development is an Operating System, Not a Campaign

    Most companies run market development like marketing with a longer sales cycle.

    They pick a segment. Build a list. Write a message. Launch a campaign. Attend an event. Count meetings. Then they do it again next quarter. Rinse and Repeat.

    The work can look busy and still fail to build anything durable.

    When the campaign ends, the target list goes stale, the lessons stay in individual notebooks, and what was once a promising opportunity is handed to a team that was not involved in shaping it. Nobody can explain why one market moved and another did not. The next campaign starts from nearly zero.

    This is episodic outreach, not market development.

    Market development is an operating system. Its job is to continuously convert an uncertain market into a sequence of better decisions, and the distinction matters.

    A campaign has a start date, an audience, a message, and an end date. An operating system decides what the organization notices, how it interprets the signal, who can act, what evidence is required, where work gets routed, and how the result changes the next decision.

    Campaigns can run inside that system and they cannot substitute for it.

    Why the Campaign Model Breaks

    The campaign model usually breaks in five places.

    First, the list becomes the market.

    The team starts with names in a database and assumes those names represent the opportunity. But the real unit of opportunity may be a property portfolio, a development corridor, a municipality, a partner ecosystem, a buying committee, or a population of projects reaching the same decision window.

    Second, activity replaces evidence.

    Emails sent, calls made, event scans, and meetings booked are easy to count. They are weak proof that a market exists, that a problem is urgent, or that anyone has authority to act.

    Third, qualification happens inside the seller’s head.

    One person sees a strategic opportunity. Another sees an unqualified lead. A third sees an operational problem that belongs somewhere else. Without a shared evidence standard, the loudest interpretation wins.

    Fourth, handoff means forwarding an email.

    The receiving team gets context late, disagrees with the assumptions, or lacks capacity. The originating team calls this resistance. The receiving team calls it poor qualification. Both are partly right.

    Fifth, learning is not retained.

    The market answers a question, but the answer never changes the segmentation, message, qualification rule, partner model, or investment thesis. The organization generates experience without building knowledge.

    An operating system fixes these failures by connecting seven components.

    1. Define the Unit of Market

    Start by deciding what you are actually developing.

    It may be an account. It may be a place. It may be a portfolio of properties, a cohort of construction projects, a municipal priority, an ecosystem route, or a recurring decision shared by several industries.

    This sounds semantic, but it isn’t.

    If the unit is wrong, ownership will be wrong; data will be fragmented, outreach will be aimed at one contact while the decision sits across six organizations. The CRM record will look complete while the market picture remains broken.

    Write the unit down and give it a stable identifier. Define what belongs inside it and what does not.

    2. Build a Signal Layer

    Market development should begin with observable change, not generic intent.

    In my current work, a building permit, capital plan, land acquisition, leadership change, public agenda, funding notice, procurement, expansion, renewal, or operating failure can create a decision window. The signal does not prove an opportunity but it does beg for investigation.

    Use official and permissioned sources where possible. The U.S. Census Bureau’s Building Permits Survey, for example, provides national, state, and local statistics on authorized residential construction. The FCC’s National Broadband Map provides location-level availability information reported through the Broadband Data Collection process. No one source tells a complete commercial story; triangulating your data will contribute to responsible market sensing when their scope and limits are understood.

    Every signal needs a source, date, confidence level, owner, and expiration rule: a stale signal should not stay green because nobody validated it.

    3. Map Decision Windows

    A buyer journey describes how someone moves toward a purchase. A decision-window map describes when a choice becomes expensive, slow, or impossible to revisit.

    Those are different things.

    In the built environment, a utility-design release may matter more than a marketing response. In enterprise technology, the security review may matter more than the demo. In a public opportunity, an approved procurement path may matter more than executive enthusiasm.

    Good market developers ask four questions:

    1. What decision is coming?
    2. Who has authority to make it?
    3. What is their why?
    4. When does the window close and what’s impacted by it?

    The how becomes the relevance of your outreach: is the message attached to a real decision, or just a persona description?

    4. Separate Momentum From Evidence

    Commercial movement and evidence maturity are related, but they are not the same. Track the two dimensions separately.

    A senior executive can be enthusiastic while feasibility is unknown and a technical team can validate a use case while no buyer has authority or budget. A signed document can exist while implementation ownership is unresolved and a decision remains unowned.

    For every opportunity, distinguish among:

    • What we know.
    • What we assume.
    • What we still need to prove.
    • Who can accept the proof.
    • What decision the evidence supports.

    This removes a great deal of pipeline theater and it also makes a respectful no easier. A weak opportunity does not need another follow-up email, it needs missing evidence, a later decision window, a different route, or a stop decision.

    5. Route Authority Explicitly

    Market development is orchestration work, but it should not become an empire that absorbs every decision.

    Product owns product truth. Finance owns the financial standard. Legal owns legal interpretation. Security and privacy owners decide within their authority. Delivery teams accept implementation work. Public-sector specialists govern public processes.

    The market-development team owns the quality of the package moving between them. That package should state the problem, affected population, decision date, evidence, assumptions, risks, requested decision, and proposed owner. A handoff is complete only when the receiving owner accepts it, rejects it with a reason, or routes it to the correct destination.

    6. Run a Control-Loop Cadence

    Cadence is not meeting volume, it is the rhythm by which the system senses, decides, acts, and learns.

    A practical rhythm looks like this:

    1. Weekly: Review new signals, aging decisions, evidence gaps, handoffs, and exceptions.
    2. Monthly: Review market theses, portfolio movement, capacity, campaign results, and control issues.
    3. Quarterly: Decide which markets to expand, redesign, hold, or exit.
    4. After every material pursuit: Record what changed the decision and what the system should do differently next time.

    The meetings are not the system. The decisions, records, and changed behavior are the system.

    7. Measure Outcomes, Not Motion

    Activity still matters, obviously it tells you whether the team is doing the work. However, that should not be confused with the value of the work.

    An outcome-led scorecard should examine seven things:

    1. Market evidence quality.
    2. Qualified decision progression.
    3. Delivery or customer outcomes.
    4. Economics.
    5. Repeatability.
    6. Partner and customer trust.
    7. Controls and learning.

    Calls, posts, events, and meetings sit underneath those measures as diagnostics. These explain performance, but they should not manufacture it.

    This is where many teams get uncomfortable. Activity is immediate and attributable, market outcomes are delayed and shared. The operating system has to preserve accountability without pretending one person caused a multi-party result.

    Build the Minimum Viable System

    You do not need a reorganization or a new technology platform to start. In the first 30 days:

    • Pick one market play.
    • Define its unit of market.
    • Name five credible signals.
    • Map the three most consequential decision windows.
    • Create one evidence record.
    • Define two accepted handoffs.
    • Establish a weekly decision review.
    • Choose three outcome measures and three stop conditions.

    Run it for 90 days and resist the urge to scale it because the team is excited. Scale it when the records are usable, the handoffs are accepted, the decisions are faster or clearer, and the learning is changing behavior.

    The point is not process for its own sake, it is organizational memory.

    A good operating system allows a company to recognize a pattern once, test it responsibly, route it correctly, and reuse what it learned. Over time, the advantage compounds. The team does not merely know more people. It knows how the market actually moves.

    Campaigns create moments. Operating systems create memory, judgment, and repeatability.

    Build the system, then make the campaigns earn their place inside it.