Tags
product
Published
July 27, 2023
Ok. Product Capitalization as a process sucks.
But also, product capitalization has a weird and beautiful sense of completion and structure. When all the hours of each developer match throughout the whole year, across all projects, it's a sense of accomplishment like watching a really dirty car get cleaned with water pressure.
Jokes aside,
That was my 1st capitalization process, and I think it's actually a valuable exercise for tracking the development of your product and making better decisions about how to allocate your resources more effectively. Key takeaways of this process where:
- Google Sheets - I remember our love-hate relationship with it from the marketing days.
- Finance people are excel GODS, especially our CFO @instacar , K. Samartzis.
- vlookup is your friend
- If you don't have a structured process for tracking your sprints (or cycles), you're going to have a hard time keeping track of your capitalization costs - obviously I learned this the hard way
Mistakes to avoid when making your 1st Product Capitalization report:
- R&D costs are not capitalized. Prototype is not an asset, is just part of the research process
- Only salaries of development team, testing team and some indirect expenses and testing costs can be capitalized (perhaps technical architecture f.e).
- Product development is an ongoing process. and it's important to track capitalization costs separately from software maintenance costs when the product is live. Capitalization costs are incurred when you're developing new features or functionality for your product, while software maintenance costs are incurred when you're fixing bugs or making minor changes to existing features. Rule of thumb to easily keep track of the expenses is
Capitalisation = Total developments costs x (Hours for new feature development / Total hours billed).