Be a Partner, not a Vendor
Years ago, I received a frustrating email from a disappointed client. I was confused – from an engineering perspective, this should have been a model project. It nailed the requirements on time, under budget, with great documentation, full unit test coverage, and even included some cutting-edge original research and upstream open-source contributions.
Here's the email (emphasis added, scare quotes original):
There are a number of reasons we are shutting down the job. . . . [T]he developers did believe that some shortcuts were made and that no initiative was taken to make the video module better outside of the “requirements”. I think on our next joint effort, we need to be much clearer from our part. Realistically, we would have preferred to pay more, but had help thinking and making the video module better.
I appreciate you sending the remaining balance back.
Now, my team could have just laughed this off and called it a day. Here is a client complaining that we met the requirements! But I realized he was right! I learned two things from this:
Service is not what you think
This client sent early signals that he was not open to feedback. We got a rigid set of requirements, and a few attempts at suggesting improvements were swiftly rejected. Rather that enter into a conflict, it was easier to fulfill the requirements as written. But we should have persisted; a true partner needs to engage with the full product lifecycle, even if that means risking a conflict. Behaving meekly is not good service.
You aren't a cog
When all was said and done, his email summed it up perfectly. We are paid for thinking. The real value we bring as an agency is in product design and architecture, not punching keys or a TODO list. The latter could be offshored for a lot less money. The former requires a partner, not a vendor.