Dogfooding Bank Software
Dogfooding is the practice of using your own products. The term comes from marketing slang - “will the dog eat the dog food?” - shorthand for the idea that the product may be amazing, but ultimately, it only matters if the consumer likes it.
Dogfooding was made famous at Microsoft, but has spread well beyond Redmond, Washington. Lots of companies dogfood their products now. Some choose more palatable imagery. For example, Siebel Systems calls it “sipping your own champagne”.
Whatever you call it, the thought is right. Otherwise, the annoying nuisances in the product never completely go away.
There are a lot of steps to making great software. Start with deep experience in the field. Beta tests help. User testing is even better. Usability experts add to the mix. But dogfooding nails it.
The problem is, dogfooding is tricky in enterprise software. How can a software company truly use banking software? After all, we don’t run a bank.
There are only two steps I can think of and one was a fluke.
- Start by ensuring clean implementations. Taking responsibility for bringing each customer aboard pushes you to work with the software from the customer’s point of view.
After 10 years of experience at one of the best banking software companies in America, our Client Services VP has the customer view nailed down.
I got to know Randa first as a ALCO software customer. She had built a 20-person Client Services team that provided better support than I had from my parents. But Randa kept her ear to the ground, contacting customers to find out their experience directly.
Randa has continued that same approach here - and is always looking for ways to make the software work just a little easier, faster, smarter. But it’s just a lot easier to catch issues in the areas you work on directly - and her strongest feedback to the developers has been in the areas touched during implementation.
- Work as a service bureau. We hit this one accidentally, but it’s been fantastic.
We recently partnered with a service bureau to supply printed deposit pricing reports for smaller banks. We knew that there would be new, unknown issues in using the software with smaller customers. So we have been building the first reports internally to ensure high quality. We inadvertantly dogfooded the rest of our process.
Very interesting.
Here’s one small example: reports.
We’ve received very positive feedback on the way we output data. Just yesterday, a user complimented this specific feature over lunch.
All the numbers flow through pre-built, colorful Excel PivotCharts. The figures are graphically-oriented and clearly understood. Users get to arrange data as they like, drill down, trace data to the source, or even pull the numbers out and make entirely new reports in Excel.
But the service bureau customer is the deposit pricing committee. They don’t have the software and don’t need the flexibility of PivotCharts. They need a clear narrative, linking together multiple reports with commentary. They need a case for making certain deposit rate moves.
We realized this committee is the end customer in every bank. Any functionality towards building comprehensive reports makes our users’ lives easier too.
I once attended a seminar on industry best practices for ALCO reports with 40 of my peers. Trust me, we all drank extra coffee that day. If there’s anything that can force me to attend a meeting that dull, it’s having to explain a convoluted chain of logic to a room full of busy bank execs.
The lightbulb went off years later during our recent dogfooding. Our software needs to pull multiple charts and tables together with notes guiding the reader through the case for optimizing to certain rates. The user (in this case, us) should not have to assemble this every time he builds a deposit pricing report.
I believe this functionality is new to the entire banking software industry.
I’m pretty sure our users are going to like it - it’s definitely a big win internally.
Next: Dogfooding the bank
Bookmark to:
Great move getting Randa, and I concur with everything you said about her. Please, do not let her skim all of the cream from her former employer as I still need them for a litte while, at least.
In many ways, we make our livelihood by “sipping our own champagne” (i’ll take this phrase over the other for psychological/framing reasons - hey every little bit helps!). In our case, implementation at a bank is part of a “consulting” engagement by our staff working in conjunction with client staff to ensure a large ROI up front - typically a driving factor in the business case. In the process, their staff are mentored and trained on a real life usage scenario - the implementation itself!
So that pretty much ensures a clean implementation, however, does it necessarily allow us to see the use of the software from the customer’s point of view? I would suggest that there is an added sublety - you must see it from the customer’s point of view and from the context of the customer’s typical use. Implementation “use” is not always the same as day to day use. Something to keep in mind.