When the brief is smaller than the problem

In April I was brought into Intuit Mailchimp on a contract to work on Mailchimp Transactional, the developer-facing email product. The brief was an incremental UI refresh. Most of what I actually did was argue that it should be a platform integration instead — collapsing Transactional into the core Mailchimp product rather than making the separate thing look better.

Arguing a brief upward is usually the wrong instinct, and I want to be careful about how this reads.

Why the smaller version was the wrong shape

Transactional and core Mailchimp were two applications, built and run separately, serving two audiences that increasingly overlap: marketers and developers at the same company, working on the same customer, in different products.

A refresh would have made the second product look like the first. It would not have removed the thing that costs people time, which is the boundary itself — separate places to be, separate mental models, separate answers to "where do I go to do this". The seam is paid for on every crossing, and repainting it doesn't reduce the toll.

That's the general test, and it's the only part of this worth carrying elsewhere: does the incremental version leave the actual problem standing? If the smaller brief makes the current arrangement more pleasant without changing the arrangement, you're being asked to decorate a constraint rather than remove it.

Why arguing scope up is usually wrong

I'd distrust this instinct in someone I was hiring, because most of the time it's self-serving. Bigger scope is more interesting work, a better portfolio piece, and a longer engagement. A designer who responds to every brief by proposing something larger is not exercising judgement, they're expressing a preference.

Three things made it defensible here rather than opportunistic. The overlap between the two audiences was already visible in how people used both products, so the argument wasn't hypothetical. The refresh and the integration shared most of their early work, so making the case cost the project very little even if it lost. And the integration was something a roadmap could absorb in stages rather than a demand to stop and rebuild — which is the difference between a proposal and an ultimatum.

If none of those had been true I'd have done the refresh, and it would have been the right call.

What actually settles it

Not the argument. The argument gets you a meeting; what settles it is showing the integrated version and letting people react to something concrete rather than to a description of it. The deliverable that moves a decision is something running, and that's more true, not less, when you're proposing a bigger scope than you were asked for — because the burden of proof is on you and a document doesn't carry it.

What I'm not claiming

This was a one-month contract in April 2026. I set the design vision and shaped the roadmap that followed; I wasn't there for delivery, and I have no shipped outcomes to report. A re-platform of that size is measured in quarters and other people did the quarters.

So the honest scope of the claim is that the direction changed from refresh to integration, and that the case was made with a working version rather than a deck. What it eventually became isn't mine to describe.

Related: how I work, and how engagements work here.