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.

However,

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