Every pricing strategy has its pros & cons, but one has always bothered us: the retainer.
Retainers are convenient and easy to understand. Pay a fixed price every month, instantly scale your team. They’re straightforward for FP&A (What will we spend next month? Same as last month). There’s no friction to start (Start sending payments and your consultant will absolutely accept them).
But for product work, retainers almost always incentivize the wrong thing: busy-ness over business. They increase the noise in the signal-to-noise ratio.
You might hire a consultant on your product for a number of reasons:
That last one is really interesting: tying payment to outcomes is powerful, but the crucial piece is the outcomes, and specifically their definition. Retainers make it far too easy to skip the part where we define our outcomes—and most of us want to skip that part because we’re busy.
Defining clear outcomes is hard. The best partners will force you to do it, but when you set up a retainer deal and you need to start now, it’s easiest for everyone to just start working. We might not have clear goals, but it’s still work, and work moves us forward, right?
Once the project is moving, velocity becomes the key metric (Outcomes? What outcomes?). Pausing for any reason is time lost; “Blocked” is a dirty word.
That’s how teams fall into to busywork. As long as stuff is happening and some set of features gets released periodically, the project looks like it’s getting somewhere. Product leads mine the backlog to keep the team busy—and in the worst cases makes snap decisions on behalf of customers with zero validation. Devs pick up tickets with vague specs and have to make hundreds of small choices on their own. Before too long, all of this becomes tech debt.
Everybody’s busy, and nobody has the time to ask: Why are we building this?
This is a dangerous way to run a product.
When there’s no clear business case, no definition of done, there’s no way to know how much time it will take to get there. Fine for maintenance, horrible for product delivery.
Usually two to three months in, stakeholders start asking when they'll see results. There was no estimate to begin with, and nobody (including stakeholders) knows what “results” actually means. This is where it gets messy.
The team’s working hard yet no one can answer: When will we be done?
At this point the pressure’s on, and the project is beyond the point of no return. No one is going to push back for a clear definition of done now. Blocked is bad!
Sometimes this works out; The project team squeezes some value out of the noise and wraps up a deliverable that’s useful. Often it doesn’t. Maybe the team saves face, but the project never goes anywhere and everyone walks away.
Retainers work when a project requires availability more than outcomes. If you need long-term maintenance or a specific resource you can't hire directly, and you're willing to manage that resource effectively, and you can afford to pay a higher hourly rate: forget everything I’ve already said and go for it.
But why do product teams still go for the retainer model?
Retainers feel good, especially when we’re busy. They give us an out. They let us convince ourselves we’re getting things done, even when we’re ignoring crucial details. Really they just kick the can down the road, and by the time we catch up, the situation is worse.
If you want to meet your goals (with actual ROI) you have to plan first.
That’s why we hate retainers and love fixed-fee projects.
Fixed-fee forces up-front planning, even when it's a significant amount of work. If the project is worth doing, it’s worth doing right, and a fixed-fee engagement will force everyone (including your team) to get crystal clear about what ‘done’ really means.
If you're building a product: go fixed-fee. Do the up-front work. Think through your goals and prioritize what matters.
And then watch the team nail your objectives, on time and on budget.
James Barr still goes to the office a few times a week, because someone has to water the plants.
