Doing the bare minimum ≠ winging it
As business owners often do, I’ve been involved in price negotiations with my clients where I’ve heard some inventive arguments. One I recently heard was that we should be flexible with our pricing since they are also being flexible by asking us to “do just the bare minimum”. This argument rose when talking about our work estimates being just that – estimates, not promises of the final price.
At Sakeus, we build new products and services for our clients, so the bulk of our work involves creating novel solutions to more or less novel problems. This means that when we estimate the work, there’s quite a bit of uncertainty around it as new information emerges during development. New edge cases get recognized, the viability of certain requirements gets questioned, and that sort of things. If something can be estimated precisely, then we’re building something that we’ve built many times before - something that can probably be bought off the shelf for much cheaper. What we focus on, and want to focus on, is creative work.
So, what’s the problem with having to do just the bare minimum? With an unflexible budget it means that we’re not allowed to fail. Not really the blessing the client might think it is.
A creative team must be given the time, the space, and the budget to make mistakes.
I understand what the client was perhaps thinking. They wanted to give us a permission to just “wing it” to get all their requests delivered at a fixed price. I can see it being a beneficial arrangement in some cases. However, when you’re working on novel solutions, you don’t necessarily know what the best, most efficient way to implement something is at a given time. It also doesn’t help that 1) we want to be proud of what we put out into the world (regardless of the client’s budget) and 2) we’re the ones liable if something goes wrong. So the only way to not deliver bad work is to scale down the scope of the work. The best sort of bare minimum is to build less, not worse, and that’s what sort of flexibility we need from the clients as well. Sometimes this leads to the types of conversations that I mentioned earlier.
This is also one of the reasons I greatly discourage estimating features in many cases. Instead, we strive to agree on budgets to drive forward certain business goals and user problems. Then we design the features that are most likely to help the client achieve their goals. In the terminology of design thinking, new products and services are built on the three foundations of desirability, feasibility, and viability (see diagram below and Brown’s Change by Design). This approach keeps us from getting stuck on defining the specs and trying to navigate the client’s thought process behind their feature requests. It allows us to stay agile, focused on the problems that need to be solved, and to embrace the multi-disciplinary nature of co-creation with the client. And from a cost standpoint, it helps us be efficient by letting us be part of the scoping process, as we have a better understanding of the needs of the business and users.
Sometimes the client’s needs are so clear that it makes sense to build them the way they request them. And maybe it’s even possible to estimate the work with some certainty. But the decision to do so should always be at the discretion of the team crafting the solution.