Working with offshore developers

Tweet

Over the last 2 months, working with small scale offshore vendors in Asia , I have come to realize that negotiating scope of the project is the most important skill one needs to have as a client.

Vendors in their zeal to win the bid almost always, underestimate the requirement and under bid on the project. They jump into development without completely understanding the requirements and eventually end up delivering sub-par product. Then starts the cycle of what is in-scope and what is not. Soon re-estimations and negotiation for higher amount follows.

In my experience as a client you spend about 40% time explaining the requirements to developers and 60% time in constant negotiations with everyone explaining, that the required functionality of the "one line description of the feature" really is not as simple as they thought. I know the obvious answer is to give a detailed feature description during initial quote request. Well it is easier said than done. For one, you do not know or have time to detail the feature functionality, and secondly, it is not advisable to share so much detail of a project during quote request phase with multiple vendors. And even if you do, the offshore vendors just deal with so many quote requests  a day, that they simply do not have time to go through detailed requirements.

I guess, it is just part of doing business with offshore vendors and one needs to be prepared to engage in long discussions related to scope of the project.

Done with Fall 2010 Semester

Tweet

I am finally done with my Fall semester. More than half of the semester(10 weeks), I was in India, taking the course part-time while working full time for Sourcebits. It was hard, but the experience and opportunity of working at Sourcebits(Sourcebits-rated as the #34 fastest growing start-up in the world) was well worth it. The link to live classes is terrible from India. I would not recommend anyone taking the courses remotely from India. The connection kept dropping every few minutes. I had to drop many courses I would have loved to take. 

The final course list included ESD.34 - System Architecture, ESD.933 - Innovation in Service economy, ESD-911 - Independent study on Enterprise Mobile Strategy, ESD.THG - Thesis on Business and Technology strategy for mobile platforms. I returned back to campus at the end of Oct to start making up for the classes and was able to successfully complete the semester with full grades.

I appreciate people who manage full-time job while doing the degree at MIT. It is hard and my experience in Fall semester has earned them new found respect. It needs too much dedication and focus to juggle both. MIT classes are not easy and truly to get something from each class, you need to at least spend 4 hrs per week per class. If given a choice full-time is recommended option not only from the perspective of convenience, but also the richer experience of MIT as a whole. There is just so much energy out here, that you simply cannot appreciate or take advantage from a distance.

EECS course on Mobile development - Spring 2011

Tweet

Many incoming students ask me about course selection. I thought I will share the link to a new course I came across on mobile development offered by computer science department. This course involves hands on development, so you will need to have some programming background.

Excerpt from the course url(http://groups.csail.mit.edu/mac/classes/6.083/):

Two years ago, it was rare for non-professionals to implement mobile applications. Even a year ago, building a working app was a challenging semester-long project. Today, implementing a mobile app can be a straightforward exercise. The challenge is to have good ideas for what to build. This course deals with how to pick project ideas and rapidly bring them to fruition through the prototype phase, how to function as an effective rapid development team, and how to present your work in a compelling way. You'll also get a hands-on introduction to current MIT research and development around mobile computing.

Android first ... Really?

Tweet

Akshay kothari founder of Alphoson Labs(http://techcrunch.com/2010/12/28/2011-android-iphone-apps/) seems to imply that in 2011,  app developers will considering writing apps for Android first. There might be some truth to it, and it could probably happen, but I think the statement is incomplete. To really analyze this, we need to segment app developers and study each segment closely. Only then, we can truly say that a particular segment of app developers might prefer to develop for Android first in future. There are basically serious professional app developers whose lively hood depends on app making money. And then there are hobbyist app developers. The professional app developers are usually a firm of size from 2 – 200 developers are full time into building apps.

See the app market comparision of Apple vs Android app store. Over 70% apps in apple store are paid vs over 60% in Android market place are free. This trend can partially be explained by the fact that most Android developers come from the web/java world bringing with them the free software mindset. I am not against open source, but I think free software movement has gone a little overboard. Historically, advertisement has not made enough money to justify the loss in revenue firms have seen due to free software movement(I am referring to free software and not open software movement).

There is no doubt that it has been difficult to make money on Android market place and if you look at the below chart by the end of September, the number of paid apps fell further to 35% on Android market place.

This mind set of building free apps will continue to make it difficult  to make money on Android as consumers will not pay for it, if there is a good enough alternative available for free. This will make professional developers think twice before developing for Android first. Of course if they have an iPhone version of the  app, they will for sure port it to Android to increase the market  size.

On the other hand the hobbyist developers(who do not completely depend on making money from apps) will prefer to develop for Android first simply because of the market share of Android. There is a little doubt that Android will outsell iPhone in 2011 and it makes sense for hobbyist developers to build for Android first.

ESD.34 System Architecture

Tweet

I had long discussions with my colleagues on whether system architecture principles and learnings had any relevance in today's world  with hyper rate of changes in technological innovations, specially in the software industry. To some extent, I concur with my colleagues that the scrupulous methodology preached by system architecture is not very applicable in the world of software product development. Only principles like Minimal Viable Product, Scrum/XP product development methodology, and quick- to-market  seem to be more applicable for software product development. 

The rate of innovation in software field is so fast that by the time you start and complete ESD.34 class, the whole technology innovation cycle has passed you by. Most often, initial needs and product goals are no longer applicable by the time the product has gone through alpha, beta stages. This makes you wonder if everything we learnt in class was applicable to software field or not.

I am of the opinion, that irrespective of the speed at which innovation and product development is happening, fundamentals remain the same. Concepts and principles underlying the system architecture still apply, but speed and manner in which they are applied, changes. ESD.34, as stated by professor Crawley(

MIT Aero/Astro - Prof. Edward F. Crawley - 

http://web.mit.edu/aeroastro/www/people/crawley/bio.html) in the first class, aims to rewire your neurons, make you think differently and transform you into a better architect. To a large extent, ESD.34 course has been successful at doing that. Whether we explicitly go through all the steps of architecture during product development or not, we do in fact follow many principles unconsciously. They become part of your subconscious toolkit and make you a better product manager.

In conclusion, system architecture is an amazing course and everyone should definitely take it. My opinion has been constantly changing over the year since the time I started it in Jan. I just have a few feed backs for improving the course. One, number of assignments should be reduced and secondly, class could be made more interactive and discussion oriented. I believe it sometimes goes overboard with the lecturing style of teaching and number of slides, which end up making you dizzy.

Now that I am done with system architecture class, I feel I am almost at the end of the journey I started at MIT. Few more courses to go and then I am back to the industry.

Spring Courses

Tweet

Well Spring semester is about to start and as usual I am overwhelmed with course selection. Following are the courses from Sloan, I am pondering to take. Lets see how it all works out. Between my thesis, courses and job hunting, Spring is already promising to be an adventure.

Interesting Sloan courses

1. Technology Sales and Sales Management
2. Competitive Strategy 
3. Innovation Strategy 
4. Power and Negotiation 
5. Evolution Towards Web 3.0 and the Emergence of Management 3.0  

I might only end up taking 2 courses for credit(well thats all I am allowed to take) and 1 or 2 as listener(time permitting). 

Minimum Viable Product

Tweet

This principle didn't make it to my final list of system architecture principles I submitted for ESD.34 class. I thought I might as well post it here as I spent few minutes writing it. I am following Minimal Viable Product strategy for my first iPhone application I am about to deploy.


Tag Lines leading to the Principle:
“Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature”
“If Apple can launch a smartphone without Find or Cut-and-Paste, what can you cut out of your product requirements?” – Sramana Mitra

Descriptive Version of Principle:
Minimum Viable product has just those features which allows the product to be deployed. It aims at generating the maximum validated learning from every customer with least effort. Such products are often deployed to a subset of users who are early adopters, more forgiving and more likely to give feedback.

Discussion:
MVP is more of a market testing strategy to understand the needs of the consumers and demand of the product before making big monetary and time investments into the product. It is important to understand that MVP is started with a product vision which is maintained through the life cycle of the product, but the features adapt to the feedback of potential customers of the product.
Not adhering to the principles of MVP can lead to development of complex products which loose the primary vision of their existence. And hence do not have customers coming back to them.  According to Tristan, the co-founder of Start-up square a primary reason of shutting down of his website was not following the principles of MVP. As he points out  - “startupSQUARE is trying to be:

• A place to find co-founders and advisors for startups (a discovery engine)
• A place to brainstorm ideas (ideation)
• A place to find the best resources for your startup

Any one of these topics is enough for several websites. By trying to tackle them all at once, we bypassed our Minimum Viable Product by several orders of magnitude and in doing so, we didn’t focus on enough basic value to keep our users coming back.”

Prescriptive Version of Principle:
Maintain a vision for your product and understand what core problem it solves. Release the product early to a subset of customers and learn from the feedback they give. Keep the product sleek and do not deviate from its vision.

[1] http://venturehacks.com/articles/minimum-viable-product-examples
[2] http://en.wikipedia.org/wiki/Minimum_viable_product
[3] http://blog.startupsquare.com/tag/minimum-viable-product/

My First iPhone App

Tweet

I am almost ready to release my first iPhone app. Its a simple vocabulary builder for GRE and GMAT, I developed to test the waters. Hoping to not run into troubles with Apple's approval process. Will post the link here once it is live on app store. In the meantime, I am attaching the screenshots below.

Working with Designers

Tweet

Entrepreneurship is a journey and so is every aspect of it, right from the time you start thinking about the idea, to designing and finally to development and deployment. During my experience, one thing keeps coming back to me; there is no golden rule for success but nonetheless every experience teaches you new things.  In this blog of mine, I try to speak about the challenges I face as an engineer trying to manage the artistic side of product development, that is the UI design. 

Art is different from engineering and so are artists from engineers. I recently had experience working with a remote designer from Vietnam for one of my website designs. The more creative a person is, the more eccentric and whimsical he is.So far he has done a great job and I am looking forward to deploying an awesome website in few days.

During this process I learnt a few lessons which I would love to share. 

1) Design is a very creative process and trying to manage it using typical project management methodology/process is almost impossible. You need to be more patient in terms of deadlines and always be ready to cut them some slack. In an artistic process, you might not get the right thoughts instantaneously, but you have to let yourself the time to understand and visualize them. Putting unneeded stress on the designer will chip him away from these thoughts.

2)Designers are sensitive about feedback. It might be just one page for you, but it takes a lot of time to think and put forward a sensible design and color scheme. Be creative and prompt about your feedback. 

3)Every designer has his own unique way of looking into things. They tend to love their thoughts and colors more than anyone else's. 

4) Art is driven by passion. Its not the money but your appreciation which counts a ton. Always be prompt about the designs you like and put forth your thoughts. Don't be harsh in your words, because no design can be judged as good / bad. Every piece has its own beauty. 

Innovation Strategy

Tweet

I am planning to take 15.910 Innovation Strategy course in the coming semester and in an effort to justify myself on why I am taking it, I decided to write a blog.

Innovation @scale - How do you manage innovation process in a large company? Entrepreneurs like being nimble and do not truly understand the complexities of innovation as their firm grows. When you are 50, 100 or maybe even 200 employees, all you do is innovation(unless you are running an off-shore service company). But as you grow bigger, hands on approach of entrepreneur is simply not enough. What you really need is a true process to manage innovation at scale.

Well that's the focus of the Innovation Strategy course I am planning to take this Spring. I will continue writing about this course as I make progress. If any of you are planning to take this course please let me know.