The "Custard" Approach To Software: How Sweet It Is.

Written by Kevin Groome | Feb 23, 2015 12:48:07 PM

According to our friends at Gartner Group, enterprise marketers today are looking for standardized local marketing and DAM solutions that are faster to implement and easier to maintain than previous generations of custom-developed solutions.

Naturally, we agree—which is why we've been focused like a laser on our CampaignDrive local marketing platform. But we also know that many customers still face the reality that a purely standard product may not fit with their marketing workflows and processes.

So, what's a software vendor to do? Hold the line on customization requests, and run the risk of being perceived as inflexible and even arrogant? Or, give in to the requests for customization, branch the product for each client who wants to go their own way—and thereby deny them the free upgrades and feature releases that everybody loves so much about platform products?

At Pica9, we realized that this dichotomy was false. So we embarked on a more open (and frankly, exhilarating) process with our clients, in which we implement features they need as standard components of our CampaignDrive platform—and we share much more openly with them in the adventure of innovating together.

Given the blend of custom need and standard execution, we’ve begun to refer to this affectionately as our “Custard” process. And I’m happy to say that Custard projects have been a huge hit with our clients and our development teams alike.

Here are a few reasons why:

First, the collaborative approach saves clients money – often, lots of money. That’s because, on Custard Projects, we ask clients to fund only a small portion of the costs for the design, architecture, coding, and testing of the component. That means clients save thousands, sometimes tens of thousands, of dollars getting the feature they need.
Second, we've found that Custard Projects encourage both sides to take a longer-term mindset. That means issues of scalability and maintainability play a bigger part in the early design conversations—which is exactly where they should be. Contrast this with purely custom projects, where nuanced features and details of the user experience tend to dominate planning discussions, often putting those fundamental issues in the back seat.
Third, the Custard approach makes everybody more comfortable about releasing software in smaller, more frequent cycles. Instead of trying to jam every conceivable feature into the first release, we're all encouraged to get working software into the hands of our users, so we can learn from them and refine the feature based on evidence, rather than mere opinion.
Finally, and most importantly, the Custard approach seems to engender trust. Our clients trust that we care deeply about and can adapt our product to their changing needs. But they also recognize that we care, and we know that they care, about the enduring quality of the platform itself. The Custard approach makes us both stewards of the same code base, and partners in the truest sense of the term.

In the past six months, we’ve engaged in four Custard projects for feature releases on our CampaignDrive product, with three more in planning today. We’d be fascinated to hear what other vendors and clients are doing in this regard, and whether your experience is similar to ours.

There is still much more work for us to do, as we iron out the important issues of product review, application governance, and minimizing risks of feature bloat, among many others. But even in these early days, I can say that the Custard approach has been satisfying indeed.

View full post