I'm an ISV myself, and I created it based on my needs. If you take a look at the planning tab, you'll see that it's not how you think it is.
It's simple:
1. You add a deadline by which time you expect some particular featureset to be completed (for example, the user interface)
2. The you add a bunch of features to that deadline (like toolbar, about box, etc).
3. You have a series of tasks for each feature that need to be completed like a standard todo list
Normal planning does not work for ISVs. But the approach above works (for me at least), because it allows you structure the way you approach your coding. It's not about traditional planning in any sense, it just a way of organising your todo lists in a manner that fits with the way that ISVs approach their products.
So, the product is another to do list? Maybe I'm missing something, but I can't see how this would benefit us any more than another to do list.
Have you been designing this product to match the requirements of an existing software company which is selling product today, or are you trying to match the requirements you think you will have once your planned product sells?
The product(s) it's designed for are selling today.
If you have an entire process setup already for planning your software development path, and you already have a well working analytics system, then your products are already being managed, and you don't need this.
This product is designed to bring an efficient structure into the life of the ISV. Processes are there for a reason - they make it so you don't have to guess what comes next or what you have to do next. This product is designed on that principle - it takes the random life of the developer and makes it efficient.
There are two ways one can approach the software business - you can either just do things randomly as they coming, and hope things work out, or you can plan ahead, observe trends, iterate and optimize to grow and make more money. This product is designed for people who want to take the second path.
Well, businesses definitely need structure, but I don't see how this particular product would help me observe trends (aside from web site page views and total dollar sales), iterate and optimize.
Perhaps if there were a case study of some sort up on your page? Right now, it just looks like a to do list stitched into Facebook, and that's not what we're needing.
I don't know how many products you sell, but let's say you sell about 4 products. You sell roughly 6-7 copies a day, and you site views are about 1500 uniques a day. Now, you nee to keep a constant eye on these numbers, and you need to do things to make these numbers go up, and not down.
If you work without structure, it's difficult. My tool is designed such that you can take a look at the frontpage and you instantly see how everything is performing.
The todo list is a standard todo list (like basecamp has), but the fact that you can keep your product based todo separate from the rest of the usual todo is helpful. When a product is cruising along fine based on trends you observe, you can ignore the product from a business point of view. When things start getting bad, you have a todo list you can refer back to.
How will your product "do things to make these numbers go up, not down"? If all your tool is letting me do is count web site page-views and total dollar sales, that's not going to help.
That part I did not add to the screenshots :-) If you click on the last tab "Strategy", there are 3 icons beside the 'trends' icon. Those pages contain the steps that one takes to increase the page view, download count and so on. The info that is taught in business school is broken down into a form that makes sense for the internet, and that will surely make you more money if you do things steadily and step by step.
I decided against putting up the screenshots of that part because there are too many pages, and I've not completely fleshed out the concept yet.
It's simple:
1. You add a deadline by which time you expect some particular featureset to be completed (for example, the user interface) 2. The you add a bunch of features to that deadline (like toolbar, about box, etc). 3. You have a series of tasks for each feature that need to be completed like a standard todo list
Normal planning does not work for ISVs. But the approach above works (for me at least), because it allows you structure the way you approach your coding. It's not about traditional planning in any sense, it just a way of organising your todo lists in a manner that fits with the way that ISVs approach their products.