Building products or software as a cooperative can often be a completely different ballgame than building them as a business. There are similarities on the most basic of levels, but our intent and goals vary greatly. A business’s bottom line is to make money and that is what motivates them to create successful products, whereas we work in the best interest of our credit unions and members.

There are multiple approaches behind how we strategize building new software. Do we design for the many by taking a general approach or do we focus on the specialized needs of each credit union? Do we build for goodwill, and if so, how do we stay within our own bottom line? How do we as a cooperative determine which approach will have the best outcome and ensure all of the above first and foremost benefit our credit unions?

Building for the many

Managing these varying strategies can be a balancing act, but it often comes down to the specific product being developed. Are we building and investing in a specific application? Does a credit union working in a specific line of business require a tool to dramatically specialize to differentiate itself in the market? And in that vein, how do we talk about building a tool that applies to three million members and recognize that the evolution of the tool, it might get more granularly specific and only apply to one hundred thousand, fifty thousand, or even ten thousand members over time? 

Ultimately, the advantage falls on the side of building and planning a product for the many, and this is the strategy our CUSO tends to stick with. We often develop software with a wide scope to start and eventually work to tighten up, specialize, and enhance it for the needs and ideas of the few. The reason being in time, we have learned that if you build for the few—say a hundred people to start—the chances of growing that audience to ten thousand is much harder than if we start off by building for the ten thousand and then narrowing the scope.

Furthermore, we have seen time and again that every credit union will have its own use for the software and its own needs to fill. Creating a broad product allows for each credit union to utilize the tool in a way that works for them. From there, we narrow down the focus and customize the software for the few by accepting feedback and adding additional features and toolsets.

Consider configuration options in online banking as an example. It had a generalized approach to start, but we are adding different feature functionalities all the time. With this strategy, we are able to add only those tools a subset of credit unions need, rather than building it with a hundred different options and features in which we might never see more than a quarter of those features being used.

Adding that customization from the base product is a really powerful approach and gets the product out into the members’ hands, which allows for the chance to gather feedback, hear the difference between what was a home run and what did not work as we anticipated, and in the end, improve our software in a way that supports our credit unions.

Building for the few

On the other hand, there are times when we do build for the few with the intention of creating opportunities for the many. This strategy typically arises when our cooperative works with a credit union or business that specializes in one area and has a specific need to be met. We will design and build software for that one credit union and then find ways to make the new product, toolset, or feature accessible and useful to a wider audience.

Consider business banking. We originally developed it for a handful of credit unions, but with the intention of making it available to the many who had yet to dive into that sphere in the hopes they would become engaged in business banking.

In this case, we design a much more specialized product from the get-go and have to essentially work backward to make it applicable to other credit unions. For example, we recently worked with a credit union that specialized in the participation of consumer loans. This credit union held a much larger loan portfolio than many others in our network, and we were challenged with developing a product to meet those needs. Eventually, we redesigned our existing tool to increase its capabilities, and this change went on to benefit the rest of the network. By enhancing that tool, many now had the opportunity to easily manage more loans and create a larger portfolio. A successful case of designing for the few and expanding to the many.

However, when introducing such specialized software or enhancements to the network, a certain level of marketing and support is needed. In essence, we need to develop a playbook for how credit unions can implement these new products and how we can cultivate excitement for these updates. The key is figuring out how a tool can complement a specific credit union’s needs and then offering a plan for the implementation of said tool and best practices for doing so (balance sheet, policies and procedures, etc.). How we can help an institution with a playbook is always really important, especially when talking about taking it from one to many. How can we share success stories? How can we share opportunities or ideas?

The importance of a collaborative network is trying to understand when we have something available that would benefit many in the network and sharing that knowledge, information, and those opportunities. Many of the successes of CU*Answers and the cuasterisk.com network, in general, came down to having a diverse community of credit unions that do things differently, and bringing them closer by facilitating the sharing of their knowledge, practical experiences, and best practices of the products and services between them. 

Building for goodwill

As a cooperative, we operate differently from other companies in that we don’t work strictly for profit. Our goal is to support our credit unions, and in the spirit of that, we also design products and software to be given away either at a very low price point or for free with the hope they will benefit from it. But building for goodwill, while valuable, is not quite so simple and cannot always be done. It requires balancing how much goodwill we can do while also meeting our bottom line. It is a fine line to walk.

The general rule that we apply when making this determination is our ability to develop software for goodwill depends on what the ongoing support costs for the product are. With online credit cards, there are always changes going on in the network from a regulatory standpoint or otherwise. We are always talking about adding new features such as card controls, promotional buckets, analytics, and then specialty and promotional codes behind that. 

As far as that cost is concerned, continuous maintenance costs and software additions require us to charge something, but we look at all the various ways that we can leverage a single application, a single toolset, or a single specific item within our software that can generate a little bit of revenue so we might have the opportunity to bring costs for the credit union down significantly or even to zero. Additionally, there is a lot of other software we don’t charge and we never will. Because, when all is said and done, unused software has no value. If a product is not out in the street being utilized by a credit union member or credit union staff member, then it has no value. With this approach, we have created an opportunity to generate revenue for the network, bring the cost down, and reinvest it to build bigger and better things to benefit our credit unions.

Building to benefit all

No matter in which method we ultimately choose to develop software, we always do so with our credit unions and their members at top of mind, as is our responsibility and goal as a cooperative. While we tend to see the greatest merit in a general approach over building with a narrow scope for specialized needs, we do not shy away from those challenges and how we might make such software useful to the whole network, nor opportunities to build for goodwill. In the end, the advantage of being a cooperative and being part of a network is the chance to share our ideas, wins, and lessons with one another so we might all succeed together.