Workfront Blueprints
Reducing time-to-value and reshaping how Workfront scales for enterprise teams
Getting a new enterprise onto Workfront took months, and in most organizations one administrator carried the whole thing. Executives wanted return on investment sooner. The admin wanted to survive the quarter.
I led the research and design for Workfront Blueprints. The obvious brief was to make setup faster. What the research said instead was that speed wasn't the constraint, reuse was, and that changed what we built.
Blueprints shipped in 2021 and it's still in the product today.
Led research, strategy, and design from discovery through launch.
Enterprise administrators across finance, healthcare, retail, and professional services.
A platform where every new customer started from an empty system.
Released in 2021, documented and in the product five years later.
The admin was the system
Every new Workfront customer started from an empty system. Someone had to decide the project types, the request queues, the custom forms, the statuses, the approval paths, the reporting, and how all of it fit the way this particular company actually worked. That took 22 to 26 weeks, often before implementation was even complete, and usually it landed on one person.
So the platform's hardest job sat with whoever had the least margin for error. If that person left, a lot of undocumented reasoning left with them.
If I got hit by a bus tomorrow, nobody here would know why any of it is set up this way.
The second problem showed up when a company that had already succeeded tried to expand. A new team, a new region, a new business unit, and the answer was to start over. Nothing carried forward, because there was no way to package what worked and install it somewhere else.
Read together, those two things describe a product that copied complexity forward instead of letting teams build on what already worked. Slow setup was the symptom people complained about. The structure underneath it was the actual problem.
Leadership framed this as a time-to-value problem, which pointed at a faster setup wizard. I went to the people doing the work instead: thirteen in-depth interviews with enterprise administrators across finance, healthcare, retail, and professional services, producing more than six hundred coded quotes.
Clustering those quotes surfaced sixty-one distinct jobs, which distilled down to five that mattered. Not what admins asked for in a feature request, but what they were actually hired to do: stand the system up, make it match how the business works, keep it governable, grow it into new teams, and prove it was worth the money.
Two of those five, growing safely and keeping it governable, had no product answer at all. That was the finding that reframed the work. Setup speed was one job out of five, and we were about to spend a release on it.
Reuse, not speed
We considered making setup faster, shipping a bigger template library, and putting more of the work on services. Each one improves time-to-value once, for one customer, and then you do it again for the next one.
The bet we made instead was installable, governed foundations: packaged configurations a customer could install into a live system, adapt to their organization, and reinstall for the next team. That's a harder thing to build, because anything installable into a production system has to be safe to install, which meant accepting real governance and quality constraints we could have avoided.
It was the only option on the table that improved time-to-value repeatedly instead of once.
A foundation teams build on
Blueprints let an administrator install a proven configuration instead of building one, then adapt it to their organization and reuse it as they expand. Setup time dropped by roughly 30 to 40 percent, and implementation partners could stand up a working instance in about four weeks rather than starting from a blank system.
The strategic change mattered more than the number. Getting a customer live had been a services problem, solved by people. Blueprints made it a product capability, which is the difference between a business that scales with headcount and one that doesn't.
It shipped in 2021 and it's still there. Adobe's documentation for it was last updated in April 2026, five years on, which for enterprise software is the only durability test that counts.
Blueprints moved Workfront from services-heavy implementation to product-led growth.
I defined the design strategy and led execution from discovery through launch: the research, the reframe, the case for the bet, and the design of the install-and-adapt experience. Product, engineering, and services built it with me, and the governance model that made installation safe came out of that collaboration rather than out of my head.
The part I'd point to is the reframe. Leadership asked for faster setup, the research said reuse, and the job was to make that argument survive contact with a roadmap that already had a plan.
This is the earliest work on the site, and the pattern in it kept going.
Blueprints made expertise installable, so a team could inherit a governed foundation instead of rebuilding one. Unified Review & Approvals did the same thing to decisions, replacing hand-stitched coordination with one model that holds the record. And my Delegated Authority Framework asks the same question about agents: what can be safely delegated, and what has to stay with a person.
Package what works, govern it, then let people build on it. That's been the argument since 2021.
The same idea, applied to decisions.
Unified Review & ApprovalsAnd applied to what an agent may do.
Delegated Authority FrameworkThis page is the story. The dossier is the record.
The full dossier carries the detail the page compresses: the research method and scale, the full jobs-to-be-done derivation, the product bet and the alternatives it beat, and the published outcomes with their sourcing. Written for the AI you'll paste this page into. Open to everyone.
www.arnoldp.com/dossiers/blueprints.md
