We're not a "Traditional Agency™"
How we buck agency norms to build better products than the status quo
Thank you so much to Paige Meher for the illustrations in this post!
We like to say that Sanctuary Computer is a hospitality company, first and foremost. That is still true - but in the early business decisions we made, we felt that it was important to setup contracts and projects in a way that made the client feel as financially safe as possible to win the business.
We’ve never issued value pricing (and never will). We feel sizing up a client’s wallet is unethical. As such, we have always based our costs in a transparent “work-to-be-done” reality. But like traditional agency businesses, in the past, we have signed contracts with fixed fees, deliverables & deadlines.
We’ve seen time and time again that the traditional agency style of winning business — that means negotiation, value pricing, glossy pitches, detailed deliverables and gantt charts, aggressive contractual deadlines — all boiled down into complex SOWs; just simply doesn’t produce the best work.
Why “Traditional Agencies™” just don’t make great work
The choices that are made week over week as a product idea comes into focus (and the client’s business needs evolving in real-time) are impossible to predict, simply put. After seeing this cycle play out over and over for the last five years, we’ve learnt that we simply don’t know enough about any project to lock it all up in a legal document on day one.
Overly complicated SOWs limit our ability to serve as a true thought partner, and innovate in the problem space. Our hands are tied! A rigid SOW is a handcuff — forcing teams to think narrowly, and to ship exactly what agreed to ship from day one, regardless of whether we realize mid-project that it’s a bloated, expensive, and likely to fail.
M̶a̶d̶e̶ ̶U̶p̶ wait I mean “Value Pricing” is bad for product thinking
The “Traditional Agency™” reads a client’s RFP, sizes up the client’s wallet, and lobs a proposal over the wall. The agency has a lot of experience, and this client is a big company, so why not make an extra couple bucks? Usually disguised under the guise of hourly rates for PMs and Account Managers, the dollar figure has suspiciously ended up a round number. How could that be? Is it possible the client’s project will cost exactly $300,000 USD? With a perfect $20,000 USD add-on for the marketing page (that’s not even designed yet)?
A perfectly round number in a proposal is a red flag. It’s saying loud and clear: one of us is going to get ripped off. Let’s find out who!
Negotiation is bad for product thinking
So, recognizing this is negotiation, but continuing to play the game, the client lobs back a counter offer. Of course, this is now a negotiation, so they don’t provide any flexibility in the work they’re requesting — the only variable to tweak is the cost.
The “Traditional Agency™” saw this coming. They built some wiggle room into their value pricing, but after some back and forth, they agree on a different, perfectly round number — which was actually less than the wiggle room they originally built in (it’s a pandemic year, after all).
Never mind! The “Traditional Agency™” can simply cut some corners on the end product. Maybe they cycle in a junior who’s a bit cheaper to setup the database, or write some (unmaintainable) CSS to get QA done on budget. Doesn’t matter! The client won’t realize until after they’ve paid the final invoice, and hired a CTO.
Deliverables are bad for product thinking
Of course, in winning the work, the ”Traditional Agency™” also presented a “Gantt Chart®”, that had the client’s launch happening smack bang on the deadline from the RFP! What an amazing stroke of luck! The ”Traditional Agency™” is able to ship the product (that right now, is just described as dot points in a Google Doc) in exactly six months, to the day!
Of course, that’s a white lie. A promise to meet a deadline (without deep research, shaping and alignment) speaks volumes:
The ”Traditional Agency™” will cut corners if (when) things go south
The ”Traditional Agency™” will squash good ideas (that jeopardize the deadline)
The ”Traditional Agency™” will pretend they’re agile, but work waterfall (because approvals are a legal paper trail)
SOWs are bad for product thinking
When the business needs of the client change mid-project (because their investor read the latest Wait But Why post), the client needs to ask the ”Traditional Agency™” for a change order. Because everything up until now is so rigidly documented (in the legal sense), it’s likely this process is left to the last minute, hurting everyone’s morale and momentum.
So, this means another painful scoping process, that drags everyone back through the mud of re-negotiation, more (fake) “Gantt Charts®” and agreeing on new deliverables and deadlines. Although this time…
At this point, there is sunk cost involved, so this time, the ”Traditional Agency™” has the upper hand
The ”Traditional Agency™” originally included the cost of pitching for the work in the price of the project cost, so of course, this change-order will be bloated and overpriced also
A negotiation at this point can often erode client trust, turning the race to the (new) deadline into a two sided headlock
Crufty, old-school deliverable-based SOWs are technical debt. As a developer, I’ve had to spend extra hours developing against the constraints of a legacy codebase. As a studio lead, my teams and I have to work around the constraints of a legacy way of doing business. Building products in a contractual straight jacket is not good for anyone.
“Traditional Agencies™” are bad for themselves
The points above paint a traditional agency engagement as bad for the product quality, and for that reason, bad for the client.
However, it’s worth noting how this stuffy old ”Traditional Agency™” business model is bad for the agency itself. By agreeing to a fixed, rigid, contracts you’re giving the client incentive to push your team as hard as possible, because if the cost isn’t variable, then the only lever the client has to maximize the result is by driving the agency team to their breaking point.
This has a massively toxic effect on workplace culture:
Contractual stress trickles down through project managers to creatives, making for a stressful workplace and unhappy people
Clients are more likely to come away dissatisfied, or trust the team less, spreading bad word of mouth or making ongoing engagements tougher
Creatives’ best ideas are likely to be ignored, as they’re contractually incompatible and not worth the conversation
Creatives begrudgingly end up working in “waterfall” workflows, because the contract dictates strict approvals
Those unrealistic, contractual deadlines are likely to have unforeseen knock-on effects when scheduling future projects and clients down the line
How we build products
We believe the best products get built in tight feedback loops, constant iteration, and careful planning. Here’s how we do it.
There is only one SOW (ever)
Our SOW is simple:
Strategy, Design and Frontend Web Development is billed at $5,800 per person, per week
Native Application Development, Cloud APIs or Firmware development is billed at $7,000 per person, per week
Every month, we send an invoice for real work done during the previous month
No deposits, no value pricing, no not-to-exceeds, no rigid deliverables. We communicate expected costs to the best of our ability, and treat budgets & timelines as a design constraint. We communicate carefully, get written approval for changes in monthly staffing and spend, and track finances openly in a shared Notion document.
Provided our client is happy with how we’re tracking on timelines and budgets, and satisfied with the value we bring (as a part of their product team!), we keep working together — light and easy!
Product development is a story
With many chapters and foot notes. It’s a Lord of the Rings themed epic, with a revolving door of characters, countless side-quests, surprising twists, and slowly evolving plot lines.
Our shaping phase traditionally takes around around 4 - 8 person weeks, and should be thought of as the foundational design tasks in our product development cycle.
Here are the outcomes we’re looking for:
1/ A shared understanding of the client’s strategy
2/ A shared understanding of the most valuable, low-effort features
3/ A shared understanding of the content strategy
4/ A shared understanding of the technology we'll use
Every product is different, but this might mean Journey Mapping, Competitive & Market Research, Prototyping, User Testing, Stakeholder Interviews, Persona studies — the list goes on.
Because our billing style is rolling, and usage based, our most organized and strategically-minded clients often come in on the low ends of our budgets, because they’ve probably done most of our work for us.
Given we often shave massive amounts of complexity (fat) from a product in this phase (and thus, save clients tens to hundreds of thousands of dollars in build & maintenance costs) we’ve consistently heard this is the most important phase in our process. We’re often told by our clients that insights discovered during Shaping have saved them hundreds of thousands, if not millions of dollars in the long term.
Typically 6 - 12 person weeks, the Vision phase is when the product starts feeling “real” through rigorous UX activities. That means we’ll be producing and aligning on architecture documents like user flows, sitemap, wireframes, etc. Developers are building database diagrams and vetting potential technology. Designers are developing a visual understanding of how the brand plays out in the product.
We leave the Vision phase with a:
1/ Shared understanding of the experience
2/ Shared understanding of how content will be implemented
3/ Shared understanding of the product mechanics and architecture
At this point, there’s very little ambiguity in what we’re building; both from a mechanical and visual point of view. The Vision phase output serves as the project’s north star.
A variable timeline depending on the product’s complexity, the Building phase brings together Design, Development & Content as an integrated team. This shortens feedback loops, forces us to prioritize, and allows us to build more efficiently.
Our preferred way of breaking up sprints is Fixed Time, Variable Scope. That means for big projects, our goals in a say ~12 calendar week Building phase (sprint size is variable based on project complexity) are more likely around shipping select components of the product, rather than the whole thing at once.
We keep working in those short, time-boxed sprints. We’re in lock step communication with our clients. We are continually aligning and calibrating our next moves. We simply keep building until launch, and when the product hits critical mass, we’re here to keep iterating, too! With this process, our clients don’t pay a dollar more than the hourly person cost to get them to launch.
It’s everyone’s job to meet budgets & timelines
We’re transparent and upfront about our costs. We do our best to help our clients understand what they might need to spend to go to market by giving example budgets for previous, similar projects (anonymized, of course).
Provided those numbers can work, we then prefer to openly discuss hard budgetary constraints and timelines, approaching them soberly and with a heavy dose of reality: it’s in our best interest to ensure our clients stay happy — unrealistic deadlines & blown budgets are rarely forgiven.
Once we’re working together, we record our spend weekly in a shared Project Wiki, and carefully voice changes in our expected spend as the inevitable comes up. If those changes push us outside of acceptable costs or dates, we all get creative to trim complexity where it makes most sense. We stay squarely in our client’s corner, and defend the success of the project at every turn.
Let’s build together
If you’re looking for a group of highly experienced product builders who operate transparently as internal thought partners, and go over and above to create an environment that produces the best work; then you’re the type of client we’re prioritizing going forward. Let us know if that’s you.