{"id":18,"date":"2026-01-13T03:02:00","date_gmt":"2026-01-13T03:02:00","guid":{"rendered":"https:\/\/137.184.37.140\/?p=18"},"modified":"2026-04-13T03:48:22","modified_gmt":"2026-04-13T03:48:22","slug":"building-for-outcomes","status":"publish","type":"post","link":"https:\/\/pptx.wtf\/?p=18","title":{"rendered":"Building for Outcomes"},"content":{"rendered":"\n

As a MarTech engineer, what drives you? MarTech engineers are often tasked with building bridges, making connections, pipelines across seemingly disjoint set of tools that do completely disparate things. All these tooling is expected to unlock a new vein of experimentation, speed up processes so you can do more experimentation, better measurement of experiments or simply save costs of experimentation. In theory it all looks good, after all MarTech is marketing enablement. So whenever you ship a new API, integrate a new vendor, add a new event, that should start ringing up the cash registers, right?<\/p>\n\n\n\n

In practice, however, when the math strikes, the reality is rarely so.<\/p>\n\n\n\n

A variety of reasons why they do not check out.<\/p>\n\n\n\n

    \n
  1. The solution was not the right solution in the first place<\/li>\n\n\n\n
  2. Solution was an MVP and was not meant to scale, i.e. does not allow for all types of experiments that would enable the kind of incremental revenue that this was sold on. This one is the most common.<\/li>\n\n\n\n
  3. The discount factor was not counted when the incremental revenue impact was thrown around a lot<\/li>\n\n\n\n
  4. The time horizon for the incremental revenue to break in, and the engineering efforts to keep the systems running up until that point, does not really add up.<\/li>\n\n\n\n
  5. Running two or more systems concurrently that do similar things,<\/li>\n<\/ol>\n\n\n\n

    While, we can all finger point each other \u2014 PMs, Engineers, Marketing, Data Engineering and so on, the fact that all these problems exist because we speak different languages. There is rarely a common taxonomy, or a value framework that we all subscribe to.<\/p>\n\n\n\n

    Enter the OLED Framework<\/strong>. OLED is a lightweigh framework that expands to Outcomes, Levers, Experiments and Diagnostics. It doesn\u2019t require a new tool, a new process, or a new committee. It simply forces clarity \u2014 the kind of clarity that prevents wasted work, misaligned expectations, and \u201cwe shipped it, but nothing changed\u201d moments.<\/p>\n\n\n\n

    Outcome<\/h2>\n\n\n\n

    Define the business result before you define the feature<\/p>\n\n\n\n

    Most teams start with the feature.
    \u201cWhat if we add this event?\u201d
    \u201cWhat if we build this workflow?\u201d
    \u201cWhat if we integrate this tool?\u201d<\/p>\n\n\n\n

    Outcome\u2011oriented teams start with the business result.<\/p>\n\n\n\n

      \n
    • Increase conversion by X%<\/li>\n\n\n\n
    • Reduce churn for Y segment by 5%<\/li>\n\n\n\n
    • Improve identity match rate<\/li>\n\n\n\n
    • Increase experiment velocity<\/li>\n\n\n\n
    • Reduce time\u2011to\u2011launch for campaigns<\/li>\n\n\n\n
    • Improve data freshness or reliability<\/li>\n<\/ul>\n\n\n\n

      Your outcome should not simply be a vague \u201cincrease incremental revenue by X basis points\u201d. You want to break it down into as simple terms as possible, simply because it forces clarity of thought for everyone.<\/p>\n\n\n\n

      Levers<\/h2>\n\n\n\n

      Identify the system levers the feature actually influences. This is where engineers thrive. Every feature touches a lever \u2014 a part of the system that can actually move the outcome.<\/p>\n\n\n\n

      Examples of levers:<\/p>\n\n\n\n

        \n
      • Data quality (accuracy, completeness, latency)<\/li>\n\n\n\n
      • Identity resolution (match rate, dedupe rate)<\/li>\n\n\n\n
      • Activation speed (API latency, batch windows)<\/li>\n\n\n\n
      • Experimentation throughput (# of tests per month)<\/li>\n\n\n\n
      • Content velocity (time to generate variants)<\/li>\n\n\n\n
      • Model performance (AUC, precision, recall)<\/li>\n<\/ul>\n\n\n\n

        This step answers the critical question:<\/p>\n\n\n\n

        \u201cDoes this feature actually have the power to move the outcome we care about?\u201d<\/strong><\/p>\n\n\n\n

        It prevents magical thinking \u2014 the belief that a feature will influence a KPI it has no leverage over.<\/p>\n\n\n\n

        Experiments<\/h2>\n\n\n\n

        Define how you\u2019ll validate the impact \u2014 before you ship. Every feature should have a validation plan:<\/p>\n\n\n\n

          \n
        • A\/B test<\/li>\n\n\n\n
        • Holdout group<\/li>\n\n\n\n
        • Stealth mode releases<\/li>\n\n\n\n
        • Dogfooding releases<\/li>\n\n\n\n
        • Pre\/Post comparison<\/li>\n\n\n\n
        • Model offline vs online comparison<\/li>\n<\/ul>\n\n\n\n

          This step protects engineering teams from being blamed for \u201cno impact\u201d when the business never set up a way to measure impact. It also protects product teams from shipping features that feel good but do nothing.<\/p>\n\n\n\n

          Diagnostics<\/h2>\n\n\n\n

          Define the signals that tell you why<\/em> it worked or didn\u2019t. How long you want to keep running this until you kill it or build the next phase. This is the most overlooked part of outcome measurement \u2014 and the most important.<\/p>\n\n\n\n

          Diagnostics are the leading and lagging indicators <\/strong>that tell you whether the feature is behaving as expected.<\/p>\n\n\n\n

          Examples:<\/p>\n\n\n\n

            \n
          • Event volume<\/li>\n\n\n\n
          • Metadata completeness<\/li>\n\n\n\n
          • API latency<\/li>\n\n\n\n
          • Error rates<\/li>\n\n\n\n
          • Identity match rate<\/li>\n\n\n\n
          • Model inference time<\/li>\n\n\n\n
          • Data freshness<\/li>\n\n\n\n
          • Enrollment rate<\/li>\n<\/ul>\n\n\n\n

            Diagnostics answer two essential questions:<\/p>\n\n\n\n

              \n
            1. Is the feature functioning the way we intended?<\/strong><\/li>\n\n\n\n
            2. If the outcome didn\u2019t move, do we know why?<\/strong><\/li>\n<\/ol>\n\n\n\n

              Without diagnostics, teams end up in circular debates:<\/p>\n\n\n\n

              \u201cIt didn\u2019t work.\u201d \u201cThe experiment was wrong.\u201d \u201cNo, the data was wrong.\u201d \u201cNo, the KPI was wrong.\u201d We have seen these play out in so many different forums.<\/p>\n\n\n\n

              Let’s run the OLED model through a couple of different examples.<\/p>\n\n\n\n

              Reducing Email Send Latency in the Activation Layer<\/h3>\n\n\n\n

              Primary Outcome:<\/strong><\/p>\n\n\n\n

              Increase revenue from triggered lifecycle campaigns (e.g., abandoned cart) by reducing the delay between user action and email send.<\/p>\n\n\n\n

              Secondary Outcomes:<\/strong><\/p>\n\n\n\n