Product Reports
One thing that I do aggregate on a monthly basis are reports about each product that I manage. I then make this information available to all members of the management team for their review to aid them in decision making and progress tracking.
These reports are all tied to product-level objectives set out within each product plan / strategy. Of course, in order for an objective to be effective, a metric is required in order to measure its success or failure. When you first start out with this, it’s natural that you won’t have a lot to go on, so I’d recommend to pick some obvious metrics to measure product success.
Two that I get a lot of mileage out of are:
- # of New Customers
- # of Lost Customers
These serve as an effective way to track product churn and help finance to accurately measure customer acquisition costs and retention costs.
In addition to this, I’ll leverage my ongoing product schedule to track the following:
- Product Revenue (Gross)
- Product Cost
- Product Net
I use standard, typical numbers to use for cost tracking: 1 resource at 40 hours per week at $50 per hour. This nets to approximately $2,000 per week, per person you have working on product. Since I schedule on a per-product basis, it’s simple to acquire the rough number when you have a release cycle going on.
So, if you have 2 developers assigned to a release cycle on Product A, Product A then has an associated cost of $4,000 per week. For 1 month, that nets to ~$16,000. This value then gets deducted from total product (gross) revenue, and you are left with product net income.
One other key metric I track per product, which is more of a long-term thing as opposed to something immediately useful, is # of defects assigned per product each month. Since Support reports in to me, I also have them create a weekly report giving me the number of inquiries they dealt with for each product. This type of data can be a savior if you are attempting to gauge the success of a product upgrade, as well as plays a key market data role.
While this seems like a lot of metrics, it’s really not. It may take me 1 hour per month to compile one of my reports, and it is useful for stakeholder’s when making decisions. One thing start-ups can lack is effective data, and executing based on effective data. It’s a fine line between capturing useful stuff and becoming to process laden. However, to be effective, everyone needs to stay on the same page.
Another point here, if you have been reading closely, is that I use the term “product-centric” a lot. There is a reason for this, but that’s a whole other post…
April 16th, 2007 at 1:45 pm
This is very cool stuff Adam!
Have you thought about tracking “cost of quality” as an extension of number of defects? Perhaps you can track support-time spent on defects. You could also track dev time spent resolving defects (versus new features). Not sure if you can directly correlate lost customers to defects, but it might be interesting to see the relationship.
Great metrics, just thinking out loud here.
April 16th, 2007 at 4:32 pm
Scott -
Thanks so much for the comment!
These are fantastic ideas. Tracking customer-based results against product quality could lead to some very interesting things…
April 21st, 2007 at 7:51 pm
@Adam
I’m not that focused on product revenue right now (others at my company are, but I have a laundry list of other priorities), but I do run an analysis of win/losses at quarter’s end.
I have a standard report that I pull out of our sales automation system with details about each deal ($ or estimated $, incumbent, who we were up against, what the prospect’s problem statement was, etc). I then write up a summary and provide some analysis about both the wins and losses and send along to the senior management.
This gives them some visibility into what I am tracking and provides a channel for dialogue on product strategy.