4 ms·

Very interesting tool. Two main thoughts: I felt that you could remove the word programmable from 'programmable cloud spreadsheet' - since most people will th

by vineet 16y ago

Very interesting tool. Two main thoughts: I felt that you could remove the word programmable from 'programmable cloud spreadsheet' - since most people will think that spreadsheets are programmable. I am a little worried that you have only gone half-way to your users. If you are about the cloud and your users understand that, then perhaps you should let them deploy to their own cloud machines, the other alternative would be to not charge per compute time but to charge per operation (line of code). Beyond that you might need to experiment with a couple of things: Try giving an example of how much a small license will buy me, or just giving me an example per compute time. Try letting me just buy buy time so that you can see what I would do with it, and perhaps don't show the number of concurrent servers in the signup page - just making the decision process simpler. Having lots of options means more decisions that a new user will have to go through - it might work for you if they are aligned with your users, but otherwise it might just mean more work for you to do to get it right.

gpjt 16y ago
Thanks for that. Re: "programmable" -- what we're trying to emphasise with that is that it's more programmable than (say) Excel -- the whole Python in cells thing, plus its ability to rework the recalculation loop with Python code. Our first cut was actually "a Python cloud spreadsheet" but we figured that we didn't want to tie ourselves down to people who already knew and liked Python, so we moved on to "programmable". Is there a better word, do you think? We've definitely been thinking about having some kind of option for people to deploy to their own private clouds (or indeed to their own server farms) but I see that we've not put anything on the site about that; we'll add something for that. I like the idea of having an example of what the different pricing plans/compute time allowances get you, we'll definitely add that. We've had a lot of debates internally about the concurrent server support; perhaps we should just drop that from the plans entirely?
- vineet 16y ago
  Re: "programmable". What you are saying makes sense. But when I first see a site that says 'programmable cloud spreadsheet' - I don't get that. Infact, there is a part in me that is still trying to figure out in which problems you are better than Google Spreadsheets and its programming model (even though I understand that you are different from it). Perhaps what you need to do is talk about the problems that you solve instead of what you are building. This will definitely be helpful when trying to get to product/market fit. Re: dropping concurrent server support - I doubt that anyone can really tell you what you should do there. You need to experiment. And the answer right now (with early adopters) might be very different from the answer a few months down the road.
  - gpjt 16y ago
    Right, that makes sense -- the classic benefits versus features balance -- which is, of course, made more complex by the fact that one user's benefit is another user's feature, but that's not to say that there's no balance to strike. One thing we did with our earlier product was to have a "How we can help..." section on the front page, naming three markets, with links through to separate pages for each, naming appropriate problem and solution/benefits for each. Perhaps we need to do the same thing here. Re: what we're better at than Google spreadsheets -- our big benefits come in simplifying complex spreadsheets, by using programmerly techniques such as objects/lists/NumPy arrays in cells, and in automated parallelisation for large calculations. These are definitely power user features, for normal cashflow spreadsheets and the like there's no advantage to using Dirigible instead of Google. (Random thought: we're currently using the example of calculating the orbits of the planets to show a bunch of those features off. We chose that example specifically because it's simple enough for most technical people to grok pretty quickly and doesn't require any real domain knowledge to see what's going on. Perhaps we also need more industry-specific examples to make the same point -- eg. pricing portfolios of exotic options for the finance guys.) Re: concurrent server support -- well, I guess a bit of A/B testing might be in order -- with a mind to the fact that we'll need to keep running the tests as time goes on and we (fingers crossed) cross the chasm.

by vineet 16y ago

gpjt 16y ago

Thanks for that. Re: "programmable" -- what we're trying to emphasise with that is that it's more programmable than (say) Excel -- the whole Python in cells thing, plus its ability to rework the recalculation loop with Python code. Our first cut was actually "a Python cloud spreadsheet" but we figured that we didn't want to tie ourselves down to people who already knew and liked Python, so we moved on to "programmable". Is there a better word, do you think? We've definitely been thinking about having some kind of option for people to deploy to their own private clouds (or indeed to their own server farms) but I see that we've not put anything on the site about that; we'll add something for that. I like the idea of having an example of what the different pricing plans/compute time allowances get you, we'll definitely add that. We've had a lot of debates internally about the concurrent server support; perhaps we should just drop that from the plans entirely?

vineet 16y ago
Re: "programmable". What you are saying makes sense. But when I first see a site that says 'programmable cloud spreadsheet' - I don't get that. Infact, there is a part in me that is still trying to figure out in which problems you are better than Google Spreadsheets and its programming model (even though I understand that you are different from it). Perhaps what you need to do is talk about the problems that you solve instead of what you are building. This will definitely be helpful when trying to get to product/market fit. Re: dropping concurrent server support - I doubt that anyone can really tell you what you should do there. You need to experiment. And the answer right now (with early adopters) might be very different from the answer a few months down the road.
- gpjt 16y ago
  Right, that makes sense -- the classic benefits versus features balance -- which is, of course, made more complex by the fact that one user's benefit is another user's feature, but that's not to say that there's no balance to strike. One thing we did with our earlier product was to have a "How we can help..." section on the front page, naming three markets, with links through to separate pages for each, naming appropriate problem and solution/benefits for each. Perhaps we need to do the same thing here. Re: what we're better at than Google spreadsheets -- our big benefits come in simplifying complex spreadsheets, by using programmerly techniques such as objects/lists/NumPy arrays in cells, and in automated parallelisation for large calculations. These are definitely power user features, for normal cashflow spreadsheets and the like there's no advantage to using Dirigible instead of Google. (Random thought: we're currently using the example of calculating the orbits of the planets to show a bunch of those features off. We chose that example specifically because it's simple enough for most technical people to grok pretty quickly and doesn't require any real domain knowledge to see what's going on. Perhaps we also need more industry-specific examples to make the same point -- eg. pricing portfolios of exotic options for the finance guys.) Re: concurrent server support -- well, I guess a bit of A/B testing might be in order -- with a mind to the fact that we'll need to keep running the tests as time goes on and we (fingers crossed) cross the chasm.