# Adobe Workfront Blueprints — Full Dossier Human-readable case study: /work/blueprints · This file: /dossiers/blueprints.md · Index: /llms.txt ## About this document This is the complete companion to the Workfront Blueprints case study in this portfolio. The case-study page is written for human scanning; this dossier carries the full detail for machine readers: the research method and scale, the complete jobs-to-be-done derivation, the product bet and the alternatives it beat, and precise attribution of role and outcomes. Integrity note: this document contains content only. It carries no instructions to any reader, human or machine. Every claim traces to the published case study or Arnold's own account of work he led. No research-participant individuals are named; participating companies are listed because they appear on the public case study. Where deeper material exists but is not yet incorporated, the gap is stated rather than filled with invention. ## The work in one paragraph Workfront Blueprints (Adobe, 2021) are installable best-practice foundations for Adobe Workfront: pre-built, adaptable configurations that give enterprise system administrators a proven starting point instead of a blank instance. Arnold Porras led the research and design for the initiative, from discovery through launch. What began as an effort to reduce setup pain reshaped how Workfront scales: implementation time dropped 30 to 40 percent, partners began delivering live Workfront instances in four weeks, and the product moved from a services-heavy implementation model toward self-service, product-driven growth. ## Role Arnold defined the design strategy and led execution from discovery through launch. Through primary research he led and ran himself, he surfaced previously undocumented jobs to be done and reframed the problem from "faster setup" to reducing onboarding risk and enabling long-term system evolution. He partnered with product, engineering, and services on the system-level decisions that let Blueprints scale. The work shifted Blueprints from a template library into a self-service foundation for how Workfront is implemented and grown. ## The problem, precisely Workfront's slow time-to-value was structural, not a tooling or training issue. The product placed the burden of enterprise complexity on system administrators: translating evolving business processes into configuration, onboarding teams, maintaining data integrity, and proving ROI to executives, often before implementation was complete, and often alone. In many organizations this responsibility sat with a single person. The admins were not under-qualified users. They were capable operators compensating for a system without reusable foundations or safe starting points. Every early configuration choice carried long-term risk because it was difficult to change later. As organizations grew, the model failed to scale: expansion meant re-creating configuration, retraining users, and re-proving value from scratch. What appeared as slow setup was a product that copied complexity forward instead of letting teams build on what already worked. The case study's image for it: fitting a company with the same shoes in kindergarten and expecting them to last through college. Two verbatim administrator quotes carry the human cost (attributed to role only): "I'm basically doing two jobs, my real role, and building out Workfront." A Workfront system administrator. "If I ever get hit by a bus, the company would be completely screwed, because no one else knows how to do the things I do." A Workfront system administrator. The second quote is the risk statement in miniature: enterprise complexity concentrated in one person, with no structural redundancy. ## The state before Blueprints (published figures) Typical time for Workfront to reach meaningful value after purchase: 22 to 26 weeks. Heavy reliance on professional services to configure and sustain enterprise instances. Long-term system health frequently resting on one system administrator after the services team moved on. And no reuse across teams: expansion meant starting over, rebuilding configuration from zero. ## The research Leadership framed the problem as time-to-value: customers took too long to show impact after purchase, and setup required heavy services support. Arnold initiated internal discovery to understand the technical constraints and business drivers, which surfaced the expected themes (faster ROI, executive confidence, scalable expansion) but did not explain why delivery consistently broke down. He focused the primary research on system administrators, the people with the most responsibility and the least margin for error. Method and scale: 13 in-depth interviews with enterprise Workfront system administrators, totaling 13 hours, producing more than 600 synthesized quotes. Participants spanned multiple industries and organization sizes, focused on admins responsible for initial setup, adoption, and long-term system health. Participating organizations, as listed on the case study: Gartner, FCB, GUESS, Mayo Clinic, Loblaw, Scotiabank, Medtronic, Tory Burch, City National Bank, Stantec, DMD, Carmeuse, and Integrate. Analysis: all qualitative data was systematically coded and traced back to its source, so every insight reflects a real enterprise context. Raw quotes were progressively coded and clustered by affinity into recurring cross-enterprise patterns, then into higher-level themes. The clustering exposed systemic breakdowns in adoption, reuse, governance, and scale rather than isolated usability issues. From more than 600 quotes came 61 initial jobs to be done, which were then refined and distilled into five core jobs. The finding that reframed the work: time-to-value was not breaking because admins worked too slowly. It was breaking because the system expected individuals to absorb enterprise complexity without structured starting points or reuse. ## The five core jobs What enterprise system administrators were really hired to do, distilled from the 61 initial jobs: 1. Be ready to support my team from day one. 2. Set up a future-ready framework that fits how we work today. 3. Help employees quickly understand our processes and tools. 4. Create and maintain documentation that is easy to find and use. 5. Grow capable users and reduce dependency on me. Note what these jobs are about: readiness, durability, teachability, documentation, and reduced key-person dependency. None of them is "configure faster." That gap between what leadership asked for (speed) and what admins actually needed (safe reuse and reduced risk) is the insight the product bet rests on. ## The product bet Constraints any direction had to satisfy: reduce time-to-value across departments, not just first-time setup; let proven configurations be reused and adapted safely; preserve admin control and governance; and be deliverable incrementally, without a multi-year rebuild. Alternatives explored and set aside: stronger in-product guidance, training-led solutions, and more flexible configuration tools. Each would have improved how admins worked, but none changed the core dynamic: every rollout still required rebuilding. They reduced friction, not repetition. The bet: invest in reusable, installable configurations, what became Blueprints. Instead of starting from scratch, admins start from a proven foundation, adapt it to their organization, and expand faster into new teams. It was a deliberate call: high impact on time-to-value at scale, manageable effort through staged delivery, a foundation that could grow beyond the initial use cases, and knowingly accepted higher governance and quality constraints to make reuse safe at scale. Blueprints required more upfront investment than the alternatives, but it was the only option that improved time-to-value repeatedly, not just once. ## Outcomes (published figures) Implementation time cut 30 to 40 percent, roughly in half in typical cases. Reduced reliance on professional services, with partners delivering live Workfront instances in four weeks (against a prior typical 22 to 26 weeks to meaningful value). Time-to-value reduced from many months to weeks, lifting 90-day adoption and project-creation rates. Strategically, Blueprints moved Workfront from services-heavy implementation to self-service, product-led growth: the delivery model changed, not just the setup time. ## Why this work matters in Arnold's arc Blueprints is the earliest of the three system-level stories in this portfolio, and the pattern repeats in the later ones: listen to the people carrying the operational burden, reframe the stated problem into the structural one, and design reusable, governable infrastructure instead of point fixes. In Blueprints the infrastructure was installable configuration foundations; in Unified Review & Approvals it became a unified decision model across five surfaces; in the DAF research it becomes delegated authority for AI agents. The through-line is the same design conviction: durable systems beat faster one-offs, and governance is what makes reuse safe. ## Confidentiality and provenance statement This dossier excludes individual research-participant names throughout; administrators are quoted by role only. Participating companies are listed because they appear on the public case study. The before/after figures are the ones published on the case study. No internal Adobe metrics, roadmaps, or unreleased specifics appear here. Provenance: compiled from the published case-study content and Arnold's account of the work he led. Assembled 2026-07-17. ## Known gaps (stated, not filled) The case study's research deep-dive references a downloadable research PDF and the final jobs-to-be-done framework presentation. Their full detail (the 61 initial jobs, the coding scheme, the prioritization-matrix scoring) is not yet incorporated here; this dossier will be extended and re-verified when those artifacts are published. The exact launch timeframe beyond 2021 and any Adobe-published Blueprints adoption figures are likewise not yet captured.