That's funny because I'm also building a web-based Excel/database hybrid, and I'm also a bit concerned about demand. But your story doesn't deter me at all, for two reasons: one, because I'm crazy; two because of La Femme Nikita. Let me explain.
People talk about ideas as being worthless, etc. No, they're not. You can't get an oak tree with a mustard seed. But there's a big difference between even oak trees. Idea and execution are the same thing, just two ends of a continuous line.
The films La Femme Nikita and Point of No Return have nearly the exact same plot. The former is one of the greatest action films ever made; the latter is one of the worst.
That whole "build something people want" is only for people who want to make money. And honestly, if what you want is to make money, be a dentist.
People waant Facebook and Twitter and Farmville. But they need core technological innovation. They need better ways to work with data. You did the right thing, Andrew. It wasn't a waste of time. And I won't stop either, because the world has far too much of what it wants and far too little of what it needs.
Actually, Facebook, Twitter and Farmville are great examples of products nobody said they wanted and didn't solve any perceived problems, but are succesful any way.
I've compulsively weaned myself off the "solve a problem" mentality because it gets in the way of building truly innovative products, IMO.
You're right. You don't have to solve a problem. But you do have to create something people want, or something that appeals to them. Technically, there aren't many "problems" in life besides survival. Everything else though has to appeal to something in the Maslov hierarchy
And honestly, if what you want is to make money, be a dentist.
And if all you want is to build something just for the fun of it, don't start a company. You'll lose money, time and nerves. There really are only to options when building something. Either build something people want (and if somebody built it before you did, build a better version - see: Altavista, Yahoo and others vs. Google) or build something, and then make people want it (see: iPad).
But don't start a company to build something just so you can satisfy your professional curiosity. That's what side projects are for.
The web was a side project. It changed the world. Linux was a side project. It also changed everything. Angry Birds was a side pro... wait, no it was a way to make money... and that's fine. I'm not trying to say, "Don't make money." I'm saying, making what people want gets you Angry Birds. Making what people need gets you the web.
So your point is that you should build something that you believe people will need even though this need/want doesn't yet exist. Ok, I can agree with that. But if you're going to run a company, you better build something people want now, or be able to make people want it, otherwise you'll go bankrupt.
Are you kidding? 80% of 'enterprise' systems involve a spreadsheet that is (conceptually) a database. Some business users use the words spreadsheet and database interchangeably. Almost every enterprise system I've build involved Excel as one of it's data sources. Users often give you requirements in terms of excel formulate etc, or ask for screens that are 'just like excel'. Microsoft has even recognized this and now offers 'server-side excel'
as part of office 2007. http://en.wikipedia.org/wiki/Excel_Services
I'd suggest that if this product wasn't a success you either didn't understand how end-users currently use spreadsheets as a 'poor man's database' or the marketing let you down.
Realistically it was more like editable gopher than excel - or that is what it was meant to be anyway, we didn't get to implement the editing functionality.
I still very much like the idea of being able to build lists from web based API's with only a handful of lines of Javascript.
You built something that was supposed to be an Excel clone, but you didn't implement the editing functionality?
Isn't that pretty much 99% of the point of Excel? I mean yes, people do use Excel to share data as well, but most scenarios involving shared Excel spreadsheets involve multiple people editing the same spreadsheet, and then generating reports out of it.
That's where the pain is, and that is what I had assumed you were aiming at. If not, then what did your system do exactly?
(Also, build lists from web based API's with only a handful of lines of Javascript isn't Excel, either)
Edit: I see further down you noted that your system was desktop based software. A web-based Excel/database hybrid isn't a big requirement list, but I'm not convinced you are covering a whole lot of it..
People do need an alternative to Excel, but it must address the issues Excel has, not compete on the same ground. One example: data consolidation. Try consolidate 30 excel files from 30 different people across the globe and you will be asking why nobody is providing a better solution.
As an analyst/controller I work with Excel every day, let me know if you want to know about issues with Excel, there are tons of problems to solve.
Our core business case is to address the problems of distributed business processes implemented in spreadsheets. We want to continue to offer the flexibility of the spreadsheet paradigm whilst addressing the most weaknesses of the current paradigm.
This short video (when its finished) will be the centerpiece of the new release:
http://vimeo.com/25937882
Do people really need an alternative to Excel? I would suggest that as soon as someone has gotten to the limits of Excel, then they would start looking at a programming language as an alternative, not at a "more better Excel".
Andrew, have you ever worked in a business environment? People get scared for some humble sql, how the hell are you going to convince them to learn programming (also vba is a problem)? Plus, what about cost/opportunity? Would you prefer to pay 10/20$ per month per person to improve their excel efficiency or either paying custom code or coding training?
Point is, there must be a market out there for some functionalities that Excel does not have, it also should not be that difficult to build such a solution (call it a hunch, but I think with nosql that should be really easy to do). But the whole thing requires stopping thinking logically (of course excel makes no sense) and start thinking business(ly) (how do I get people to understand and use my solution).
You're both right. Spreadsheets are already a (poor) programming paradigm called Functional Reactive. I say it's poor but it does something amazing: it doesn't require structure, planning, and forethought; and it can be used by anyone. The problem is that these constraints pull at each other: make it more powerful and you make it less useful.
I think it's only when you make a complete rewrite from the bottom up in another paradigm that you can extend the power while retaining the usefulness.
'I think it's only when you make a complete rewrite from the bottom up in another paradigm that you can extend the power while retaining the usefulness.'
True, but again, look at the users. People with very poor IT knowledge and very scared of change. Any new solution pointing at this market will have to:1) be as easy to use as excel; 2) much better than excel (why change otherwise?).
I think that being better than excel overall is impossible, but looking into specific businesses and uses it should be.
David, if you have something better than excel in mind, I'll be glad to hear that.
Personally, I have been giving it a lot of thought and I can't come up with a complete better solution. But other (Palo, Hyperion) seems to make money on solutions that do not change the excel paradigma.
The key question is what are the users trying to accomplish with Excel? There may be ways for them to continue to use Excel and gain the benefits of a more complex reporting environment.
The base of users with knowledge of Excel is very large. Most organizations have a built in base of knowledge of Excel. Why swim upstream and go against that. Try to make Excel work in that environment.
Take a look at www.excelcube.com. It may be helpful.
No problem, when I have time I send you an email. I would like to discuss this myself to see if there are cheances to build something in this direction.
I would love to hear about these problems, too. I'm currently planning (as in not having started programming yet) a web app that allows people to manage all sorts of data. Which of course would also include financial data. I'm always looking for new use-cases.
Interesting topic as I recently spent three months on customer discovery for a CS researcher/wannabe entrepreneur who developed a spreadsheet consolidation (combining data from disparate sources) solution. My discovery work was primarily focused on enterprise. The primary finding was that everyone in enterprise claimed that they have the problem but the pain is not high enough for them to consider buying a solution that only consolidates data. They were looking for end-to-end solution.
Have you looked at google fusion table and google refine? These are powerful tools in same space for non-enterprise applications.
A Python company just outside the city, whose name escapes me right now, was doing very well with a web based excel.
Most/many hedge funds manage billions of dollars on the back of very complicated excel spreadsheets, mostly because
the "talent" understand excel and can bend it to their needs.
But auditing these things is an utter nightmare, which version was used to lose a million here or a million there. Is it still on bobs laptop? How can I reuse code?
By providing a excel like front end and a centralised, versionable, auditable back end, they got a lot of interest going.
The space is still very wide afaik, but I have been out of the City for some years now.
(In fact you could take a similar approach to any CFO's office)
Jane Street is very unusual in having such an advanced technology management set up (IIRR OCaml, directors review the code before production etc etc)
Wufoo solved the "mail a template spreadsheet, receive filled in spreadsheets, manually consolidate results" problem, which is huge in any company with more than a hundred or so employees.
I am currently building/have built a web-based spreadsheet with a really unique approach - something that Excel does not and can not do.
I will be presenting this at the Seedcamp in London later in the year. I am really exciting about the project, so I wont be giving anything away here! Unless PG wants to get in touch directly...
The basic idea was that with 10 to 15 lines of Javascript you could bring back results from any XML or JSON web based API and display it as a list. You could then link any row or cell to any other list.
In a way it was like a reinvention of the old "gopher" protocol which allowed the user to navigate from one data list to another.
The question is though, what problem does it solve? It was very hard to explain to people why they would need it or care about it.
Spent a year developing it and spent alot of money on it. For nothing in the end. A very cool technology and I still like it alot.
Lesson: build something people want, or that solves a real problem. Don't build a solution looking for a problem.