Early Signals

“What are you doing?”, my wife asked. Most of the time I grunt something. I think of this question as more of a greeting than a question. This time, however, I said enthusiastically “I am reading about the Wiki Wiki Web”.  This cracked up the entire family (two kids included). Wiki Wiki means quick in Hawaiian. This was in the early 90s before the days of Wikipedia. I was browsing through c2 wiki.

Wikis became mainstream when Wikipedia became popular and now my family does not laugh at me anymore.

There are times you have a hunch about certain trends. I felt strongly about – Databases in the 80s, Wikis and application components in 90s, XML, Python in early 2000 and now ML and Chatbots. This resulted in my working on an SQL database engine in the mid-80s, database components in 90s, an XML chip in the 2000s and on Python since 2006. Now, it is ML and chatbots and Natural Language Processing.

Not every thing I was excited about became mainstream. RDF and Semantic Web, OLE from Microsoft,  Domain Specific Languages and Pattern Oriented Languages did not go very far.

Over a period, I have built a few thumb rules about paying attention to early signals in emerging technologies.

  1. What is the research behind the technology and how long has it been going on? For example, neural networks and ML are several decades old. AI has gone through several difficulties.
  2. What is the volume and velocity of research papers?
  3. Is government funding research in this space? (Internet, Page Rank algorithm, self driving cars and many others started as funded Government research).
  4. Who are the major companies involved in the early adoption of these technologies? For XML it was Microsoft, Sun Microsystems, and several others.
  5. What are pilot projects being done for commercialization and who is working on those?
  6. Who is hiring in this space?
  7. Which business publications are covering topics about this space?
  8. What companies are getting funded? Funding is both a leading and lagging indicator depending on who is funding and why they are doing it.
  9. How is the information about this space being propagated? Who is propagating it?
  10. What are the conversations going on in Twitter?
  11. Are there books on the subject? Books are most of the time lagging indicators.
  12. Are these technology topics being covered in conferences?

Some of these indicators are easy to find. You need to look for others.

Thinking Through the Design of a Product is Fun

I was talking to a student. He is fascinated with a robot that cleans pipes. He had a prototype and won some awards. He wanted to discuss it.

We sat with him and brainstormed many ideas for the design at a very high level. I encouraged him to think about a different cleaner robot – one that cleans water tanks. Our discussion lasted half an hour and it was one of the most rewarding exercises I did today.

Thinking through the design of products is fun. When you do it as a small passionate group, it is even more fun. One of the reasons I hang out with a lot of engineering students.

Nano Hackathons and Build to Learn

A small group to build stuff together, learn together and learn by doing. This will replace techtalks for our weekly meets.

  1. A nanoapp is something we can build n a day. The core in a couple of hours. The goal is to learn by doing.
  2. We may find open source stuff that to build upon. It will be easy to get started. Every nanoapp we build will be open sourced with a liberal license (like BSD/MIT/Apache)
  3. We can start with a few programming languages  – Python, Lua, Clojure. We can have others too. We need a couple of champions for each language.
  4. We can build web apps, mobile apps and desktop apps to start with.
  5. If there is enough interest and a community forms around it, we can grow them in to mini apps or even commercial products.
  6. We will keep the group small – 10 to 20 regulars
  7. We would love to have students. As long as they are willing to work and learn.

If the experiment is successful, we can create nano hackathon events in schools, colleges.

LinkLog: Ara – An Innovative Modular Phone Project from Google

From Google’s Project Ara

Ara is definitely an amazing innovation, and a project that it would be amazing to see come to fruition. It’s also massively ambitious, and not every experimental tech Google develops ends up as a proper shipping project. Modularity has a lot to potentially offer the smartphone market (and could also be very interesting when applied to tablets) but there’s a lot of ground to cover between here and selling these things in stores. Still, if anyone has the resources and runway to make it happen, Google is a pretty good candidate

The TIME profile also sheds light on some of the fundamental mechanics of how Ara works. Modules are designed to slot in to each compartment on the basic chassis interchangeably, regardless of what each does. They’re also hot-swappable, so you don’t need to power down the phone to replace individual parts. Finally, the modules are secured to the device using hardware latches, which use magnets to lock stuff in place. That lock is released using an app of the phone, so that they won’t fall out when jostled or when the phone drops.

Project Ara: Inside Google’s Modular Smartphone

A Product Incubator – Is There One Like This?

Here is a scenario.

  • A couple of founders come up with an idea and do some initial research. They have a good feel for the market and confident that they can build a business. They have a set of hypotheses.
  • Founders have some money – just enough to bootstrap a first version of their product (a minimum viable product).
  • They don’t have a tech team yet. They are looking for a tech co-founder. It is kind of chicken and egg situation. Without a prototype, they cannot go and validate their hypotheses. Without a technical co-founder, they cannot build the prototype – at least that is the common wisdom.
  • Enter a new kind of incubator – a product incubator. They are a group of serial entrepreneurs with a mix of technical and marketing skills. They know how to bootstrap a product business and get initial customers. This is not just a tech team. It is a team that has built products before and knows how to manage a small highly capable product team.

Looks good, doesn’t it? Have you seen one like this?

Trying to Create a Better Product? That Strategy is too Vague.

From Law of Perception – Marketing for Geeks

Ries and Trout say, “Marketing is not a battle of products, it’s a battle of perceptions.” Sometimes the best product does not win.


Quite frequently, perception is merely an exaggeration of reality.

I like this advice:

Don’t try to create a “better” product. That strategy is too vague. Instead, try to create a product which is better for a specific group of  people with specific problems that are not being solved very well by others. That specific group of people will perceive your product as the best (emphasis is mine).

I like it because, it lets me enter a marketplace where there are other products but they don’t satisfy the needs of certain classes of users.

Let me take a specific example. We have a product – TopicMinder,  which can provide you topic based alerts. At a broad level, it can be perceived similar to Google Alerts. However, when you dig deeper, for specific research needs, it is better than Google Alerts. Google Alerts are broad. We are deep. So even though Google Alerts are perceived to be better (and free).  We are starting to get users who came to us, because they do not get what they want from Google alerts.

Service Business vs Product Business

Some Thoughts on Service Business vs Product Business in Software.

1. In a service business, the customer tells you his problem and you provide a solution. In the product business, you discover a set of customers with a problem and come up with a solution. Or you dream up an idea and find customers who can use your product.

2. In a service business, you build a custom solution that the customer pays for. In the product business, you build a generic solution that you or your investors pay for first and hope that many customers will pay for later.

3. In a service business, the customer gives you a spec. You build to that spec. In product  business, there is no spec. You make up one. If you are smart, you may build a minimum viable product and see whether you can get some customers to use it and pay for it.

4. In the service business some of the projects may be migrating from existing systems, improvements to existing systems or just maintenance work. You may be constrained in the tools you use. In a product business you have the freedom of space (domain), architecture, technology and tools.

5. In a service business, some of the risks are mismanaged expectations, communication problems with customer and changing specifications. In the product business your risks are finding your ideal customers and keep delivering superior value.

6. In a service business, you may have a cash flow problem but revenues are predictable, since you will be charging for time spent. In a product business, you don’t have guaranteed revenues unless you figure out the right business model.

7. You can bootstrap a service business with just your skills and reputation. In the product business, your bootstrapping strategy would be to build something valuable and find paying customers quickly.

8. In a service business, there are low multiples. You get paid for the work you do. If you are smart, you will build yourself a set of tools that will let you deliver higher quality systems, faster. In product business, there are either no multiples (if your product does not take off) or high multiples. You have a chance of getting exponential revenues disproportionate with your initial investment.

9. To grow a service business you growth is linear and depends on the number of customers, number of employees and  number of locations. In a product business your growth can be non-linear and does not depend as much on locations and employees. There is a much higher dependency on the number of products and customers.

10. In product business, you may be the next  Microsoft, Google, Facebook, Salesforce.com, Intuit with millions of users. In service business you will be more like Accenture, EDS, Infosys, TCS. The barrier to entry is much higher in service business than product business (example are Google, Twitter, Facebook).

11. Innovation drives product business. Implementation and Service quality drives service business.

One is not necessarily better than the other. But you will notice that product business requires different company culture from a service business.

This is by no means an exhaustive list. I have taken some liberties and made some grossly over simplified statements. But you get the drift. Please add your comments to expand the list.

Update – Sep 2013

A link to my presentation on why service companies can benefit from a product initiative