Domain knowledge is important; however, even more important is domain experience. With domain experience, you learn where the bottlenecks and pain points are in your workflows.
During my time as an interest rate risk analyst, I had the displeasure of working with a horrible piece of software. It crashed at the most inopportune times, usually near the end of a run. Considering that one run could be on the order of a few hours, you could lose a significant portion of your computing time, something in short-supply when other business processes don't get you your input until seven to ten business days within a new monthly reporting cycle. When it did finish, the probability that there was a problem with the final output was much larger than it should have been. Furthermore, the software could not even be used for actually analyzing your results. You still needed to dump out the calculations to Excel before finishing your analysis.
On the surface, it would seem that the hardest part of solving this problem would be implementing the software as it's a highly specialized area of finance with lots of mathematics. When you break it down, however, what needs to be done on the software side is pretty straightforward.
I had to document this stuff for regulatory purposes at my old job. To document this stuff, I had to do a lot of "reverse engineering" of this software, basically building in Excel the same calculations performed by the software. If any person or group of people near Mountain View are looking for a problem to solve, I'd gladly sit down with you one evening and answer questions about this space.
During my time as an interest rate risk analyst, I had the displeasure of working with a horrible piece of software. It crashed at the most inopportune times, usually near the end of a run. Considering that one run could be on the order of a few hours, you could lose a significant portion of your computing time, something in short-supply when other business processes don't get you your input until seven to ten business days within a new monthly reporting cycle. When it did finish, the probability that there was a problem with the final output was much larger than it should have been. Furthermore, the software could not even be used for actually analyzing your results. You still needed to dump out the calculations to Excel before finishing your analysis.
On the surface, it would seem that the hardest part of solving this problem would be implementing the software as it's a highly specialized area of finance with lots of mathematics. When you break it down, however, what needs to be done on the software side is pretty straightforward.
I had to document this stuff for regulatory purposes at my old job. To document this stuff, I had to do a lot of "reverse engineering" of this software, basically building in Excel the same calculations performed by the software. If any person or group of people near Mountain View are looking for a problem to solve, I'd gladly sit down with you one evening and answer questions about this space.