Tuesday, September 28, 2010

8 reasons why Investors won't invest in my startup

I have been doing some soul searching lately about the future of my startup. Things like where I am in the lifecycle of my startup, if and when I should spend time and energy to raise funding, or how viable it is for my startup to follow 37signal's way to growth and profitability.

To keep things real, I have compiled a list of reasons why an investor would not want to invest in my startup. Here it goes,

1. I am building "yet another" project management tool. See Dharmesh's post on "Onstartup" about this.

2. My startup is in the B2B space (which takes longer and costs more), when all the craze is in the consumer space. 

3. I'm a 41-year-old, first time entrepreneur, and not charismatic. These days, most entrepreneurs are in their early twenties. Stats are stacked against my generation.

4. I don't have a great elevator pitch, nor do I have a great deck.

5. I don't have a great UX expert, nor do I have a great Customer development / Inbound marketing expert on my team.

6. I don't have a popular personal or product blog. In fact, last time I checked, our product blog had a blogger grade of 26 (by the way, I love the graders tools by Hubspot.)

7. I don't live in the Mecca of startup- Silicon Valley, for that matter, not even in Silicon Alley, or Boston.

8. I'm a first generation immigrant without any "social proof." Stats are again stacked against me.

Oh, well! I won't let this list get to me. I keep this list to remind me of things I need to do everyday to neutralize these forces. I also have a list of reasons why investors should invest in my startup. That's for another day.

Friday, September 10, 2010

Twitter - "The Remote Control of Our Social Networks"

Imagine for a second, you get a job alert on your twitter account from your Linkedin network. You tweet back to your Linkedin account to your resume to the person who posted the job like this:

   /send myresume @ #LI

Although it is a trivial example of how Twitter can fit in our ever growing online social presence, but you get the idea. We already understand the power of Twitter as a non-stop source of streaming content. We have seen how Twitter has become the primary realtime news, interactive customer service, or marketing outlet,. However, I believe we are completely missing another aspect of a potential use of Twitter. This is the use of Twitter as a "virtual remote control" of our social networks like Facebook, Linkedin, Foursquare, Social Games (e.g., Zynga games) etc. This will put Twitter in the middle of our virtual social life. Let me explain what I mean.

To IRC users, the use of commands to control and manage the network is not new. For computer geeks, it is also known as "control data" used to regulate main data in many protocols like HTTP, FTP, TCP etc. For example, if you type just regular text on IRC, it is treated as a message to be published for everyone to see. However, if you start with / it is intended for the server to take some action in the context on behalf of the sender. For example, if you type 

       /invite Syed #ScrumPad

It is interpreted by the IRC server to send an invite to the user "Syed" to join "ScrumPad" channel. This is really powerful, yet very simple tool to use. The use of slash with some keywords is getting popular lately in the Twitter community as "Slashtag." This was introduced by Chris Messina, the guy who also introduced us to the world of "Hastags."

We already use some commands to control and provide additional context to our Twitter messages. Some of these are directly supported by the Twitter server (e.g., RT as retweet, D as direct message) and some are just interpreted by the recipients and no actions are taken by the server (e.g., mention, or reply by using the @ in the message). Here is a good guide on how to use them correctly. Most of these evolved organically by the Twitter community. Here is a TED talk by Twitter founder Evan Williams on the evolution Twitter syntax.

We all know how Facebook has become intertwined in our lives. If there is one thing that can be attributed to the growth and success of FB as the largest social network, that would be its brilliant idea of "InApp" - applications running inside Facebook application. It transformed Facebook from just a social network to "a platform for social network-aware applications." In the same way, if Twitter directly supports and facilitates the flow of control data among different applications, it can become "the hub of our virtual world." It can allow us to have our own "Virtual Remote Control." Let's just call it "TweetMote." Here is what the world would look like with our TweetMote (just checked tweetmote.com domain is not available. Is there any domain available these days?),

Tuesday, September 07, 2010

Synchronized dance between customer and product development

This May, I had to make one of the most difficult decisions of my life. I had to close our offshore development center in Bangladesh. We built this development center from ground up over last 4 years. This team became an extended family. The team was young and full of energy. They believed in the vision of building a world class software development center. They gave 120% day in and day out to earn the praise of our clients.  For most of them this was their first job. To see the dream come to an end was heart-breaking for them. But the reality was that this had to be done. This is why.

A little bit on the background. We started our business to provide software development services to small business using Agile /Scrum delivery model. Along the way, we ended up building ScrumPad, a Web-based project management tool, to help us manage our service delivery. Encouraged by initial feedback from some of our early adopters, last year we decided to make a transition from the service to product. So, we gradually started to move the whole team over to work on just ScrumPad. Around the same time, I met Eric Ries, Sean Ellis, and Dave McClure on the "Geeks on a Plane" trip to Europe (if you haven't been on this trip, I highly recommend it. You need to apply for it). I am glad that I did. I came to know about "Lean Startup." And I decided to start applying the principles.

It is easier said than done. Transitioning a running engine takes more effort than starting from scratch. It took us a good 3 months just to figure out where we were and where to start (or so we thought). We gradually slowed down new feature development, and started to focus on validating the existing features. However, we started to realize that it takes longer to validate a feature (even qualitative feedback) than to build a feature. So, we still continued to produce more (hence waste) than we were able to validate.

We finally realized that the only way we could tackle this issue is to put a hard break on the development. This meant the closing of the offshore development. It took us another 3 months to actually announce the decision and 2 months to implement. Here is what we learned:

    Match product development cycle with customer feedback cycle. 

For most companies, customer feedback cycle is the slower (a lot, at least in our case) of the two. An out-sized product team will always end up producing crap and hence slow down overall progress. This is especially true for companies making a transition to "Lean Startup" model. We had a large team (for an early stage startup) with mostly product development experience with no customer development experience. As a result, no matter how slow we went, we were still producing more than we were able to validate. In fact, we found out it is better to have product development run a bit behind than necessary. We don't want to produce everything that we think what our customer development (I'm using customer and product team more as two different roles that we get to play than as physically two different teams) is telling us to do. This is because test results and customer feedback are imprecise and open for interpretations. Having a less than required development bandwidth is a good way to force us to prioritize our work.

In an essence, a successful transition to "Lean Startup" model requires establishing a rhythm between customer development and product development first.

Monday, March 29, 2010

Iterative funding of startups- an entrepreneur's perspective

I am a first-time entrepreneur, and have not raised any external funding yet for my venture. So far it is self-funded (a.k.a bootstrapped). Recently I started to explore different funding options available to us. All the blogs and articles I read are from VC (investors') perspective. So, this is a view from the other-side of the table- an entrepreneur's (an inexperienced one I might add) perspective.

 As I am dabbling with the concept of "Lean" model of building startup, what I see is missing from the model is the "funding" side of the equation. Traditional sources of external funding are Angels and VCs. We all start our venture with a "big" dream. Yet, the success in our minds is subconsciously anchored in getting "funded," instead of building a "sustainable business." As a result, we spend a lot of energy in pursuing VC funding (a proxy for success). If we are lucky, we get a sizable chunk of money to build out your business. We get the whole amount upfront based on a "carefully crafted pitch" and a "big plan." Although the investor will try to hold our feet to the fire, but once we are funded, we get to spend the money in the hope that the plan will come to fruition before we use it all up. If not, we get to work on raising our next round of funding, and repeat the cycle. This time along with our first round investor. It feels there is a "big waste" hiding in there somewhere. That is why 37signals guys are so dead against raising money.

I see this is not an issue of external funding vs. self-funding or customer-funding (customer pays for your product or service that funds the growth of the business) though. It is an issue of how we earmark fund and spend it. Dave McClure has eluded to it in this presentation. He calls his alternative funding model as Incubator 2.0. I like the idea a lot. The gist of it is instead of making a commitment for an amount (usually large) upfront for a longer horizon, fund the business based on "progressive learning." Dave's funding model has 3 stages-

1. "Micro seed" (3-6 months) corresponds to "Customer Discovery" stage of "Lean Startup" model. Expect to spend between 0-$100K.

2. "Seed" (6-12 months) corresponds to "Customer Validation" stage of "Lean Startup" model. Expect to spend about $100K-$1M.

3. "Series A" (12-18 months) corresponds to "Transition to Growth" stage of "Lean Startup" model. Expect to spend  about $1M -$5M.

I would like to extend this funding model further. Why not break the funding into even smaller amounts that actually funds a set of experiments (hypothesis). We make these funding decisions "iteratively." If externally funded, we set up an MoU with the investors to enable "incremental funding" as opposed to "big upfront funding." The whole model would look something like this,

The goal of funding should be "just enough" funding to "sustainable growth." If we could do it through self-funding, great. If not, external funding is fine so long as it is in sync with the iterative model of building a business.

Am I missing anything that would prevent us from implementing a true iterative funding model that works in lock step with iterative customer and product development model? By the way, we are looking for an Angel investor who would like to try this with us...:-) Seriously.

Friday, March 26, 2010

Startup wisdoms are plenty, but data are scarce

If you are trying to implement "Lean" model of startup or building  SaaS business, you probably are looking for answers to these questions like me-

What is a typical time a company spends in "customer discovery" (problem-solution fit) in a specific category of application in my industry?
What is a typical time a company (in my industry/category) spends in "customer validation" (product-market fit)? 
What is a typical customer "acquisition" conversion rate in my industry?
What is a typical customer "activation" conversion rate?
What is a typical customer "churn" or "retention" rate?
What is a typical customer "referral" rate?
What is a typical CAC or CLTV in different stages of development?

You may say, the answers to these questions depend on specific situations. Yes, I agree. However, without any empirical shared knowledge, it is like walking in the dark. A shared database of such data would be helpful, don't you think?

When it comes to advices on how to start a business, run and grow it to a success, there are plenty to go around on the net. I appreciate all those insightful words of wisdoms. These wisdoms help me pull through days when going gets tough. They show me what I should consider when presented with a situation. However, these wisdoms fall short of actually helping us validate that we are on the right track, or we are capital efficient. As much we are open about sharing wisdoms as we are closed when it comes to sharing actual data. I understand we are very reluctant about sharing real data because we are then exposed (to our competitors, or to the scrutiny /critique by the media or industry experts). As a result, we are repeating the same mistakes as our sage predecessors have experienced themselves. It is a vicious cycle.

The value of these metrics will vary from industry to industry, but for the same industry and similar applications, they should be similar. When I started to look for data for SaaS business, I came across a great blog by Philippe Botteri from Bessemer Venture Partners. He maintains these data for public SaaS companies. However, it is not helpful for startups. I wish we were tracking these numbers for "SaaS Satrtups" without revealing the identity of individual companies. There are some examples of brave individuals- Peldi of Balsamic, Dharmesh of Hubspot who shared some data in the past. We can create a shared Google spreadsheet where we can voluntarily share these data as we progress through different stages of our ventures.  The format for this spreadsheet could be
                                                                                Stages of Development
Industry Category  Metric  "Customer Discovery"    "Customer Validation"   "Transition to Growth"    Growth

With a shared  database of these metrics, we can become more efficient with our capital, and we all will be better off.

What do you think of the idea of sharing these data? Am I missing something that would "really" get in the way to start sharing data anonymously? Or, do you think it is not an issue and hence not worth solving for?

Friday, March 19, 2010

Meet your customer at the door

Recently, I read an interesting blog post by Brant Cooper about accidental discovery of product-market fit. The gist of it is that if your server goes down for some reason, and you don't hear your customers calling you or even better screaming at you, you probably do not have a product-market fit yet.

We also unknowingly implemented an effective process for exploring product-market fit. Essentially it was embedded in our "customer acquisition" workflow. This is how it worked:

1. Customer would signup for ScrumPad for a 30-day free trial.
2. At any time during the trial period the customer can cancel the trial subscription.
3. We would notify them of upcoming end of trial by email and remind them of explicitly canceling the subscription.
4. If they choose to cancel the subscription, we ask them to take a short "exit interview" (which was optional; we allowed the users to skip the interview) with four questions:
                          a. Reason for cancellation?
                                1. Speed, 2. Usability 3. Lack of Feature, 4. Price, 5. Any other
                          b. Switching to another tool? If yes, which tool?
                          c. Reconsider in the future?
5. If not canceled before the trial period ended, the account "automatically" rolled into a "paid subscription" (since we do not have any "tiered pricing").

Requiring explicit cancellation turned out to be a very effective "product-market fit" exploration tool. We almost got 100% participation in the "exit interview." There were users who would forget (even after all the reminders) to cancel. When they would get an invoice (the controversial aspect of the process) at the end of the 2nd month, they would come back and cancel the subscription. We would always waive the invoice. Based on the the interview answers, we would go back to some of them to get further clarification on some of their answers.

However, we also quickly learned that some customers considered this to be an "annoying," even "deceptive" practice. Although we never intended to use "auto opt-in" as a way to mislead anyone,  we understood how this could be misconstrued as a "bad practice." It is important for us to do what feels right to our valued customers.  So, we now changed the process from "auto opt-in" to "explicit opt-in" (that is customers need to explicitly upgrade to a paid subscription before the trial period ends or the trial account is suspended). This reduced the number of trial customers that go through an explicit cancellation process, and hence the exit interview.

We have now embedded survey.io in our application in addition to our "exit interview" during cancellation process. However, it is difficult to get people to take the survey or explicitly cancel subscription.

How are you exploring product-market fit for your SaaS application? What do you think how we could increase participation in our "exit survey" or survey.io? Your insights will be much appreciated.

Friday, February 26, 2010

Why is "Continuous Deployment" challenging for most companies?

Continuous Deployment (CD) is one of the elements of Lean Startup model and the most controversial one. In simple words, it is an act of rolling software codes to live servers (a.k.a production) as frequently as many times a day. It is an extension of the popular and critical Agile software development practice known as Continuous Integration (CI).  In CI, a development team continuously integrates each other's work and run a suite of automated tests with every change in the code repository (a.k.a. check-in). This allows the team to catch any bad changes as soon as they are introduced so that they can be fixed quickly. Eric Ries took this practice a step further at his company IMVU. At IMVU, they move codes to live servers as many as 50 times a day, a high mark set for others to follow. To be able to pull this off, you would need technical maturity and product management discipline. However, as much as I love to be able to implement it at my company, I see a few issues with extending CI to become CD at most companies.

Review by the product owner. Unless you are a one-man team, you would want your changes reviewed by the product owner before you make it available to the users. In Lean Startup world, most likely the product owner role will be with someone from the customer development team. At least, the product owner is not someone from the product development team. Even the team is co-located, and there is daily interaction between the development team and the product owner,  the product owner should review the changes before  we ship them out the door. The product owner would want to make sure the changes are what he/she asked for. Usually the product owner would have feedbacks for the team. So, it is not clear how bypassing this human review is going to work. The larger the team, the more important the review becomes. If the team is geographically distributed, it is even more important. If you outsourced the development, I don't think you would feel comfortable with changes making to the live servers without you reviewing it.It is not clear how the product owner role fit into this CD at IMVU.

Risk vs reward. Yes, we cannot eliminate all bad changes or bugs through tests. However, I am not sure what incremental value we would get from CD beyond CI. With CD, yes, you may catch some bugs that may still slip through CI sooner (assuming you have a lot of users, which may not be the case for an early stage startup) and it may be easier to track down (there are other ways to reduce debug cycle) the bad codes since only need to work with smaller set of changes. But, at the same time, CD increases business risks (not just ours, but also for the end users), even if we can back out our changes with the flip of a switch. For most business applications, the reward would not outweigh the risk. In fact, it is a good practice to perform deployment during a "scheduled maintenance window" (even if you can do hot deployment) that the users know about so that their is no surprises. However, I can see the reward outweigh the risk for IMVU and similar services.

Non-backward compatible database changes. Database changes are always the most difficult to deal with, and requires more scrutiny and would not be good candidate for CD. In other words, it is difficult to back out (undo) changes if things go wrong. With iterative, incremental development, we encounter these changes more frequently. It is not very clear how IMVU handles these type of changes. It seems from the comments on their blog on CD, they handle the DB changes out of band. That means these are not part of CD.

Although I do not see any significant value in CD to live server beyond CI, I definitely see the value in CD to test/integration servers. In fact, we recently started doing this. It is not exactly CD, more like daily deployment to test servers for the product owner to review and provide feedback. This helps us to be able to deploy changes to live server every iteration (every 2 weeks).

Are you doing CD? Am I missing something?

Update: Got a chance to speak with Eric at a recent DC Lean Startup event. At IMVU, they do not do any non-backward compatible changes. All changes to DB are additive. Also, he thinks it is still important to do continuous deployment to production (to catch issues that surface under high load) even though you can (should) catch most of the other issues through CI. I can see his point, but for a startup having issues with scalability is a good thing (which can be addressed easily). At product/market fit stage, scalability is most probably not going to be an issue. So, we continue to agree to disagree on the benefit of continuous deployment.

Friday, February 05, 2010

Retrospective on ScrumPad Product/Market Fit

As I am beginning my journey of Lean Startup with our ScrumPad service, I plan to share my experience along the way.

The first stop in the journey is "Product/market fit." For the uninitiated (I am not an expert either, learning by doing), all it means is to prove that there is a large enough market for the product or service that I am building. The goal at this stage of a startup lifecycle is to identify/define that market with specific details- who are the users, why they like our product, and the business model that would work the best, and a repeatable sales model.

The best way to adopt the Lean Startup model is to first look back to understand where we are (since it's been 18 months that we are working on ScrumPad). During this time, we did not apply the Lean Startup model (were not aware of it). We only focused on product development using Agile software development model (the only good thing we did). Customer development was largely absent. I haven broken the retrospective in two parts- 2008 retrospective, and 2009 retrospective. And I have structured it in light of Lean Startup for easier understanding.

Version 1- Free ScrumPad: 2008 Retrospective
What was our hypothesis?
All started with a itch of ours. We looked for a tool that fits our needs. We found two- Basecamp and Version One. But, none was what we were looking for. After trying both, we had decided to build one that we liked. So, since we liked what we had built, we thought there must be more like us who would also like ScrumPad.

How long did we spend to validate this hypothesis?
6 months.

What did we do during this period?
  • We primarily focused on adding functionality (product development, not customer.). We thought more functionality = more satisfaction = more users. 
  • We were releasing incremental version of ScrumPad every two weeks using Agile/Scrum process.
  • We did not do anything on the customer development front. Did not do any marketing. Did not talk to customers for feedback (did not get out of the building). 
  • We completely deferred design thinking that design and usability is secondary to functionality. We thought once we have the functionalities in, we could always add design and improve usability.
  • We did not charge for our service. We thought we need to first build out the full product (not thought about an MVP) before we can start charging.
  • We did put some basic tracking- Google analytics as well as some custom ones (i.e., number of projects, users, and overall project activity index that we defined). It helped us detect some early issues with signup and getting started with ScrumPad. 
What was the result?
We did get a constant stream of SEO traffic from search engines. This traffic resulted in a trickle conversion 1 to 2 every week. Received some unsolicited feedback, primarily from those who liked it. However, when we started charging in early 2009, most of the users from 2008 stopped using the service.

  New   Bounce Avg. Time   Pages 
Visits     rate     on Site       per visit  Conversions
3,521     48%   00:02:50            2.61          5%

What did we learn?
Our product is better than the opensource counterparts. However, as a paid service, we did not learn anything about whether we have a market yet as a paid service.

Version 2- Commercial ScrumPad: 2009 Retrospective 
What was our hypothesis?
If we shift focus from functionality to user-interface and usability, there is a market for our service for a $21/user/month with single pricing model (no tiered pricing). I did a pricing analysis of our competitors (I must admit my class on pricing for my MBA from UNC helped).

How long did we spend to validate this hypothesis? 
All of 2009.

What did we do during this period?
  • We changed our logo, updated the UI, and continued to tweak the interface to improve usability. 
  • However, we spent a significant amount of time in refactoring (rework) to fix the sprawling code-base that resulted from the quick piling up of functionality. 
  • We started actively asking for feedback. We in fact incorporated a short exit interview during the cancellation process. 
  • We started charging for our service. 
  • We still did not do any CPC marketing. We wanted to focus on word of mouth. We added affiliate program instead. 
What was the result?
We continued to have a constant stream of SEO traffic from search engines. Even with pricing in place, we saw significant improvements in all metrics except trial conversion rate. We saw a drop in trial conversion rate (by 1%. I think it makes sense since its no longer free). With "trial to subscription" business model, we finished the year with a few paying customers, but no new customers through our affiliate program.
 New     Bounce    Time      Pages per        Conversion
Visits  rate Avg.   on Site      visit         Trial   Trial to Paid
   7,578    38%    00:04:23      3.72           4%          4%

What did we learn?
Since we have customers who are now paying for our service, there exists a market who are willing to pay for our service at the price-point we are offering now. However, we do not know who they are and how to reach them, and why they like our product over our competitors. Also, the metrics suggest that we have room to optimize the conversion rates through A/B testing of landing page and other aspects of the site and the service. Affiliate program was too early to add.

In hindsight, I believe what we achieved in 18 months or so, we could have learned even more in 6 months or less using Lean Startup techniques. More on what's next from here. 

Friday, January 29, 2010

Three Startup triplets that I like

Recently Dharmesh Shah blogged about Startup triplets- startup advice in exactly three words. I thought what a great idea to collect all advices from all great entrepreneurs in one place. I was not alone. It is evident in the responses it got on the net- 1434 tweets and many comments, and still counting.

I always like the number 3. 3 goals, 3 ground-rules, 3 action items, 3 options... I find it easier to deal with a list of 3 of anything. Any list longer than 3, I lose interests. In the spirit of 3, I asked myself,  if I had to choose only 3 triplets that I think are the most important to me as an entrepreneur, what would those be? So, here they are and why, in no particular order.

Just do it. The famous Nike tag line. It captures the timeless essences of entrepreneurship. The fundamental difference between success and failure. We need to start somewhere. Without the beginning, there is no being. We will make mistakes. We will fail. But we will know that we tried, which is lot better than then living with "what ifs." Kevin Dewalt, summed it up nicely on his blog and I quote,
Entrepreneurship tests us like few things in life. Jobs are trivially easy in comparison. Capital markets have a brutal way of exposing our own personal flaws in blinding bright neon signs before our eyes – frank feedback you just can’t get any other way

Build, measure, learn. The essence of "Lean Startup." If we can take the leap of faith, now we have this growing body of shared experiences about how to go about doing a startup that would give us the greatest chance of success.

Support customers maniacally. This is our ultimate goal. Anything else we do are means to this end. I recently stumbled on a post by the guys over at Scout. I could not agree more with them that we have an unfair advantage over larger incumbents when it comes to customer support. It really is easy for us to be very responsive to our customers' needs. It opens up the door to connect with our customers at a personal level like nothing else can. What can be better than this for "customer development."

What's yours and why?

Tuesday, January 19, 2010

Retrospective from a first-time entreprenure

It's been almost three and a half years since I started my "entrepreneurial" journey. I did not blog about my experiences so far. Everything has been written about the topic. I feel that I have nothing new to add to these shared experiences. Well, reinforcement is always good, even though everything has been told before. So, here it goes.

Getting used to no-paycheck is difficult. I quit my fulltime job to focus on my startup, Code71, (IT outsourcing services) in early 2006. I was too excited the first few months to notice that paychecks stopped coming. When I first noticed, the reality of entrepreneurship hit me. I must admit that I was a little uncomfortable in thoughts that it could take a while before I would see any paycheck again. As I had become self aware, I began to notice that I would look at interesting job posts from time to time and would toy with the idea of applying. It took me a good 6-9 months to actually stop looking at job postings (which I call a symptom of withdrawal from not receiving regular paychecks).

Brother and wife as co-founders. I started my business with my brother and my wife. Yes I know, you might be thinking what are you crazy? In my defense though, I involved them not because my relationship with them, but purely based on what they brought to the table. However, it has not been easy, I must admit. With my brother, we gradually started to step on each other's toes. He would complain that I do not treat him as a partner like I would have if he weren't my brother. And I would say the same. It got to a point where we decided to end our business relationship to save our personal. As for my wife, we are still in the business together and married...:-) But, it constantly add spice- good and bad to already eventful days of a startup business.

Emotional roller-coaster. I was aware (from other entrepreneurs) of the stress that comes with starting and running a business, yet I did not realize the extent of it until I experienced it firsthand. It is almost like mood swing. At times, I would mistake it for a split personality disorder. One day I feel I am at the top of the world, everything is looking great. The next day it would be completely opposite so much so that I would be thinking what have I gotten myself into? The worst thing was that it would spill over and impact my team. It was particularly difficult when the team is half way around the world and missing the context.

Clients amplify emotional roller-coaster effect. We work with startups and small businesses. As a result, they experience the same emotional roller-coaster themselves. This has "amplifier effect" on my emotional state- good and bad. When they are feeling great, I am doubly happy. When things are not so good for them, things are even worse for me.

Saying "No" is difficult. I would say "Yes" to any opportunity (even it did not fit with our long-term goal- technology or industry that we want to focus on, or agree to terms that we would not usually agree to) that come my way. How could I say "No" to a "potential revenue source," right? I always thought I could minimize the undesirable aspects of an opportunity while making the most out of it including short-term revenue. Sometimes we will sacrifice in the sort-term for a long-term benefit (the proverbial "carrot"), which never materializes. This got us into some situations that would leave a bad taste in our mouth. Even worse, it jeopardized our relationship with clients. I plan to say more "No" than "Yes" in 2010.

Product vs Service. When we started, we only focused on providing custom software development services. I did not plan to get into building a product ourselves. Things change. Business model evolves. We found ourselves building a SaaS agile project management software called ScrumPad in a year and half into our business. Having a taste of both service and product businesses now, I could say I like product more than service business. It is not so much because one is easier than the other. Both pose their own challenges. But, with service, it always feels like I am at the mercy of my clients, which is not a great feeling to have all the time. Whereas with a product, I feel that I have the freedom to pursue my vision and hence control my destiny. Now we are at a cross-road in our business. It remains to be seen that in 2010 how well we could make a successful transition to a product company following  lean startup framework (thanks to Eric Ries). However, I feel that we should continue with our service business in some form and fashion just because it helps us learn certain aspects of the business that could be applied to our product business. This should work to our advantage over our competitors who are pure product companies. After all, products are packaged as services (SaaS) now-a-days. I know this is contrary to popular belief, and investors would not like us for this.

It's not a sale until you get paid. I come from a technical background. Sales is something I am still trying hard to learn. It is still a work in progress. In the beginning, when I would have a conversation with any potential client, I would take any positive conversation as a sign for a sure sale (closed deal). After many disappointments, now I am aware of the complex dance that goes on during a sales process. I learned it is not a sale until you actually sign the contract. In fact, I do not even consider that a sale until I get paid.

Client feedback can be harsh. We ask our users to provide feedback every chance we get. I did not realize that it would be difficult to handle harsh feedbacks though. Fortunately, we get more positive than negative feedbacks. However, it made me realize that there exists a symbiotic relationship between entrepreneurs and their products. Every entrepreneur put hearts and souls into their products that is probably we as users are not always mindful of. Yes, some products are better than others. But all of them get the same love and care from their creators. I am now more respectful in giving feedback about any product that I use. You should be too.

Are you an entrepreneur too? Please drop a few lines to compare notes.