[ This is going to be a long post. It is a very sensitive matter to discuss failure, particularly when it involves highly accomplished and commendable professionals and VCs that have put in more than $18M. It is not my intention to get into the analysis of board-room strategy decisions, particularly because I am not privy to any of them. However, I worked there long enough to understand what was going wrong. I have very high regard for the leadership team of Gridstone Research and continue to believe that it was a great business idea. We (Yes, and I am part of it) just failed to execute! ]
Gridstone Research was a company that aimed to simplify the delivery of financial data of public listed companies, while expanding the scope of available data and reported metrics. The company had a Research Ops (read people who did the hard work of capturing data, auditing them and writing reports) and a Product Development (people who built customer facing products and and an internal product that was used by the Research Ops for data capture). The larger technical goal was to build technology that can significantly automate the data capture process, thereby making it possible to scale up significantly without expanding the work-force. This was a unique differtiator and could potentially challenge the big boys (Reuters, Bloomberg) of the club.I was one of the early members of Gridstone’s technology team and started with what was called AST (Advanced Search Tools) Group – the internal R&D team. AST’s mandate was to build (possibly patentable) technology that could make this automation of data capture possible. I was hired at Gridstone because that’s what I did at my previous two jobs at IBM Research and FICO. However, I ended up doing different things as the story at Gridstone unfolded. More on that later.
The big question is what went wrong? The easy answer is “the market conditions became so hostile that the customer-base eroded and business became impossible”.
The harder answer is “we failed to work like a startup and deliver to our potential, took some poor execution decisions, built an irresponsible R&D culture and drank too much of our kool-aid”. I will try to segment the problems and generalize the learning.
We are a big organization
When I first walked into the Gridstone office for an interview, I was amazed by how beautiful and BIG the office was. It was as good as an office in India can get (OK, I am not talking about the luxury offices in Microsoft Research). This would have been ok, if it ended there. The big organization feeling was engrained in the processes that we followed. The entire product development was outsourced to a vendor. We would later realize our mistakes in doing this, and build an in-house engineering team; only to fire half of them within a month because we realized how bad the market had turned. The product management (PM) teams created detailed Product Requirements Document (PRDs) that were almost always in isolation from the development leads.
Even when engineering came in-house, the product management team continued to work as if they were outsourcing work to a vendor. This led to a never-ending struggle between the product management and engineering verticals – resulting in slower product launches, bug-ridden software and poor team morale. This large organization culture made things difficult and there was an escapist approach to delivering products.
Outsourcing product development without a strong in-house technical leadership
When Gridstone Research first started, product development was outsourced to a vendor. This was understandable because our founders came from Infosys and did not have first hand experience in product development. However, they completely relied on the vendor for technology choices and product architectures. Both of these would eventually become big problems that made understanding and extending their code a nightmare and force a rewrite of a significant aspect of the product. Not having an architect on-board from the beginning turned out to be catastrophic.
The products were so poorly designed, that even incremental feature development would mean days (sometimes even weeks) of planning and scope analysis meetings – a complete waste of time for a startup that was trying to enter the big boys club of financial data delivery. I wouldn’t blame the vendor because they would work on maximizing their own profits and worked with whatever limited knowledge they had at any given point of time. What is interesting is that the founders came from a pure services background, so they should have understood that (typical Indian) services companies have low technical competence to deliver well architected products. But that is in hindsight.
At this point, I must share an early incident on how disastrous this can be. One of my early projects was to develop a “smart search” that could search SEC filings based on concepts. This was a feature in the larger product that was developed and managed by the vendor. I was responsible for only the backend search engine and the UI was built by them. The ratio of people working on the (actual) search engine to those building the UI was 1:4. If you think about it in simple terms, it means the company felt the job of making the UI was four times difficult than processing, indexing and building the engine that gets the search results using the keywords entered by the user. If there existed a strong technical leadership, the person would have seen this skewed and misplaced priority.
This turned to be a nightmare inspite of us having a clear agreement in design and integration. The problem was less technical and more tactical – and needs a bit of detailing. We used Sourceforge to manage all the products and development was tracked using artifacts (reports that are filed when something is wrong or when a new feature request comes from the customer). When I started working on this joint project with the vendor, every evening at 6pm I would suddenly see a bunch of artifacts assigned to my name. The first day, I went through them and found no big deal in either of them with most not even relevant to what I was working on. Since I had a lot on my plate, I focussed on getting the backend search engine ready. I came to office the next morning directly into a project call. To my amazement, the vendor had assigned all the problems that were reported for this Search feature and the project manager washed off his hands by his one-liner – “all the bugs are pending at Nimit’s side”. The funny part was, they had just done a bulk assignment of all the bugs to me so that they can save their face during this call. What was even more interesting, that there no Gridstone leadership turned up to understand how come so many bugs are reported to one inidvidual, particularly when the person is not involved in the front end. Again a clear lack of technical understanding and missing leadership.
From that day, I was spending 6pm to 11pm going through the bunch of random bug assignments. I would review them, put my comments and assign them back to the relevant individual. This was only to ensure that I don’t have to face an uncomfortable time at the morning meetings. BTW, I was not the project manager for this product. 🙂
Project managers of services companies are NOT product managers
This was a big failure. All our product managers were project managers in services companies before and had no experience in product designs. They were used to writing detailed documents that would take days to write and more days to read and understand. This would be followed by hours of debate with the development team only to understand that half of what they have written will take months to finish.
This could have remained a smaller problem if they had not started dictating the software designs and telling developers and leads how the database design should be. They did not have the skill to assume this leadership and it should not have been their mandate. The developers and leads worked with reduced responsibility and were constantly frustrated. I am still not aware about who gave them this right, but it was a cockatil of disaster.
Fortunately for me and my team, I was doubling up as the product manager of our Search product. This was a relief for everyone and we delivered at a conderably faster pace. I also led development of an internal product that was managed by the PM team – it was a nightmare bringing sanity in it’s execution. Partly because this product was originally developed by an external vendor without the involvement of an architect.
I first started with the R&D team at Gridstone. On the day I joined, I was explained a classification engine (a piece of program that can separate data into one of the many categories) that was written by someone. This followed an interesting discussion which went something like this.
Me: Looks great. What’s the accuracy of this system?
X : Around 95%
Me: That’s amazing! What’s the dataset we have used to validate this engine? I would love to see the data sometime.
X : (A loud laugh) No, we don’t have any such dataset. We have approximated its accuracy through some interesting ways.
I didn’t know what I was supposed to say. I came from IBM Research and FICO which were majorly data driven companies and where you couldn’t even open your mouth without data to support your statements. And here I was talking to someone who was making amazingly tall claims and not having a piece of data to back it up. The interesting part was everyone at Gridstone bought it! Not surprising, I didnt work on this project for long.
R&D can be a highly abused activity. It needs lot of discipline to be able to get something tangible out of R&D for production use. There were lots of resources spent on R&D and the output was nothing but a collation of open-source technology put together under a different name. There were tall R&D claims made in one of the board meetings, the only one I ever attended. It left me thinking about how are investors buying this, because clearly the ground reality was far from it. But then, people believe so many things that are not true!
Drinking too much of your Kool Aid
A startup must have a system to encourage critiques within. It is even more critical for startups to do this, because they cannot afford to go too far on a wrong path. This was absolutely unwelcome at Gridstone. There was a make believe system that made everyone believe that the best in the world was happening there and nowhere else. The reality, ofcourse, was far from it. We raved about our products and celebrated how awesome we were. Mark Suster has an awesome post that talks about this problem. Everything he talks about, happened here.
Do portfolio managers and buy side analysts care about a rocking UI?
The primary customer target of Gridstone were the buy side (mutual funds, etc) analysts who need fundamental data. We felt we could do a better job at it by giving them deeper data than what was currently offered. In this context our value proposition was the data itself and not the website where the data was shared. If the website was usable, people would be mighty pleased if we could offer consistent data over a wider range of companies. Another important point to note here is that analysts live their life on spreadsheets. They would probably never have the time/motivation to visit a Website. So the idea of making a Website that made all the designers weep with joy was highly misplaced. With limited resources, we aimed to achieve the limitless.
We spent close to 8 months on rebuilding the web-based product that on the first place never looked bad. To make things worse, the new website used so many images that it slowed down end-user experience – again a very obvious technology choice that was overlooked. Instead of that, we should have made our Excel product more compelling and made that the pivot of all activities. We lost time and by the time we were ready with this rocking UI, the economy had already sunk into the downturn. Analysts didn’t give a damn about learning new things and were only interested in saving their jobs – and rightly so.
These are very important points for any startup to learn from. After leaving Gridstone, I started my own venture by the name of Samuday, a communication and collaboration technology company. We did not raise any money from the VCs, are only three people strong (with one still in stealth and working part time), and have revenue paying customers. It would have been a much easier life raising loads of venture money and going every morning to a big office. Building a business, is almost never about these things. It is about understanding your customers, being brutally honest with feedback and turning course when required. The failures at Gridstone has taught me immensely on what one must NOT do.
There is no one right answer to starting up and building a business, but elimination of wrong choices is the biggest help you can get. If you had the patience to read through this long post, please do drop a comment. If you worked at Gridstone before, please feel to comment/critique and share your insights.