What Kind of Tools I am Building

I am building tools for the Office of the CFO. The Office of the CFO is essentially a term that means any department that reports up to the CFO. This is obviously accounting and finance related tools, but depending on the organization, it can capture other departments as well (e.g., Legal, Credit, Risk, HR, BI). The Office of the CFO consists of back-office functions that help support the production, sales, and distribution arms of the company. When done right, they are a strategic benefit for the whole company.

I want to build tools that support those functions. These are essentially tools that I myself am a user of at Athena, but also the tools I wish I had at GPS. Geared mostly toward accounting and finance functions, these tools are meant to take things that are commonly done in Excel and put them into a platform that will help secure and automate those processes. This will include things like fixed assets, prepaids, and leases. I am not going to focus on FX/payment tools.

While most of the tools I will build already exist, they are enterprise-level solutions. They have a ton of bells and whistles and features that most companies will never use. The onboarding requires special implementation teams, and the tools are not intuitive to use. Oh, and they cost a lot of money that will usually require board approval. For someone who just wants to get off of Excel for something like leases, this is all a lot and will prevent them from ever leaving Excel. It is really only the large enterprises that need and can afford these existing tool packages. I will focus on the small and medium sized companies; companies too big for QuickBooks, but not at the SAP/Oracle level.

The plan is to also build a whole suite of tools. I want to build about a dozen or so tools that any company can and will want to use and package all those tools together. There is no product roadmap. While I have a good idea of what tools I will build, I will make the decision of what to build as I go. I want to be able to stay flexible. A company might want to use one of my tools, or they might want to use all the tools. I am not exactly sure which tools will resonate with people, so part of my approach is to offer a wide array of tools and see what sticks. All the tools will be what I want to use (I'll eat my own stew), but I am casting a wide net as to what the market will want to use. I also want it to be valuable to the end users; when I package them all together, I want them to get a lot of tools for a low monthly fee.

Part of the approach to cutting all the bloat in these software products and making them easier to use is focusing on convention over customization. While some users want all the customization in the world, most just want to adopt the tool, spend as little time in it as possible, and move on. While these tools will not be able to handle every edge case, they will get the job done for most companies, especially the average company. Most software gets bloated because they have a few large customers that request features, and because those customers pay so much, they have to make those changes. Software can also bloat because you have people in the company (most of whom don't even use the software) that invent problems they want to solve. Because they spend a lot of time in one area, their imagination goes wild with all the things they can do, and if left unchecked, it creates feature bloat that will crush the end user.

Because there is so much bloat, it is hard to onboard with these tools. It requires a lot of handholding (or sometimes the company selling the software has to do it for you) to get the tool usable. Sometimes the tool never gets to the point it is usable and the product implementation dies. Other times the product is usable, but only one person knows how to use it and you hope nothing happens to that person. For most, when you log into the system there are so many options you don't even know where to start. It is hard to play around because you might create permanent entries that will stay there forever, or you have to onboard a whole other time to test around the features. For some reason almost every other industry has gotten the message about intuitive usability of tools except for accounting and finance tools. My goal is to make the products intuitive enough that there is no onboarding team. Perhaps aided with a product walkthrough video, the user will be able to open up the site and easily be able to use it from there.

For all this, I plan on coming in at a very small price point. The company is just me, so I don’t have to make much to support myself. Part of the reason I don’t want to raise money is that once you raise money, you have to grow quickly for your investors. You have all this extra money, so you naturally use it to hire people. Then, you have payroll to worry about. There is a ticking time bomb that once the money runs out, you either have to have enough sales to cover payroll, fire people, or raise more money. Soon enough, the founders are not even thinking about the right product; they are worried about how to cover payroll. If I keep it simple and small, I can build the right products, and I don’t have to worry (as much) about making it overly profitable.

I will have a simple fee model as well. One of the things I hated at GPS was onboarding with a tool at a reasonable price point, only to watch the fees for that tool balloon into ungodly amounts of money given what we were getting. I hate fee creep. Usually, this is because the software charges per head, and the more people that use it, the more it costs. A few things can happen because of this. Maybe you start sharing passwords so as not to create new users. Maybe you centralize all use of the tool with one or a few people, but then that person is overworked running reports and functions out of the tool. Maybe you sign up at one price point, just to find that as you use the tool you need to upgrade to receive the features you actually want or use; the features you need are behind another paywall. Or, in a lot of cases, you start with a deal that you think is fair, and as the company grows you are stuck with a tool that everyone is using.  Now you cannot easily leave because you are integrated into the software, but you are paying multiples more than what you originally signed up for. Simple fees, no blocked features, no surprises.

Also, I don't want uneven clients. I don't want some clients that pay a lot, and some small clients that are so small I don't care about them. I want every client to pay the same, so they all have the same value. This will democratize the clients at the company, to where they all have the same worth. Also, I can sleep better at night knowing that there is not one client that is responsible for majority of the company's revenue. I want to keep my fee a flat fee per company. 

Once all this is put together

Lastly, the tool is for the Office of the CFO, built by a CFO. For a lot of B2B companies, the product decisions are made by the tech team, not the end user. It is really hard for a product manager to know what an accountant actually needs because they have never made a journal entry before. They can interview clients and salespeople, but they really don’t know. If there is no product manager, then usage decisions are made by the developers or the salespeople. No other company in my space will have the design person closer to the product than at Athena. The end user (me) will be the one coding it. Having the users of the product make product and design decisions will always be part of our DNA.