Mark Suster (@msuster) has written a very insightful post (What Should You Do with Your Crappy Little Services Business?) on his blog. If you haven’t read it already, you should. He sums up with the following advice.
I’m not advocating that companies are crazy to try and be product companies. In fact, that’s all that I fund as a VC. But I don’t want the narrow world of venture-backed companies and the trade rags that report on them to dissuade the overwhelming masses of potential entrepreneurs from building meaningful businesses that are both fun and economically rewarding.
Basab Pradhan (@basabp), further extends Mark’s post here, where he suggests that services companies never need to find a product strategy “given their lack of skills and management experience of the products business“. Rightly so considering he is mainly referring to the offshore services business.
There is, however, an interesting case for product companies (particularly early stage technology companies) to have a services focus to solve the cash problem. I call it productized services, and this is exactly what we do at Samuday. This is particularly relevant if you are not VC-funded and need to build high quality products with sustained revenue stream. If you are an India based technology company, this might be even more relevant.
Early stage technology companies that are aiming to build high quality products have a tough life in India. Indian VCs mostly invest in e-commerce driven (technology) companies, so funding is scarce for pure technology players. Indian customers have a slightly misplaced definition of technology, thanks to the plenty of offshore/outsourced/software services companies. Several potential customers do not appreciate the difference in technology capability for building a website as against building a real-time communication and collaboration solution. Anything delivered through a website falls in the same league. This leads to a perception problem where your product may not be valued at what it deserves, posing a challenge in building sustainable revenue streams.
[ 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. Continue reading
This is a great talk by three Silicon Valley serial entrepreneurs – Tony Perkins, CEO of AlwaysOn; Tim Draper, Founder and Managing Director of Draper, Fisher Jurvetson; and Michael Moe, Founding Partner of ThinkEquity. They talk about several different ideas around opportunities in the current slow-down and the global marketplace.
Source: Entrepreneurial Thought Leader Lecture, Stanford Technology Ventures Program.
I was reading an article titled ‘Engineering wants to rewrite‘ on the SVPG blog and couldn’t help keying in my own thoughts around the dynamics engineering has to work its way through in a technology startup. To quote the article:
When a company does get into this situation, everyone typically blames engineering. But in my experience, the harsh truth is that it’s usually the fault of product management. The reason is that for the past years the product managers have been pounding the engineering organization to deliver as many features as the engineering team possibly can produce. The result is that at some point, if you neglect the infrastructure, all software will reach the point where it can no longer support the functionality it needs to.
Most startups work at break-neck speed and the focus is always on features. The uncontrolled pace of piling up features without thinking of infrastructure and architectural limitations is a key component in this collapse. In a startup, a high rate of feature addition is inevitable and needs to happen. In this view, how should the Engineering and PM verticals be prepared to ensure a catastrophe is not waiting down the hill as products roll out? Here are some thoughts . Continue reading
It is encouraging to see some quality product development technology startups in India forming up steadily. We have finally broken the IT services jinx and are looking beyond the outsourcing model. It is taking time for this wave of change to hit the shores, but it is worth the wait.
I have been directly (I work for one!) and in-directly involved with some technology startups. I do experience the pains of building a product development company on several occasions, especially in the Indian context. Continue reading