Though we’re unique in many ways, Appiphony has certain traits in common with most other consulting firms:
- We engage with clients with a specific project as our focus and scope of work.
- We estimate the total cost of that project before we begin the bulk of the effort.
- We want to end every project with the client very satisfied, happily recommending our services to other companies.
Much has been written about getting your customers to recommend you to new ones; this is often quantified as a Net Promoter Score.
To oversimplify, you want customers to rate you a 9 or above on a scale of 1 to 10. And for companies like ours that handle entire projects, it makes the most sense to take this measurement when the engagement is wrapping up.
It’s usually around that time when we reflect on what went well and what we’d like to do differently on future projects. In our retrospectives, we almost always observe a pattern in which there’s tension up front that melts away once we begin delivering, especially if we exceed expectations in some way. We call it “moving up the trust curve.”
We tend to take on projects large enough to split into multiple deliveries (i.e. releases), and each one is an opportunity to gauge client satisfaction. Applying an NPS-style scale reflects how we set the bar high and always want to track towards a strong recommendation at the end of each engagement.
The red area represents the anxiety we notice at the beginning of our medium-to-large project efforts. Once we exceed expectations and deliver at a level high enough to yield a recommendation, we enter a “zone of trust” that has a calming effect for both parties. Also, the progress on the project typically develops a rhythm, like a train steadily moving down a track.
With this model in place, it’s worth asking what we can take away from this and how we can improve in the future.
Deliver SOMETHING Sooner
When we look at the Trust Curve, the desire to minimize the red area is obvious. The most robust way we’ve found to do this is via delivery of a demo-ready, full release code package. That said, the packaging process adds overhead we’d like to avoid when we’re in the red, especially when we’re working on the very first package.
One workaround we’ve used with is delivering an extra “gift” that the client finds valuable, even if it’s not part of the code base. One example might be creating some high-fidelity design concepts with rich visuals that can be used in an executive pitch meeting.
This type of thing starts to relieve the anxiety, but, for better or worse, it doesn’t eliminate it completely.
Deliver More Often
Even as I type this I can hear Agile advocates thinking, “you should deliver smaller chunks far more often! That gets code out the door faster and allows for a change direction along the way.”
We’ve identified at least two reasons why this has never worked for us. First, as mentioned at the beginning of this article, our scope for a given project is defined, estimated, and almost always captured in a legal document. This effectively prevents both parties from introducing any non-trivial change in direction. Jeff Gothelf and others have written about how to restructure legal agreements to move away from delivery of a fixed set of features, but we’re not there yet.
More importantly, the enterprise software we build on behalf of clients does not lend itself to meaningful delivery on a weekly basis. So while it’s true that a login page can be built, tested and packaged in five business days, a software package containing only login can’t be marketed or sold and hence should not be released. It has no economic value.
Instead, we do our best to structure the project schedule so that each week something new is either a) designed and ready to be evaluated or b) built and ready to be tested. Even though this is decoupled from release, it helps move up the Trust Curve. It also works against the anxiety created by a large waterfall design phase during which no code is written.
All that said, once the product gets out into the market, frequent or continuous delivery should be reconsidered. It may very well be smarter to get feedback from the market before diving into the next slate of work on the roadmap.
You Can’t Just Do What’s Asked
If we refer back to the Net Promoter Score, we spot one takeaway that’s counterintuitive.
This point bears repeating: doing only what you’ve been asked does not yield the recommendations we need. It’s well-established in the world of the NPS that customers in the Passive category are highly likely to defect if they spot a “better deal.”
To meaningfully exceeding expectations, we need to include at least one element in the delivery the client did not specifically request. People simply are not delighted by service that only “checks the boxes” on a list they walked in with. If I order a bacon cheeseburger with fries, and that’s what I get, that’s fine, and maybe even good, but not exactly amazing or exciting. If you have to request the mint on your pillow at a hotel, that ruins the effect.
For us, this usually involves integrating the client’s idea more deeply into Salesforce than they anticipated or thought possible. There’s always more than one way to skin a cat, and we typically propose additional feature concepts that extend the theme of the release and add some “wow factor.”
If you’re reading this while on the verge of engaging with us, know that we’re making plans to earn your trust as soon as we can. It’s key to the health of our business that your engagement goes well and you recommend us in the future.