What happens when you iterate on one feature for a year?
It’s rare to see the underbelly of enterprise software development. Behind every CEO’s story of success lies weeks, months, years of iteration, bureaucracy and (mis)communications.
I worked on the product team for a FinTech web-app for a year. While we uncovered many user insights and shipped many features, we returned to one critical feature again and again.
The Problem and Solution
The value proposition of the app was straightforward. For those living paycheck to paycheck, struggling to be prepared for unexpected financial shocks, the app allowed people to access their paycheck in advance.
The critical feature was thus: The app could tell when your rate of spending put you in jeopardy to pay off your bills, or when you had a surplus so you could save.
This was a suitcase feature, which is what I like to call a feature with many risks, unknowns and dependencies. A suitcase feature needs to be unpacked. We knew that understanding requirements for this feature would be high complexity and high importance. We prioritized this as our first major project.
The very first thing we needed to understand was how our target customer thought about their finances. How does the user (who we called Jonas) know when they’re in a cash crunch? Do they know? How can they tell?
We ran several card sorts to unpack how Jonas prioritized financial information to make decisions. Our 1.0 of the Cash Flow Visual (internal title for the feature) was a literal interpretation of this information.
We shipped this feature to a lukewarm audience. Many questions were raised. Onboarding did not including gathering data to generate this information. How would we be able to motivate Jonas to tell us about his bank information and bills?
As we built features to enable Jonas to provide financial information, we also integrated the ability for Jonas to take an advance from his paycheck from a partnership with another FinTech company. We wanted to validate if Jonas understood his financial situation and the recommendation to take a cash advance to mitigate the situation, if necessary.
The response was again lukewarm. The numbers were not understood. The call to action was unclear. We needed to regain our footing. We ran a Google Ventures Design Sprint.
New information surfaced. A data analyst at the company modeled an algorithm that understood Jonas’ finances in more nuanced terms.
Pay periods and rate of spending were added to the mix. This presented an even more complicated design challenge.
We ran interviews and workshops with financial counselors and programs managers.
We centered around the idea of presenting a straightforward recommendation and revealing detail when necessary. This seemed to spark positivity from our users for the first time.
Nearly a year after our initial explorations, we debuted the product to the press. I applied the company’s branding and typography to the app, a sign that the company was ready to say it was their product.
Lessons Learned
Relying on consensus instead of a shared vision.
While the team had always rallied around the problem, the solution never felt clear. It was difficult for stakeholders to articulate their vision, only through negative reactions to earlier iterations. I would work with the Deciders directly next time, extracting their vision into the first MVP to validate and gather learnings.
Being wary to knee-jerk user requests.
I think the financial domain is especially tricky to navigate. When we started on the Cash Flow Visual journey, we prioritized and built purely to user requests. I would have learned as much as possible from SME’s and conducted diary studies with users, not interviews and quick reactions.
Space to breathe and reflect.
We put pressure on ourselves to move fast and break things. It’s hard to really know how to fix your broken things without really understanding what went wrong. I would have created more space for learning and understanding and less space for building and the demons telling me I had to make every minute productive.
