Why no one cares about your fancy spreadsheet & how to change it: Design Thinking approach on financial modelling

Throughout my career, I have built hundreds if not thousands of models on Excel spreadsheets, and have seen equally number of terrible spreadsheets - well, basically most spreadsheets built by other people are considered terrible, sounds arrogant, however, I’m sure a lot of you would relate to this.

It was until recently, I realised a major flaw in my approach towards model building. Earlier this week, I built a model that helped me to assess different return potentials of some investment opportunities I have been considering. The same evening I shared that with my partner who immediately loved it, and adopted the same model for his portfolio. He also started giving me feedback that I didn’t ask for. My initial reaction was “I can tell you really don’t know how spreadsheet works”. Just seconds after I had that thought, something struck me. 

Being a product and pricing person, I worked a lot with IT people, developers and engineers. A very frustrating thing that I faced a lot was whenever I shared feedback, they would often come up with millions of reasons why it is not going to work, or why they think their approach is better. In my mind, I would be thinking “come on you technical people please go out and talk to the customers”. No one would use the product if it is designed that way. 

Now let me come back to what struck me. At that moment, I felt I was playing the role of an arrogant technical person, who probably knows better about the technicality of things, but did not consider how the product (the spreadsheet) will be used by other people. I was having a rant about why things should be built the way it was, as it enables the formulae to flow through nicely, and quick to update - from my own perspective. It was really an ah-ha moment for me. Not only did it explain why we all hate other people’s spreadsheets (because it was not built the way we like or used to, good or bad), but also inspired me to come up with an alternative. 

If you work in the field of product development, an approach that has attracted a lot of attention in the past 5 years is Design Thinking. I hate buzzwords like this, so let me re-quote from my ex-colleague, the UX designer Hanny, “Design thinking is a problem-solving methodology based around empathy and experimentation”. The methodology re-frames problems in human-centric ways, and helps the designers to focus on what is the most important thing for users. It is an iterative process but in general, involves 5 stages:

1. Empathise: This is the very first step, with the aim to develop an empathetic understanding of your users’ problems, or pain-points as what they are often called. It is done via user research. Depending on the time and budget, there are various ways you could conduct your user research. When I was working with Telstra, we went on the extent of actually going to users’ houses, sat there with their families and observed and listened to how they used their products. In my startup days, we did this via user interviews, where we sat down with a list of questions that we got our users to answer. The most important part in this stage is to understand the “why”, as very often, users might indicate a problem which has a deeper rooted problem associated with it. 
2. Define: This step is a solitary exercise. You would typically just go through your notes and try to categorise things from various user interviews. You could label problems by its severity - how many people reported the same problem? If I don’t solve it, is it easy for them to resolve the problem themselves? The end goal is to have a list of problems that you need to solve, prioritised by severity. 
3. Ideate: Now we are on the problem solving part. In this part, you would re-visit the problems you have defined, and come up with innovative ideas to solve them. Again, depending on time and budget, you can host a fancy ideation workshop, where you involve people from various parts of the business to bring in different ideas, or you can just ideate yourself.
4. Prototype: Based on the ideas generated, you would build a very quick-n-dirty product, with the aim to test and revise. Remember this is an iterative process. The most important thing in here is that you want to be really quick as the first couple of prototypes are likely to be very different to your final product, and you just need something good enough to convey the concept, but not the actually look and feel of the final product.
5. Test: Here you would invite people to test out your product prototype, and based on their feedback, you can go back to any stages of the process until you reach something that is satisfactory. 

Design thinking is a very common approach that often got used to developing a new product, and I was very eager to test whether I could use the same approach to solve my spreadsheet problem. I jumped on the opportunity when my partner asked me the next day to help him build another model to manage his portfolio, little did he know I just wanted to test my new approach. 

Some disclaimers, even though I have adopted this approach many times for product design, I have never followed such a rigorous approach when it comes to building a financial model. It is something I am testing out for the first time, and I am sharing my thoughts here, not to provide you with the holy grail of financial model building, but to share the experience and hope to collect feedback from those of you, who might want to give it a try when you build your next financial model.

In my opinion, empathise and define are the two most important stages. During my 30-mins “interview”, I have discovered so much more about the needs of my partner. More importantly, I feel he has also benefited a lot by talking out loud about what he wanted. The interview questions challenged him to think about the rationales behind certain decision. Also a few times during the process, he realised that what he said he wanted was actually not what he really needed - imagine the time saved just by having all this cleared out before you even touch your keyboard.

Ideation in my case involved me drawing something out on a piece of paper, which is a good practise I think any modellers should do. However, there is always this temptation of just wanting to build it on excel, and I am very often a victim of that. Even a slight thought of “I will just build a quick and dirty one” should be avoided, at least for someone with OCD personality like me. Very often, once you touch the keyboard, there is no more quick and dirty prototype, you would get carried away and before you realise it, you already spend way too much time on it. A hand drawn skeleton to demonstrate the concept is a good enough prototype, don’t invest more time on it until you finish your first testing with the user.  

Of course, in my case, I have ample time to just try and test things out, but when you adopt this approach for work, it is wise to consider the cost-benefit of investing time. If your boss just wants a back of envelope calculation, I wouldn’t go into the extent of conducting user interview or ideate. Hope that makes sense.

Then the rest is about how “perfect” you want your model to be, and you test, ideate and repeat as the methodology suggested. I’m a big fan of 80:20 rule, so my model is never perfect, but it is good enough to help me to make sound decisions. 

This is all I want to share so far. As mentioned, keen to hear your thoughts. Drop me a PM if you want to discuss more.