Home
Incepto
Building a 0->1 fintech startup as a Founding Designer
My role
At TrustRadius, I was the Lead Product designer. On this project I supervised another product designer and together we worked with product management and engineering to deliver these new product capabilities in 6 months.
Skills used
Product Design
Strategy
User Research
Prototyping
Agile
Excel is the de-facto tool for CFOs and Financial Analysts to build model forecasts. While it’s familiar and ubiquitous, modeling in Excel is overly challenging and frustrating because it wasn’t built to be a forecasting tool. It just became one out of necessity, and because there wasn’t a good alternative. We were sure we could do better.
When the Founder and CEO (and my prior boss) reached out to me about the project, his ideas on how CFOs could better approach financial modeling sounded super interesting — and an awesome design challenge.
Research phase
Talking to users first
The CEO and I interviewed more than 20 CFOs and other accounting professionals before we started with any kind of design work.
Competitive research
I also conduced extensive competitive research to understand where the market had been, currently is, and was heading.
Our "place" in the market begins to emerge
As we began to synthesize the data from our customers, market research, and our core product ideas; we began to see the “shape” of our app and where it could compete in the marketplace.
Prototyping phase
Before starting to build software, we wanted to prototype some of the core product ideas so that we could bounce the concepts off potential customers and investors.
The big story for our prototypes
Our initial prototype was based on 4 real-world CFO scenarios that we felt best represented the pain points we wanted to solve.
After defining our 4 scenarios, we created each scenario as a separate prototype in Figma. These Figma prototypes ended up serving as a key way for our team to collaborate and we referred to them regularly for for the entire project.
The "Tech Preview"
The Figma prototypes were awesome for testing conceptual ideas, but because our app involved a lot of numerical calculation, we decided to build a “Technical Preview”, which was proof-of-concept software based on our Figma prototypes so that we could test how the UI worked with real financial models.
MVP ideas begin to emerge
From our initial ideas, user interviews, competitive research, and prototyping, a few key ideas emerged.
Object-oriented metrics
Users could create “objects” for their metrics (think components in Figma), and these could be placed in a Metric Library (think a Design System in Figma). This allowed users to have central control over all their metrics. These concepts became central to the entire product.
Object-oriented worksheets
Worksheets are built from these object-oriented metrics.
Modeling language
The third major component and differentiator of our application is the modeling language. Figuring out how and why our modeling language should be different from Excel was one of the major challenges we faced and will become a case study on its own!
One super cool feature about the formula editor we created is the ability to autocomplete metrics. Adding this single feature allows users to build models in hours as opposed to days. It is a total game changer!
MVP strategy
The biggest challenge we faced in getting to MVP….was figuring out what a viable MVP needed to be! We had loads of ideas, and a small team to design and build them.
In the beginning, we had a lot of product ideas that all felt important to us. These ideas fell into three categories:
Modeling (what I’ve described so far)
Rolling forecasts (revising and creating new forecasts over time as the future unfolds)
Analysis (graphs, reports, discovering where actuals vary from forecasts)
Over time it became really clear that most of the analysis functionality simply could not make it into MVP.
It was a real challenge to let go of doing all that we envisioned, but in order to get something viable in the hands of customers in our timelines, it's what we needed to do.
We had to focus on our differentiator - building the best modeling tool to create forecasts. We could build the rest later.
Takeaways
A lot of my work on this project has been based on skills I’ve used for a long time (User Research, Design Systems, Visual Design, Prototyping).
My biggest lesson has been becoming very intentional about what features we should work on and extremely pragmatic about how much effort we can put into them.
For example, we drastically reduced the UI effort for the re-forecasting feature in order to ship knowing it was better to get something out and iterate on it later than to spend additional time implementing the ideal UX.
On the flip side, some features don’t need complex UIs, but can take a long time to build. Case in point was our data integrations. This literally took me 2 days to design, but three months to implement.
Keeping design and dev in-sync to build a viable MVP product is hard, y'all!