Gridstone Research: What can go wrong in spite of all the good people and money?

[ 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.

Irresponsible R&D

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.

15 thoughts on “Gridstone Research: What can go wrong in spite of all the good people and money?

  1. Too many things to comment on. But affirming your point, traders don’t need fancy UIs. I guess anyone who has seen a Bloomberg terminal would realize that.

    Good post though. Will post comments as and when time permits.

    • Absolutely! Eliminating the wrong choices only increase the probability for the right answer. The rest must be hard work, intuition and creativity.

  2. Well written. Though I was not much aware about happenings in R&D and engineering team however I do agree with your views on unnecessary spendings and our belief on nothing can go wrong. We distributed heavy bonuses when there was no revenue to back us. I also agree with you on development on excel capabilities. In fact I tried a lot to push excel based model and for some time there were activities around it. I remember one of the instance when one of our founders came down from States and trained team on building earnings model but nothing happened there after. We hired a team of dozen people in the US but I don’t remember any call taking place between research operations team and sales team. I always think there was a huge gap between Sales team and operations team. Well.. I think you can now write a book on ‘N points someone not to do in start ups…

    • Thanks Pankaj.

      Although there were some things that were not right, I am sure nobody wanted to err by choice. As you have rightly pointed out there was a very strong belief that nothing can go wrong.

      I agree that there was lesser tranparency on the sales front. IMHO, when sales is not discussed there is one of the two reasons – you are doing so well that you don’t want the competitors to know your mantra early; or you are doing so poorly that you don’t want your employees to know to prevent them from leaving. In our case, it was the latter.

      We had several processes (some of them were very useful), but it would have helped if we spoke about our failures a bit more openly. We were too touchy to discuss them and critique ourselves.

      While many of us can now comment and critique decisions in hindsight, it is always a challenge to look forward and predict the success or failure of any decision. Since nobody is an Oracle, a test and proceed approach probably works best. Take small steps and go deeper into understanding the customers. This is less of a “sales executive” job and more of an evangelistic process.

  3. Too many things went wrong – at this magnitude even a large company will not survive – except Dilbert would thrive on this.

    • Thanks for your thoughts Milan. Yes, there were several things going wrong, but we probably didn’t realize. I am sure if our senior management consciously realized this, they wouldn’t have done it. Probably they had a view which I am not aware of.
      That aside, if it was not the downturn, we probably would have still managed to survive and make our way through these problems. The crisis following the downturn magnified some of minor problems that were not attended to.

  4. Thank you for writing a long due public critic of what went wrong in Gridstone – a theme that aches everyone who has been associated with that firm. There were many reasons to fault, and in my view VANITY is the foremost. Gridstone Board, by all its actions, demonstrated that it believed in its business plan more than doing business by itself. It wanted to be a product company, but had staffed the firm with people who can only execute on a service delivery model. There were many, many red flags to warn that the business was failing, but arrogance (bordering on stupidity!) kept the executive team firmly tied to the “plan” and not look at the “reality”. A start-up has to be managed by entrepreneurs whose primary goal is to make money, not by managers who think their job is to execute on some grand plan and leave the money making headache to those guys who have sunk $18 mn. I could go on, but then this would read like a thesis and not a comment. And I hope all ex-Gridstone have somehow caught on with their professional lives by now and have learned in their own ways from that organization’s failure.

    • Thanks for sharing your thoughts Nilanjan. I agree that start-up leadership must be willing to get kicked in their faces while going through the processes of setting up a sustainable revenue stream. It helps everyone. The customers get an opportunity to get a product that works for them and the startup can execute faster on what is an absolutely real need for the market. Executing as per the “plan” doesn’t work beyond a point because the plan itself is dynamic.

  5. Excellent post. I too strongly believe (based on my own experience, though a short one) how a startup can eat up the resources in the wrong way if they don’t keep checks on the points you mentioned in your article.

  6. “Closed-mindedness” would be singular reason.

    Hiring too many too ‘alec-smart’ kind of persons not needed or supported by business.

    Overwhelming fear of failure led to increasingly alarming level of lack of transparency — even a goverment organisation would be put to shame in this regard. All the time I used to wonder how come such a high level of opaqueness is present.

    Lesson: Failure should not be feared but to overcome.

  7. This kinda shows the difference between mindset in service based companies and product based companies. In service industry almost everybody is busy saving their face rather than actually contributing which looks like one of the biggest problems

  8. All said and done, here are my 2 cents 🙂

    1) While you are at product development, never make it your child so you won’t see it’s limitations and drawbacks. As an extension to this point, detailed specifications are useless, the product requirements must evolve with user-feedback. If the product idea is too rigid, you have to be ‘LUCKY’ to be successful.
    2) The complete development must not be outsourced to a vendor. Rather than a prototype must be built in-house, so that people are not ‘LOST’ when the source reaches back. This also helps set the guidelines for the product development and since it’s developed by the people who are actually close to the product, they’d know where it might need to be extended and hence open for extensions/plug-ins.
    3) Backing the 2nd point, a product startup strive to blur the line between the actual developers and marketers of the product. A developer must know where s/he is going to add the value in the process and where exactly the work done by him/her will benefit the users of the product.
    4) Last but not the least, the key to product building is 3 people: User Interface Expert, Technology Expert (Technical Architect), and Subject Matter Expert (SME). If either is missing of the three, there are not very good chances that it’ll end being a success.

  9. Amazing post. I work in Equity research and could feel they way Gridstone would have worked. I learned a lot with the post. This could easily be a case study. 

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.