Archive for the ‘Startups’ Category

Venture Capital’s Disconnect with Clean Tech

October 19, 2010

CleanTech Investments

Many entrepreneurs today are focusing on startups associated with CleanTech/Environment. For these entrepreneurs – the following article and review done by Joseph Lassiter, Professor of Management Practice at Harvard Business School, titled -“Venture Capital’s Disconnect with Clean Tech” would be a worthwhile read.

Interestingly, we at GlobalLogic had similar fears on the points raised by Professor Lassiter last year as we were in process of defining our technology services offering. This article certainly does a great job in articulating such fears.

Few key highlights which entrepreneurs trying to focus in this area should take away from this article –

  • Be ready to face and live through the ‘valley of death‘ – the painstaking stage between researching and developing a product and going to the market.
  • Unlike their cousin startups in the area of IT, Software/Internet and Telecom/Communication space, startups in CleanTech typically have a catch-22 challenge – they cannot prove their ability to scale without actually scaling. An absolute must for modern day VCs to be excited about a business.
  • Huge amount of dependency of the CleanTech ideas on the Public Policy. Interests in it tends to change from one political administration to another.
  • Extremely low VC investments (average ratio of one investment for every 100 ideas)

Personally, as mentioned above I had my inhibitions about entrepreneurship in the area of CleanTech – however it would also be of interest to me to hear (possibly from Professor Lassiter himself) as to how the VCs should try to structure their investments in such ideas/companies. In our internal study about a year back – we had seen that the same investors who were making investments in Consumer/Technology/Healthcare related ideas were also making investments in CleanTech. Just felt that this was a odd combination to have in a portfolio considering the differences in mindset required towards such investments.

Technology Start-ups: Tips for India from the West!

February 11, 2010

[Sometimes back a journalist from a leading business publication had asked me if I can write a short essay with my thoughts on what differentiates Indian start-ups from US start-ups and also what were some good learnings which budding start-up industry in India can learn from their mature counter-parts in the West – so that he can file a story on the same. Unfortunately, it seems that the journalist had to move to another story and hence could not take this forward. So I am posting the same essay here for the wider audience.

While the article compares Indian start-ups with US (driven by the need of the Journalist); the comparison in here is valid with start-ups in general with the Western countries besides US too. Thoughts and comments are welcome!]

Startups - India vs. West

I recollect a quote from one of a renowned Management Speaker from United States wherein he had observed that he was amazed to see the entrepreneurial spirit in the current generation of India. “Strong Dollar! No problem!” An Indian entrepreneur seems to have told him. “I can now generate more for the same amount.” For the weaker dollar argument, the same entrepreneur was still bullish. “I can now go and think about buying out someone in US”.

I agree with the speaker. While the modern ways of counting number of self-started businesses a.k.a. start-ups may have a different approach to measure – entrepreneurial endeavors have been prevalent for generations in India. Be it a doctor starting his independent practice or a housewife at home deciding to start an embroidery business. However with technology start-ups (the focus of this article), the state of things in India seem to be slightly different from the other countries in the world. Assuming that in today’s world technology is a common denominator all across the world now, the number of successful technology start-ups in India are still handful.

Over the years having consulted and worked with more than a dozen start-ups – in India and outside India – I feel that I may have some thoughts on this low success numbers (as compared to countries like United States) followed by suggestions to improve those. Hopefully, this will also help to contrast Indian start-ups with their counter-parts in other parts of the world. The points listed below are from the perspective of what are some of the key differentiated learnings which Indian start-ups can take from their counterparts in US (besides some standard best practices for any start-ups).

  • Technology just enables a business; Value Proposition drives the business:

In comparison with the US start-ups, a large majority of Indian start-ups are driven by technologists. I am not surprised by this considering that science and technology has always been close to the heart of the Indians. In their passion for the technology, I have seen that many such entrepreneurs have inherent weakness of not being able to properly formulate the end-user value proposition. As an example – cell phones did not become popular because of the technology; but because of the convenience and accessibility they offered to its users. However, the same cell phone user may not be ready to pay for a video stream on his/her cell just because technology enables video streaming to mobile phone too. I have started to cringe when yet another entrepreneur’s focus is on technology which allows you to find the nearest X, say plumber, using your mobile phone. My question to them remains – is this a technology solution or a value proposition?

  • Focus on the early adopters:

Another difference between the Indian and US start-ups is their focus on who their potential customers would be. Compared to their US peers, Indian start-ups traditionally seem to have believed that their success is directly proportional to the wide range of customers they can attract at the start. One might think of this as a natural strategy; however in my experience it dilutes the value proposition and confuses the initial set of users. Start-ups are all about crisp and focused value proposition. Entrepreneurs should focus on the needs of early adopters of their value proposition. More users will naturally follow if these early adopters like what these start-ups have to offer.

As an example, we had worked with a start-up focusing on using social media streams for project management. It was a powerful concept and in their zeal they tried targeting all possible personas for the first release. Unfortunately, a late entry in this space with a small focus got all the attention when they could crisply explain their value proposition to a subset and people could make sense out of it. The first company sadly could never recover from that setback.

  • Focus on execution; Ideas are just temporary:

Majority of start-ups today are based on a value offering as compared to a new or ground-breaking intellectual property. Contrary to the popular belief, it is not the ‘idea’ of the start-up which is critical for the success. An all-round focus on execution which includes building a strong advisory and organization team, partnerships, software engineering, messaging, launches, etc. is what matters. Indian start-ups need to be sensitive to this aspect of achieving success.

  • Productization of the “offering”:

Whether the start-up has a product or a services offering – in today’s world the productization of what customers are buying from them is becoming increasingly important. By productization, I mean things like Messaging, User Experience, Packaging, Clear Pricing, Delivery, etc. US start-ups with their experience over the years typically have done a better job in this. Indian start-ups need to catch up on this in a faster way.

  • If we build it, they will come!”:

This principle may have worked for Kevin Costner in the movie Field of Dreams‘; but unfortunately this may not apply in real-world start-up scenarios. In the initial stages of the start-ups, the entrepreneurs have to think about from the perspective of earning each and every of their customer. And let me tell you from my experience that it is not easy. Entrepreneurs may have invested a lot in building their product; however if they cannot invest in the Marketing & Sales effort their success may not be guaranteed. Start-ups in India need to increasingly focus on this aspect of their go-to-market plan.

I am of the view that Start-ups/Entrepreneurship in India is booming, however it is in its end success rate where India might be struggling. The above suggestions are more from the learning of what the US counter parts are doing better. Compared to them, Indian start-ups probably also do not have access to the best of environments, infrastructure, or an ecosystem. However, I have also heard from many US start-ups envying business opportunities and possibilities that India offers and to which Indian start-ups have easy access to.

[Image Src – “Start-ups That Work” by Joel Kurtzman]

[Update|Feb. 24, 2010 – New York Times carried the news today about Intel’s initiative to pump in about $3.5 Billion into technology start-ups in US fearing that America might be losing its competitive edge to countries like China and India. Interesting article which covers some interesting points as to how each country view’s start-ups in the ‘other’ countries.]

So do you have it in you to be an Entrepreneur?

July 9, 2009

Entrepreneurs for many of us have typically been cool yet mystical figures! There are typical curiosities which many think about them when they hear or read about them – “What did they have in them that they could become an Entrepreneur?“, “What drives them?“, “Do they do this for money or glory?“, etc. And ofcourse the million-dollar self-introspecting question which many have – “Do I have it in me to become an Entrepreneur?

An interesting new study titled “The Anatomy of an Entrepreneur – Family Background and Motivation“, just published this month by Ewing Marion Kauffman Foundation demystifies a lot of that. It is an interesting read. The study certainly seems to be debunking lots of common perceptions out there. No, you don’t have to be a college-drop-out or a revolt in a family or be in your twenties to be a successful entrepreneur. Sigh!

Some interesting findings/thoughts/questions which I had after reading the survey which the study conducted –

  • Average or median age of the entrepreneurs seem to be around 40 i. e. many of them are around the peak of their career age-wise. (Hence majority of them were married and with children). A while back I had read a particular VC had created some flutter when he mentioned that the prime age of becoming an entrepreneur today was in the 30s. This finding in some sense may invalidate that.
  • It may not be an accurate statement when some one says that entrepreneurship typically runs in the family. The study found that about 52% of the entrepreneurs interviewed were the first in their family to take that step.
  • One thing which I always had perceived is that majority of the ventures by the entrepreneurs were typically motivated by certain challenges they themselves faced in their life and thire urge to resolve the same. This study seems to have missed covering that aspect when they listed out the prime motivations for becoming an entrepreneur.  Would have loved to see how many of them started their ventures because of “want to change the world” factor!
  • Also, does the motivation factors change from males vs. females?
  • While reading the paper, I got a feeling that the study seems to be considering the entrepreneurial venture more from the perspective of factory/start-up/company setting. However, I think there is yet another sub-section of entrepreneurs – who are typically not the Bill Gates kinds – but still are running their own individual setups. Example – a Medical Practitioner who sets up his/her own private clinic; an artist who sells his/her art on the Ebay, etc. I would consider these also as a form of entrepreneurs. If these forms of entrepreneurs were also considered in this study,  my gut assumption is that a lot of findings could have been substantially different.

I understand that this is the first finding report and few more future ones are going to come out. Looking forward to reading those too.

Happy Reading!

Honey, I destroyed my product by adding too many features!

November 30, 2008

The temptation associated with squeezing in as many features before it gets into the user’s hands is typically very overwhelming for any product entrepreneur. This is especially true when a new product is being launched in the market for the very first time. A typical assumption behind this is that the probability of users accepting the product is directly proportional to the number of the features which the users find in it. The notion that the products just have one chance to get to the eyes of the potential users or buyers also fuels the urgency behind squeezing in the features. This a classic dilemma for products today.

Per the standard practices prevalent in product engineering today, the standard practice is to classify the features to be developed into different Priority Buckets along a scale. e. g. Priority 1, Priority 2, and so on. This scale may vary amongst various product groups. However, broadly this scale typically gets classified into three kinds of buckets – “Can’t go to market without them!“, “Lets do it if we have time!” and “Forget about it right now but I am so glad you documented it!“. Once the features or the requirements are classified in this manner, as a standard practice it is typically a race against time to see how many of these can be implemented.  If the team is able to implement the most from this list – they are considered to be the most efficient. It is also assumed that the product is better off once most number of the features from the list gets implemented.

However, in my opinion and experience – there should also be another way to look at the feature queue. The requirements prioritization should also take into consideration to understand if there is a threshold beyond which any addition of features would start affecting the product in an adverse manner. This threshold could be from the perspective of count of features or the spread of features from functionality perspective. Features and functionality in the product are meant for empowering the end users to fulfill their needs with the maximum amount of ease. Beyond a point, the additional features can make this task more complex and may actually result in turning off the user from using it.

Every product needs to have a core value proposition and a defined user base which it targets to. In my opinion and experience, the tendency to squeeze in as many features as possible in the product is typically associated with both. It can mean an incoherent understanding of the needs of the potential user base or probably a sign of weakness in the core value proposition associated with the product.

Any features which needs to go into a product should be focused around the few key value proposition which the product has to offer and how to do that in the best possible way. Increasing the breadth of features may enable the product entrepreneur to fill in a check list associated with a long list of features and claim “we have that too!”. However if this comes at the cost of diluting the key messaging associated with the product – this may just might mean the doom for the product.

Any thoughts or comments are welcome!

Add to Technorati Favorites

Paidinterviews – For In-demand People

September 9, 2008

It is always a great feeling when someone you work with very closely achieves a big milestone in their endeavors. We, as part of the Version 1.0 team in GlobalLogic, have had the privilege of seeing many of our Clients achieve that on a regular fashion. It is a proud occasion for us as we also get to share that joy of achievement with them.

Today has been one more such day for us. Paidinterviews went Live with their product today. And the icing on the cake was that their product was also showcased at Demo 2008 today! We have been working with Paidinterviews for about 6 months now, partnering with them on their product development. So in some sense this is also very personal to us.

We met with Jim Weaver and Keith Robison, the two co-founders of Paidinterviews,  slightly more than 6 months back. We were impressed by their thought process which finally resulted in the product they have today. When we started working with Jim & Keith, we knew that Paidinterviews is going to operate in a crowded market space of online job portals and online job search. However, we also felt that none of the existing solutions/services did an effective job of holistically matching a job profile with a candidate profile. Profile matching is simply not just about keyword matching in resumes or experience matching. A lots of dynamics come into picture when a candidate looks at a potential job opportunity or in a vice-versa case when an employer is looking at a potential candidate. Also, there are social aspects too which plays a big role into this matching. This is where Paidinterviews wanted to differentiate themselves and now does a great job in doing that today. In addition to this differentiation, Paidinterviews also wanted to incentivize the job seekers for marketing themselves better. We all thought that was a very cool idea.

Along with Jim and Keith, we built this product from concept to Beta in less than 5 months. We spent a lot of time in thinking about different ways of building the best user experience for all types of users. The product has Rich Interfaces and has been built and deployed using Ruby on Rails on commercial enterprise platforms.

It has been a privilege working with Jim and Keith on this endeavor and our congratulations to both of them on achieving an unique milestone in their long journey.

Read more about Paidinterviews at –

Add to Technorati Favorites

Building a Team in a Start-up – Tuckman’s Theory

June 28, 2008

Having worked with more than half-a-dozen start-ups now right from the early days, I have had the first-hand experience in seeing how critical the initial team formation step is. Not only the quality of the team mattered but also the timing associated with getting them together was critical too. Once the team gets in place, how soon the team ramps up with the mission and gets going is another hurdle the start-up/entrepreneur has to worry and cross.

Having seen it closely, many start-ups tend to miss out the after-effects of the Bruce Tuckman model of Group Evolution. Per Bruce Tuckman, any new team on a project typically goes through four stages of evolution before we see them performing as per the expectations set on them. These stages are inevitable and in some sense they are all necessary and happen in the same order.

  1. Stage I – Forming: The first few weeks are spent in this mode when the team comes together. They are in the process of understanding what needs to be done but typically tend to remain and behave in an individualistic manner. The initial personalities of the individuals come to the fore in this stage.
  2. Stage II – Storming: A slightly painful stage wherein individuals push forward their own ideas for consideration and tend to resist any group pressure.  Typically numerous conflicts arise at this stage because of different personalities, roles, and styles which can make things difficult for teams to work together. Depending on the maturity of the team, these stage can persist for weeks and months. Storming stage is however considered necessary for the growth of the team.
  3. Stage III – Norming: This is the stage where the teams start putting their individualistic thoughts aside and become more keen in finding solutions by agreeing on guidelines, behaviors, methods, etc. Teams start trusting each other. Signs of increased motivation are visible in the team.
  4. Stage IV – Performing: Again, depending on the maturity of the teams, only few teams would reach to this stage where the performance levels are optimal. Teams start functioning as a unit. They are focused on the common goal and work out decisions/conflicts using a more collaborative style.

Depending on the team size and complexity of the group structure, this evolution of group can take weeks and months. In my experience, only few of the start-ups can afford this and any mis-handling in these stages can be disasterous.

I have always believed that for most of the start-ups, the process of achieving their first goal is like playing in a limited-over cricket match. There is a limited quota of time; constrained number of resources; and steady influx of surprises/changes which they need to tackle. And I am talking about this from business perspective. In all this it is very tough for many start-ups to afford their team to go through the above stages. Imagine the eleven players – unknown to each other – going out to play a limited over cricket match and going through the stages above. This team cannot afford spending time in solving individual conflicts or formulating strategies or the game plan while they are on the pitch. The team needs to start scoring from pitch no. 1.

So if Tuckman’s theory is true and considering the limited options in front of the start-ups to afford what is described in this theory – what are the alternatives? Well, in a simple scenario if the start-ups can afford it, they should include this time as part of time-plan and cost. If not, there are other alternatives too.  I will talk about it in one of my future post.

Add to Technorati Favorites

Product Engineering approach for Startups (4): Estimating time and cost for Engineering of Version 1.0 product?

June 11, 2008

[This is fourth in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why it is necessary to implement a Goals-Driven Planning Approach.]

My group – Version 1.0 in GlobalLogic reached a very important milestone this week. Using an unique business and engagement approach, we successfully rolled out a Version 1.0 of one of our first client in the group. This was done in-time and within-budget with all the quality requirements which we had agreed with our client. Two more products are in its way to be completed within the same parameters in the next few months.

I would not like to claim that we were the first to finish a project on-time or within a fixed budget. However the unique thing about this achievement was the approach and methodology we took to reach to this stage – especially when we had to consider the driving forces behind rolling out first version of a product. (fixed time to go-to-market, changing or evolving requirements, and most important a fixed budget)

We are currently engaging with more than 8-10 organizations who are keen in seeking our help in soup-to-nuts aspects of engineering and rolling out their product to its Beta. While each of these organizations bring in an unique vision and passion associated with their products, there was one thing which was common in almost all of them. Almost all of them – in our first meeting with them – were keen in knowing a ball-park number associated with how much time it was going to take to build their product and how much was that going to cost them. We had to tell most of them that in software world there was probably no formula or a calculator which existed which could easily tell them that. Well, unfortunately, at least we did not have one!

Having said the above, we also do realize it was also important for such product entrepreneurs to get a feel of the time/cost numbers before they jumped into their mission. So to all of them we typically have been suggesting the following thumb-rules.

  • Regarding time required to build a Version 1.0 = This, IMO, for a product at an inception stage should be same as when the product should be taken to the market. So time estimates to build the product should be the same as the product’s pre-determined go-to-market date/s.
  • Assume that it would always take x amount of time for one person to build up a product feature. Increasing the number of people does not reduce the time. So for example in 98% of the scenarios, it is not possible to reduce the time to build a feature to half if you have twice the number of people working on it. This is a very important aspect to be considered in software engineering.
  • It is a risky proposition to build the first version of the product on a fixed cost; it should be always built on a fixed budget. So the best possible answer associated with how would it cost to build a Version 1.0 of the product is typically best answered by the entrepreneur themselves.
  • You can assume fixed regular cost associated with the raw materials required to build a software (intellectual property, human services cost, hardwares, softwares, etc.)
  • Only variable which remains is the product scope which the product entrepreneur wants to be part of the Version 1.0 release. This is an important variable which the product entrepreneur can use to optimize time and cost associated with Version 1.0

Hope the above thumb rules helps in some manner with the estimations. As Sachin puts it very nicely – “There are two things any product entrepreneur has in abundance – vision and passion. There are two things which he/she does not have in abundance – time and money.” Keep that in mind while doing your estimations.

Thoughts and comments are most welcome.

Add to Technorati Favorites

Version 1.0 in Silicon India

April 7, 2008

Silicon India has carried a cover story on Version 1.0 titled ‘GlobalLogic: Incubating Ideas, accelerating innovation“.

Provides a good overview of what Version 1.0 in GlobalLogic is all about.

Webinar – Helping Entrepreneurs Launch ‘Fabless’ Software Enabled Businesses

March 26, 2008

If you are a technology entrepreneur or a domain expert keen in hearing out the experiences in launching software-enabled businesses – you may want to check out the “Helping Entrepreneurs Launch ‘Fabless’ Software Enabled Businesses” Webinar. (Thursday, April 03, 2008, 1 P. M. EST). To register, you can follow the instructions listed on the page link above.

The Webinar is sponsored by GlobalLogic (my current employer) and the Version 1.0 Service which has been my recent passion.

Add to Technorati Favorites

Version 0.1 for Workstreamr

March 13, 2008

The team just released the first Iteration Release of Workstreamr this Monday and I was amazed at the terrific job they did. As I told all of them – this is probably the first time in my working experience that I have a seen a relatively functionally stable product released by the Development Team after the first iteration. Typically in my past experience, the first iteration release to the QA was when all the hell would break loose (sorry, there is a slight exaggeration here). QA cursing Developers for what they have handed them, Developers passing the buck to the Requirements Engineers for unverified requirements, and so on. It used to take few iterations and multiple patches to make the product stable for functional testing. In this case, the product was put to actual usage after the first iteration. It was a perfect synchronized dance between all the members.

The team sat down for an interesting retrospective meet yesterday.

Some key things which the team claimed worked very well for them were

  • Well defined and understood Iteration Goals. Goals were kept in an achievable format. (Team had spent substantial time at the start of the iteration to talk amongst themselves about the goals and success criteria)
  • Requirements in visualized formats (from wire-frames and prototypes).
  • Good team coordination and quick turn-around for queries. (Team uses Velocity Methodology & Platform)
  • Test Automation

Areas of improvement which the team suggested –

  • Branding Planning & Design should happen before the engineering starts.
  • In Iteration Planning Meets – plan for things beyond the next iteration.
  • Although it worked in the current iteration, Iteration Planning & Estimation process needs to be more rigorous.

There are three more iterations left for the release. I am sure the team would have excellent opportunity to implement these improvements. At this time, however, they should savor their achievements. And yes, a pizza is due on me!

Add to Technorati Favorites

Product Engineering approach for Startups (3): Goals driven planning.

March 12, 2008

[This is third in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why should startups invest in prototypes.]

One of the most important thing all the startups have to figure out as part of their Business Plan is what is going to be their go-to-market strategy atleast from Product or Services Delivery perspective. As critical as it is for almost all the startups, I see that many startups make the mistake of planning their go-to-market strategy using engineering milestones and not customer-driven milestones – especially in products which are more customer driven.

To explain my point here, let me take an example of two hypothetical Startups – A and B (assume that they are building same type of product).

  • Startup A sets its first milestone to roll out a Beta Release. So they plan a list of features to be implemented in Beta and drive their product engineering. The goal or purpose behind the Beta Release is somehow implicit here.
  • Startup B sets its first milestone to get 100 users start using their system. So in this case they drive their plan for Beta Release with the bare minimum features which will reach them to their goal. In some cases, these minimum features might be same as the features which Startup A is implementing. However, the point here is that purpose of the milestone is well defined in B’s case as compared to Startup A.

IMO, from the above example Startup B is in a much flexible situation where they can maneuver their engineering close to what customers or potential customers are expecting. They are customer driven. Also, there is also an implicit requirement on Startup B to be more Agile to reach the goal. Startup A’s strategy is more Engineering driven which may or may not be the same as Customer driven focus.

While I am personally in favor of following Startup B’s approach, I will also agree that organization’s circumstances to select either of the approaches may be driven by more wider range of issues.

From my experience, I have also learnt that Product Developers are more motivated and aligned when B’s approach is taken. They are more mission oriented. Whereas in A’s case, I have seen that the aim is more timeline oriented.

I would love to hear your thoughts/comments/feedback.

Add to Technorati Favorites

Product Engineering approach for Startups (2): Investing in Prototype

January 24, 2008

[This is second in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about what made Product Engineering approach so different for Startups.]

Over the last many years, I have seen various different approaches being taken at the early stage of product development in software startup organizations. For the sake of discussion, let me categorize them into two types of approaches.

The first type of approach is more directed towards initiating the actual development and evolving the product as they go. The vision of product concept also starts getting built up as the actual product itself evolves. While the approach in Type – II is to have a more stress on Product Conceptualization and Visualization (aka. prototyping) first and then initiating the actual product development.

In my experience, the Type – I approach is more suited for a very small and highly cohesive team. The product architect who may have conceptualized the product is also typically engineering the product in this case. This approach is also much more suited to the teams wherein the key folks have already experienced building a product on the similar lines as what they are currently developing. There is a chance that the team may be able to save time in terms of total release time for the product, however more number of development iterations are required in this case to finally build the product. More number of iterations can add up to the cost. This approach is much more suited to startups who may already have secured funding as compared to the ones who are hoping to get funded based on the product they develop. IMO, organizations building products in a niche/new domain or untested markets should not follow this approach.

For organizations who find themselves not able to satisfy even few of the criteria listed in the approach described in the above paragraph or infact see opposites of them, the type – II approach is the safest one. This is very much required when you have a large or distributed team or when you are collaborating with an outsourcing partner to build your product up. The key idea in this approach is to conceptualize and visualize the product (in form of wire-frames, clickable prototype, stubbed application prototype, etc.) to an extent where all the stakeholders have the same understanding of the product and the engineering team feels comfortable to build it up. The engineering iterations are much simpler and faster in such cases.

Approach – II does require some additional investment (both time-wise and monetary). Organizations will also have to invest on special non-engineering skills here which are typically found in Product/Domain Specialists, Usability Specialists, Visual Designers, and Rapid Prototypers. However the returns on such investments are substantial. Barry Boehm has written about it in his book on Software Engineering Economics. (“The Options Approach to Software Prototyping Decisions” a paper from School of Computer Science at Carnegie Melon is also a good read on the same.). This approach would certainly help organizations to predict better and reduce the uncertainty associated with product development.

Trust me – Startups already have lots of uncertainties to deal with!

Add to Technorati Favorites

Entrepreneurship Quiz

January 13, 2008

I thought this was a very interesting quiz from the facts and figures perspective for any budding Entrepreneur

I tried rating my own current employer – GlobalLogic wherever it was applicable on the same scale. Looks like we are doing very good.

Product Engineering approach for Startups. (1)

January 6, 2008

Having gone through the experience of working for few startups in my past life and now helping and working with plenty others in my current organization – I find myself in anecdotal situations lot many times when I explain those who have not tasted the sweet experience as yet. Majority of the software engineers in India still have experienced building software products from a services mentality. I would say this even if some of them may have worked for established Product Organizations here. By services mentality I mean where everything needs to be scoped. (When I say this, I am not saying that scoping is bad. Trust me, I work for a Services Organization and I understand the need for scoping continuously in order to keep us running our business.)

Product development requires a substantially different approach and more so when we are in a startup mode ready to roll out the first version of the product. 99.99% of the startups work in a “perish or exist” mode. You think of a project management variable (time, money, effort, etc.) and there is always a constraint there. And a very tight one too! ‘Scope’ many a times may have a shelf-life of few hours. And there is nothing anybody can do to stop that. So whether you are working for a startup organization or in a business of serving startup organizations like myself, you require a radically different approach towards taking an early stage product to the market. Yes, I mean radical.

My group in GlobalLogic is trying to do exactly that!

(This is part of many of my forthcoming blogs on Product Engineering approaches for Startups)

Add to Technorati Favorites