Introduction: The Optimization Trap
There's a siren song in the world of technology, and it whispers a single, seductive word: optimization. It’s the idea that the path to progress is paved by making the things we already do faster, cheaper, and more efficient. For decades, this has been the gospel of enterprise software, and few have preached it more successfully than Pegasystems.
Pega has built a multi-billion-dollar empire by providing a powerful platform for Digital Process Automation (DPA). They give the world’s largest companies the tools to map, manage, and accelerate their most complex internal workflows. They are, in essence, masters of paving digital cow paths. If your company has a convoluted, 150-step process for onboarding a new customer, Pega will help you do it in 140 steps, or do the 150 steps with fewer errors.
And that seems like progress. It feels like innovation.
But it's not. It's the optimization trap. It's the fallacy of perfecting the present at the expense of inventing the future. The most defensible, category-defining opportunities are rarely found in optimizing existing processes. They’re found in making them entirely obsolete.
This post is a teardown of that optimization trap, using the DPA market as our case study. We're going to apply a rigorous set of strategic frameworks to show you how to move beyond a world of process and into a world of outcomes. You’ll see how to:
Deconstruct the core assumptions of a market using First Principles Thinking to find its foundational flaws.
Reconstruct a new, customer-centric solution from the ground up using the Jobs-to-be-Done framework.
Strategize by choosing a powerful Organic Growth Path as our North Star and then designing a deep, defensible moat using Doblin's 10 Types of Innovation.
This isn’t just an academic exercise. This is a blueprint for building a next-generation company. It's about shifting your perspective from asking, "How can we do this better?" to asking, "Why do we do this at all?"
Part 1: Deconstruction — Why 'Process' is a Flawed Foundation
Before you can build something new, you have to understand why the old thing exists. The entire DPA market, with players like Pega at the forefront, is built on one central assumption. Let's put it on the table:
The Central Assumption: "The most effective way to improve enterprise operations is to digitally replicate and automate existing business processes."
This seems logical. It’s intuitive. But is it true? To find out, we have to deconstruct it.
A Socratic Dialogue with the Status Quo
Socratic questioning is a technique for dismantling assumptions by relentlessly asking "why." Let's apply it to our central assumption.
Question: What is a "business process"? Answer: It's a series of steps and decisions that a company takes to achieve a specific outcome. For example, the steps to approve a mortgage.
Question: Why do these specific steps exist in their current form? Answer: Well, they've evolved over time. Some steps are for regulatory compliance, some are because the credit department uses a different system than the underwriting department, and some are just "how we've always done it."
Question: So, the process is a product of history? It's shaped by legacy technology, departmental silos, and past regulations? Answer: Yes, absolutely. It's a patchwork.
Question: Are those constraints—the legacy tech, the silos, the old ways of working—fundamental truths? Are they like the laws of physics, unchangeable? Answer: No, of course not. They are inherited constraints. We could, in theory, change them.
Question: So if the process is just a collection of workarounds for constraints that aren't fundamental, what is the actual, unchanging goal? Answer: The outcome. The goal is to give a qualified person a mortgage.
Question: What if you could achieve the outcome—a fully compliant, vetted, and approved mortgage—without executing the historical "process"? What if you could just… get the outcome? Answer: That would change everything.
This dialogue reveals the crack in the foundation. DPA tools are designed to manage the workarounds, not to challenge their existence. They accept the historical baggage as a given and sell you a nicer suitcase. True innovation lies in leaving the baggage behind.
The Five Whys of Enterprise Software Complexity
Let's dig deeper with another First Principles tool: the Five Whys. We'll start at the surface and drill down to the root cause.
Why do enterprises spend millions on Pega?
To automate and manage their complex, multi-step workflows.
Why are their workflows so complex?
Because they have to connect dozens of legacy systems, involve multiple departments that don't talk to each other, and adhere to layers of regulatory checks built up over decades.
Why do they orchestrate all these moving pieces instead of just replacing them with something simpler?
Because the perceived cost and risk of ripping out a core banking system or retraining an entire department is immense. Organizational inertia is a powerful force.
Why does this orchestration seem like the only viable path to efficiency?
Because it accepts the underlying complexity as an unchangeable reality. The focus becomes managing the chaos, not eliminating it.
Why is the complexity accepted as a given?
Root Cause: Because no one has successfully created a new layer of abstraction that makes the underlying complexity irrelevant to achieving the business outcome.
This is our foundational truth. The market for DPA exists not because processes are essential, but because no one has built a good enough "complexity abstraction" layer.
Synthesis: The First Principles of a Business Outcome
After shredding the assumptions, we're left with the fundamental truths. A business outcome isn't the sum of its process steps. It’s much simpler. Any given business transaction requires only three things:
Validated Inputs: Verifiable data about the customer, request, and context.
Application of Rules: A set of business logic and regulatory constraints that must be applied to the inputs.
A Verifiable Output: A clear, auditable decision or change of state (e.g., account opened, loan approved, claim paid).
The sequence of how you gather inputs and apply rules is an implementation detail. The "process" as we know it—a rigid, step-by-step workflow—is just one possible implementation, and it's often the clunkiest and least efficient one imaginable.
With these first principles in hand, we can now rebuild a solution from the ground up.
Part 2: Reconstruction — A Blueprint for 'Outcome as a Service' (OaaS)
If the problem isn't "our process is too slow" but rather "we want to achieve an outcome," then we need a solution designed for that job. This is where the Jobs-to-be-Done (JTBD) framework comes in.
Finding the Real Job-to-be-Done
JTBD forces you to look past the product and understand the customer's underlying motivation.
The Low-Level Job Pega is Hired For: "Help me execute, monitor, and improve my multi-step loan application workflow." This is about the solution (the workflow).
The High-Level Job the Customer Actually Wants Done: "Enable me to provide capital to a qualified applicant instantly and safely." This is about the outcome.
This high-level job statement is our new foundation. It’s what the customer is actually trying to achieve. It’s filled with rich context. The customer is struggling with the tension between speed ("instantly") and risk ("safely"). They are trying to achieve a desired future-state where capital flows to the right people with zero friction. The existing process is just the painful, inefficient way they're forced to do it today.
Designing the 'Anti-Pega' Solution
If we're building a company to serve this high-level job, our product won't look anything like Pega. Our core design principles will be fundamentally different.
Principle 1: Abstract the Complexity, Don't Expose It.
The value proposition of DPA is that it helps you manage complexity. The value proposition of an Outcome-as-a-Service (OaaS) platform is that it hides it.
Working Today, Few Are Doing: Look at pioneers like Stripe or Plaid. When you use Stripe, you don't build a "payment processing workflow." You don't manage PCI compliance rules, orchestrate bank transfers, or handle currency conversions. You use a simple API, and the payment outcome is achieved. Stripe absorbed a world of financial complexity so you wouldn't have to. Plaid did the same for linking bank accounts. They sell outcomes, not process builders. This is our model.
Novel Concept: The Outcome Synthesis Platform. Imagine a platform where, instead of a visual process builder, you get a simple configuration screen. You define the outcome you want—e.g., "Onboard a new wealth management client." Then you specify the required inputs (customer data) and the desired output parameters. The platform, as a black box service, takes it from there. It connects to a network of APIs for identity verification (KYC), background checks (AML), and account funding, applying the necessary rules and delivering a simple, binary output: "Success" or "Failure" (with auditable reasons). The labyrinthine process is the platform's problem, not yours.
Principle 2: Elevate the Job Performer.
In Pega's world, the "job performer" is often a business analyst or IT professional dragging and dropping boxes to design a workflow for a customer service agent to follow.
In the OaaS world, the primary "job performer" is another software system. The goal is to enable machine-to-machine automation of outcomes. An enterprise's own application would make a single, secure API call to the OaaS platform: onboard_client(data). The response would trigger the next action in the enterprise's own system. This elevates the entire enterprise tech stack, freeing up humans to design better products, not manage broken processes.
Principle 3: Deliver Value Through Fewer Visible Features.
Enterprise software has been defined by feature bloat for decades. The perceived value of a tool like Pega is in its endless menus, options, and configurations for handling every possible exception in a process.
The OaaS platform's value is in its radical simplicity. The user interface might be nothing more than a developer portal with excellent documentation and an analytics dashboard. The only "features" the end customer cares about are:
Speed of outcome.
Accuracy of outcome.
A clear, auditable trail.
It’s a shift from "power through configuration" to "power through abstraction."
Creativity Triggers for OaaS Concepts (Reference Table)
To show this isn't magic, let's map these concepts to specific innovation tactics.
Part 3: Strategy — Building a Defensible Moat Around Outcomes
A great idea is not a great business. A great business has a deep, defensible moat that protects it from competition. How do we build one for our OaaS company?
This is a two-step process. First, we pick our strategic North Star. Then, we use a tactical toolkit to execute that strategy.
Step 1: Define the North Star with Organic Growth Paths
The Organic Growth Paths framework helps us define our high-level strategic intent. Are we trying to steal market share, create a new market, or something else?
Our OaaS model is a classic example of New Platform Creation.
Why it's not "Core Market Disruption": We aren't trying to build a cheaper or better DPA tool to steal Pega's customers one by one. That would be competing on their terms.
Why it's "New Platform Creation": We are building a new, intermediary layer in the enterprise technology stack. This OaaS layer sits on top of and abstracts away the complexity of legacy systems, data providers, and even DPA tools themselves. Over time, this new platform commoditizes the layers below it. Why would you pay millions for a process engine when you can pay a few dollars for the outcome itself? The platform that successfully delivers outcomes becomes the new center of gravity in the enterprise.
This is our North Star. Every decision we make should be in service of building out this new, essential platform.
Step 2: A Tactical Blueprint Using Doblin's 10 Types of Innovation
With our "New Platform Creation" strategy set, we can now use Doblin's 10 Types of Innovation as a tactical checklist to build our moat. The strongest moats are built by combining multiple types of innovation.
The "Behind the Scenes" Moat (Configuration)
This is the internal architecture of your business that competitors can't see or easily copy.
Profit Model: We're moving from Pega's Per-Seat/Per-CPU Licensing to a Pay-per-Successful-Outcome model. A bank pays us $50 for every successfully approved mortgage, not a million dollars a year for software licenses. This aligns our incentives perfectly with the customer's job and makes adoption frictionless.
Network: This is the heart of the moat. We create a powerful network effect by integrating hundreds of data and service providers (for identity, credit, compliance, etc.). Every new provider makes the platform more valuable for all customers. Every new customer brings more transaction volume, which allows us to negotiate better rates with providers and train our AI models. This creates a flywheel that is incredibly difficult for a new entrant to replicate.
Structure: We organize our company around Outcome Verticals, not software products. We have a "Head of Mortgage Origination Outcome" and a "Head of Insurance Claim Settlement Outcome." These teams are composed of product managers, engineers, and legal/compliance experts who possess world-class domain expertise for their vertical. Their job is to be the best in the world at abstracting away that specific industry's complexity.
Process: Our key proprietary process is the Regulatory Abstraction Engine. This is our "factory" for turning messy, ambiguous legal and regulatory documents from around the world into deterministic, machine-executable code. This is our most valuable and secret IP.
The "In the Market" Moat (Offering & Experience)
This is how the customer perceives and interacts with our value.
Product System: We don't sell a collection of disconnected tools. We offer a single, cohesive Outcome System: 1) a developer-first API, 2) a world-class developer sandbox and documentation environment, and 3) a customer-facing analytics portal to monitor performance and audit results. That’s it.
Service & Channel: Our go-to-market strategy is inverted from traditional enterprise sales.
Channel: We are developer-first. We win the hearts and minds of the engineers inside the enterprise who are tired of wrestling with legacy systems. They can start building with our API for free in a sandbox, demonstrating value from the bottom up.
Service: Because the product is so simple to use, our "service" isn't about training. It's a "white-glove" integration service. We help new enterprise customers connect their internal data sources to our platform quickly and securely. It's a high-touch onboarding for a product that is, thereafter, zero-touch.
Conclusion: The New Mandate for Founders and VCs
We started with Pega, a company that has built a phenomenal business by helping its customers optimize the past. We deconstructed the very foundation of its market and found it was built on accepting complexity as a given.
From those first principles, we reconstructed a new model—Outcome as a Service—built around the customer's true Job-to-be-Done. We then laid out a strategic and tactical blueprint for how to build a category-defining company with a deep, defensible moat around this new model.
This brings us to a crucial point, especially for those in the startup ecosystem. The accelerator model, with its relentless focus on short-term, measurable growth, is often hostile to this kind of foundational thinking. An investor looking at a weekly progress chart would ask, "How many processes did you map this week?" They wouldn't ask, "Did you invalidate the need for the process entirely?"
The pressure to find product-market fit quickly encourages founders to solve visible, surface-level problems. It rewards paving the cow path because it's easier to show progress on a known road. But the generational companies, the ones that build moats that last for decades, aren't the ones who pave the path. They're the ones who invent the teleporter.
My challenge to founders is this: Stop looking at the processes in your industry and start deconstructing them. Find the fundamental truths, identify the high-level Job-to-be-Done, and ask yourself what a solution would look like if it were built to achieve that outcome instantly. Shred the process.
And my challenge to investors is to develop the frameworks and the patience to fund them. The next multi-billion dollar enterprise company won't be a better version of Pega. It will be the company that makes Pega irrelevant.
Let me know that you read this far by dropping a comment. 👇
Follow me on 𝕏: https://x.com/mikeboysen
If you're interested in innovating for the future as opposed to fiddling around the edges, feel free to contact me. My availability is limited.
Mike Boysen - www.pjtbd.com
De-Risk Your Next Big Idea
Masterclass: Heavily Discounted $67
My Blog: https://jtbd.one
📆 Book an appointment: https://pjtbd.com/book-mike
Join our community: https://pjtbd.com/join
