Originally published on LinkedIn, John’s Corner is where Fortimize CEO John Hamon shares the perspectives, challenges, and hard truths he sees from the front lines. View original publication.
You Can't Spec What You Haven't Seen
The first thing a bank signs with us is not a list of features. It is a list of outcomes, and an agreement to work out the details together as they learn what the Salesforce platform can do. People expect a specification, thick enough to know exactly what they are buying. That is not what we hand them. What stays fixed is where we are going. What stays open is how we get there.
The first time a client reads that, some of them get quiet. They came to negotiate scope, line by line, because a locked scope feels like protection. If every requirement is written down and signed, no one can move the goalposts and no one can pad the bill. The airtight specification is the document most likely to blow a bank’s budget and timeline. The open one is what protects it.
The decision made too early
A requirements list asks them to make their most binding decisions at the moment they understand the least. A head of lending can describe exactly how her team works today. She cannot tell you how she will want to work once she sees what the platform makes possible, because she has not seen it yet. Neither have I, not for her bank, not on day one. The only real choice is who carries the risk of that not-knowing. Pretending the risk isn’t there does not remove it. It just decides, quietly, who pays for it.
Lock It down, or run the meter
Diligence and drift are opposites. They should not arrive at the same dead instance. To see why they do, you have to find the belief underneath the careful bank’s plan, because the plan was internally rational. The belief is this: users adopt systems because systems are good.
Almost everyone in enterprise software holds some version of this belief, and almost nothing in the history of enterprise software supports it. Good systems sit unused in every bank in America. Mediocre systems get used hard for decades; ask anyone who has tried to pry a core processor or a shared drive out of a branch network. Quality is not nothing. But quality is not what converts a tool into a habit, and a CRM that is not a habit is not a CRM. It is a data entry obligation that loses to whatever the banker did yesterday.
Lock it down, or run the meter
The industry has two standard ways of deciding, and both put the bill on the client. The first is the fixed-scope contract. Sign the spec, lock the requirements, and the moment the client learns something new, which is the second week, that learning arrives as a change order. Every improvement becomes a negotiation. People stop asking for what they now realize they need, because asking is expensive, and the project ships the version they understood least, on purpose. The second way is time and materials. No fixed scope, the meter runs, and the client carries the risk as open-ended doubt. No one can say when it ends or what it costs, so confidence drains out of the room a little more each month. Neither is built to let a bank change its mind, which is the one thing every bank will need to do.
Every snowflake has six points
There is a third option, and it starts from something most consultants resist saying out loud: banks are far more alike under the hood than they believe. Every institution is sure it is unique, and on the surface it is. Its brand and its market are its own. But deposits, retail and commercial lending, referrals, the call center: these run on nearly the same structure everywhere. Every snowflake is one of a kind, and every snowflake has exactly six points. So we stop handing clients a blank sheet of paper and asking them to design a system from nothing. We show them a working model of what is possible, the way a model home shows a buyer what a floor plan feels like to walk through. Reacting to something real is easy. “I want that, not that, and let’s start here.” We fix the outcomes, show the model, and let the bank set the order of the build, sprint by sprint, changing its mind as its understanding grows. The destination holds. The route bends.
The tell is excitement
You can tell early which way a project is going to break, and the sign is not in the status report. It is in whether people are excited. When a team sees working software in week three and gets to steer where it goes next, they lean in. They start asking for more, because more is now theirs to shape. When a team is waiting on a spec to be perfected before anyone touches it, they brace.
I watched this hold at a community bank we launched this past spring. We went live in weeks, not months. The head of retail did not have to be pushed into the system. She pinned it to her desktop, set referral rules with her managers, planned scavenger hunts to get her branches living in it, and within weeks was asking us what we could add next. The Salesforce account executive on the deal, unprompted, told her this was not how most of these go. He had another customer who bought the same software 18 months earlier and still wasn’t live, because they were still trying to make it perfect. Same product. Same year. Opposite outcomes.
Before you sign
Here is the question worth carrying into your own project, whether you are buying software or selling it. Look at what gets signed before the work starts. How do you know what the solution needs to be when you haven’t yet modernized your processes? Does that scope nail down a system no one has used, or fix the outcomes and leave room to learn? The first approach feels safe and isn’t. But when was the last time one of those SOWs delivered anything other than a false sense of security? While the second might feel risky, it is the only kind I have seen come in on time, on budget, and then actually get used.
