Product
Embracing Change in Software
Skip the out-of-scope dance and get on with adjusting quickly to what's best.
It sits above every Statement of Work Postlight sends across to a prospective client:
The below represents a high-level description of the scope of work required by this agreement. Any clarifications, modifications, deletions or additions must be mutually agreed upon.
At first glance it looks like a fairly innocuous snippet of legal language. It’s actually a lot more than that. It embodies how we at Postlight fundamentally view the software development process. You can pluck it out of its legal wrappings and sum it up in two words: things change.
When a prospect approaches Postlight, we have a series of conversations before we decide to move forward into legal paperwork. A lot gets discussed. We talk through what can get built. We discuss time and money constraints. We make recommendations on what makes sense to tackle first. We explain our process: Ship early and often. Iterate. Make decisions as we go.
Eventually, we end up with that Statement of Work (or SOW). It’s usually one to a few pages. Rarely longer than that. It’s a laundry list of what we’re committing to build. “You give us X dollars and we’ll give you a piece of software that does this list of things.”
Then we throw that clause on top. Above all else, it is an acknowledgement that every software effort is to some extent organic and fluid. Decisions will be made as we go. We’ll tilt a few degrees to the left or right to get there. It is not only likely. It is inevitable. We are not going in with a blueprint.
Sure there are SOWs that are extremely detailed. Some are delivered in spreadsheets. They try to account for every single bit of detail. The problem with that approach is it rarely leads to great software. Right out of the gate, it compromises strategic flexibility and hamstrings design. It may promise true clarity and predictability but it rarely unfolds that way. Then you have to share the bad news: “What you’re asking for is out of scope.” Meetings get set up. People are frustrated and sometimes angry. Change orders get drafted. It’s a demoralizing way to build software. It injects an adversarial dynamic to the process of creating something great.
The spirit behind the clause above is to acknowledge and embrace change throughout the software development process. It’s asking both sides to be reasonable and flexible and talk through decisions as we go. It’s going to happen anyway. Let’s skip the out-of-scope dance and get on with adjusting quickly to what makes sense as we work together. It replaces that adversarial dynamic with a collaborative one.
The lawyers hate this sort of thing. Legal language should be airtight. It should cover as many future scenarios as possible. Clauses like this rely on collaboration and trust. Put differently, they rely on a relationship in good faith. Assuming the best is not instinctive for most lawyers — your job is to protect your client.
Putting all this legal stuff aside, this is wise guidance for any software effort. Embrace change and work collaboratively. Great software is really hard. If you’re inside the team, tell everyone else that stuff will change. If you’re an outside customer, empathize and join the dialogue.
In the end we all want the same thing: a great software product.
Rich Ziade is Co-Founder and President of Postlight. Send him a note: rich.ziade@postlight.com.
