tag:blogger.com,1999:blog-249478352024-03-05T15:18:38.820-05:00Syed Rayhan on Technology and BusinessSeeding business with technology in an Agile world.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.comBlogger50125tag:blogger.com,1999:blog-24947835.post-6418379275166586462015-09-03T03:50:00.000-04:002016-11-06T23:05:12.715-05:00A Cautionary Tale of Co-founder betrayal at Praiseworthy (Formerly Fosubo), a Silicon Valley Startup- 6 Lessons Learned <div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;">When we hear that </span><span style="color: black; font-family: inherit; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">"Co-founder Conflict"</span><span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;"> is one of the biggest reasons that startups fail, we think it won't happen to us, until it does! Yes, it happened to me. And finally I decided to share my story with you all. I hope this will help you if you are starting a venture with someone you have never worked with before. So here it goes:</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">The Back Story:</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">I met my co-founder </span><a href="https://www.linkedin.com/in/misachien" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Misa Chien</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> through a colleague and friend back in August 2013. I was coming off of another startup in the process of shutdown for lack of subsequent funding after 2 years of existence. At the time Misa was also in the process of shutting down her previous small business (Food-truck called </span><a href="http://www.inc.com/30under30/2011/profile-jennifer-green-misa-chien-founders-nom-nom-truck.html" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">"Nom Nom"</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">). She was brought onboard of </span><a href="http://praiseworthy.co/" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Praiseworthy (Formerly Fosubo)</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> (our startup) as a CEO in July, 2013 by her then boyfriend </span><a href="https://www.linkedin.com/in/nicolasbrenner" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Nico</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> and Nico's friend Pato.</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Praiseworthy was born out of a hackathon that Nico and Pato participated in</span><a href="http://www.udd.cl/noticias/2013/06/05/plataforma-de-evaluacion-gano-angelhack-2013/" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;"> Chile organized by AngelHack in May 2013</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">, where Praiseworthy won. Praiseworthy was then invited to present at </span><a href="http://www.ilovechile.cl/fosubo-winner-chiles-hackathon-angelhack-prize-silicon-valley/" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">the AngelHack Global Demo Day in Silicon Valley on September 5, 2013.</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> While Misa, with the help of Nico and Pato, were preparing for the demo day, she started talking to me about the possibility of joining as the co-founder and CTO. Both Nico and Pato were running their own startups back in Chile, and were not interested in seeing Praiseworthy through full-time (or so I was made to believe!).</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><span style="font-weight: 700;">My </span><b>Praiseworthy</b><span style="font-weight: 700;"> Journey:</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Our conversations led to forming a partnership (verbal) between Misa (as the CEO) and myself (as the CTO), while Nico and Pato stayed on as advisers. With that verbal commitment, I started working with Misa in early September as </span></span><span style="white-space: pre-wrap;">Praiseworthy (Formerly </span><span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;">Fosubo) had won the global demo day securing $25K investment from Right-side Capital. We were hard at work with our Pilot client (a T-Mobile franchisee) and preparing for the YC winter session 2014 application. We had not formed a formal company at the time. I had deferred all those business activities to Misa, while I focused feverishly on our product to make it work for our pilot client. We had rushed through all legal filings as we applied to YC, but we did not get in. Subsequently, we applied to </span><a href="http://500.co/" style="font-family: inherit; text-decoration: none;"><span style="color: #1155cc; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">500 Startups</span></a><span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;"> and </span><a href="http://alchemistaccelerator.com/" style="font-family: inherit; text-decoration: none;"><span style="color: #1155cc; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">AlChemist</span></a><span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;">, and got rejected by them as well. We also had participated in </span><a href="http://women2.com/2014/01/31/announcing-8th-pitch-finalist-fosubo/" style="font-family: inherit; text-decoration: none;"><span style="color: #1155cc; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">Women 2.0 in February 2014</span></a><span style="color: black; font-family: inherit; vertical-align: baseline; white-space: pre-wrap;">. All these were in the first 6 months of our business! </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">While getting rejected from the accelerators, we were working hard as a team to learn and evolve our business model & product to make it work for T-Mobile franchisees to a point where we were able to convert our pilot client into a paid client by April 2014. After a successful pilot, we were able to sign up couple more franchisees in quick succession. We knew then that we had found our product/market fit in the telecom retail space! During this time we also raised more money from angel investors to help us pay for our operation & customer development costs.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">In May 2014, we decided to apply to </span><a href="http://www.ycombinator.com/" style="text-decoration: none;"><span style="background-color: transparent; color: #1155cc; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">YC</span></a><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> for the second time. This time, to our surprise, we received an offer of acceptance contingent on us making a drastic change to our "CAP" table. YC did not like the fact that Nico and Pato had about 11% equity between them as advisers. They also did not like that Misa and I had unequal shares. They wanted us to bring my equity close to hers and remove Nico and Pato altogether. We desperately tried to figure out ways to accommodate what YC was looking for. However, ultimately we could not find a solution, and our YC hope had died with that (we were invited to apply for the next session if we could take care of the CAP structure issue). We were so close to be part of a great network that every entrepreneur hopes for these days, only for it to be taken away for something I had no control over! It was such a let down.</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">As we were preparing to scale to all T-Mobile franchises nationwide, we were struck by lightening again. One fine morning in June 2014, we get an email from one of our paid clients that T-Mobile Corporate had asked them to stop using Praiseworthy as it was not approved by them. Just like that we had lost all our clients overnight! We scrambled to contact T-Mobile through many different channels to convince them to allow their franchises to continue to use Praiseworthy. Our plea fell on deaf ears! Not ready to give up, we quickly switched gears, and looked into other telecom retailers like AT&T, Sprint, and Verizon. As luck would have it, we had learned that Verizon is not as hands-on with their franchises as other telecom operators are. In two months we were able to sign up couple of Verizon franchises, and were able to show similar positive results as we had shown to T-Mobile retailers. It seemed our fate had started to turn for the better by early September. We were able to line up a few potentially large Verizon franchises- a total of around 2000+ stores among them. </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">And then on a Friday in September (conveniently just a month before my first year vesting date), Misa broke the news that she no longer wanted to work with me. Caught by complete surprise, I was devastated, and frustrated. I found out that Misa with the help of her now Fiancé Nico (they got engaged in June 2014) removed all my access to our systems, email, and everything. I quickly reached out to some of our investors (as it turned out they did not know anything about it either) asking to mediate a reasonable solution. One of the investors agreed to help, but Misa quickly turned down the offer of help. All my attempts at finding a reasonable solution were met with refusal.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">I had trusted Misa and Nico, worked my butt off during the most nascent time of Praiseworthy, had put everything on the line by depleting my savings in the process, only to be betrayed at the end! That's the ugly side of entrepreneurship that is not talked about as much. Sadly, if anything, we see Silicon Valley celebrates the </span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">get-to-success-by-any-means </span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">type of entrepreneurs, and unfortunately some wrongly interpret that as </span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">get-to-success-by-dishonesty</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">!</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Lessons Learned:</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Here are a few things I have learned the hard way from all of this:</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">1) Do a reference check on your potential co-founder(s):</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> This is something I did not do on Misa. Had I done this, I would not have worked with her. I took her Nom Nom story on the face value, and never thought about doing a fact check. As it turns out, when I reached out to her former business partner at Nom Nom, the story was much different. It is not about believing one story over the other. Instead, it would have at least cautioned me to not trust her blindly. The lesson here is to always do a reference check. Any red flag, think twice before partnering. </span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">2) Hire your own lawyer:</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> I trusted Misa to hire a lawyer that represented both of us equally. I signed all papers without really reading them thoroughly and verifying with a lawyer of my own. I had painfully learned later that the lawyer we (on the dime of Praiseworthy) hired did not protect my interests in Praiseworthy. I was not involved in hiring the lawyer, so I am not sure what the conversation was between Misa and the lawyer. Evidently they only protected her interests. The lesson here is make sure to get involved in engaging a lawyer, and / or make sure to get your own lawyer to independently verify that you are protected. </span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">3) Agree only to the same vesting schedule for all:</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> I had naively agreed to a vesting schedule with a one-year cliff, while Misa, Nico, and Pato started to vest immediately. It did raise a concern in my mind at the time, then again I thought we would know in 3 to 6 months whether we can work together. It would become a moot point after a year. Boy was I wrong! The right thing to do is to have all founders on the same vesting schedule. It does not matter who came up with the idea, or who joined when. The standard vesting schedule seems to be 4 years with a one-year cliff. If your potential co-founder seems to think otherwise, run away from that venture!</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">4) Agree only to equal equity structure:</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> I bet YC must have seen many startups fail because of uneven equity distribution. What was even more alarming at Praiseworthy not only Misa and I had a substantial difference in equity, we had Nico and Pato holding a significant share for advisory roles (in their mind they thought they deserved those shares just because they did the hackathon). We all know an idea or an early prototype is nothing but just that. Over the course of a startup's lifetime the idea and the product change fast and furious. And it did at Praiseworthy Of all the things, this was my biggest issue in considering joining Praiseworthy, yet I had given in. It is not so much that I should have a bigger share, but it goes to show the mentality of the potential partners. The lesson here is that If you see similar mentality in your potential co-founder (that is an entitlement to larger share for any reason other than putting up dollars as an investor in addition to being a founder), run! Also, if there is any personal relationship between some of the founders (like Misa and Nico in my case), be weary of that. In my case, it played a huge role in motivating Misa to pull such a move on me!</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">5) Keep a personal record of your communications: </span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">I had all my communications with everyone in my emails and Google docs under my Praiseworthy account. When I was blocked from my accounts I lost everything. The lesson here is to always keep a copy of all communications and documents at a different location- in a personal Dropbox account. And do that periodically! </span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: inherit;"><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">6) Get to know your investors and clients:</span><span style="background-color: transparent; color: black; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> When I was frantically looking for email/phone contacts of our investors I quickly realized that I did not have them. Even more importantly, most of them did not know me in person. I deferred the responsibility of fund raising to Misa, and did not think about building a personal relationship with them. The lesson here is that all founders should get to know all early investors and clients until the company starts to scale. </span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<span style="font-family: inherit;"><span id="docs-internal-guid-57579030-921b-0e45-eed7-80418123a39e"></span><br /></span>
<br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">If you are thinking of starting a new venture with someone you did not work with before, I hope you find these tips helpful and start the relationship on the right foot. I would say this though, I did not lose faith in people. I believe most of us are well intentioned and want to do the right thing. It is just that we get caught up in the short-term greed, and/or misinterpret what we read in the media. Let's promise ourselves to celebrate the right kind of entrepreneurs, and encourage the right kind of behaviors. In the end, fail or succeed, it is the journey that matters more so than the results! We should be remembered for how we made each other and our customers feel more so than what we built!</span><br />
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span>
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">=================== </span><span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><b>Update</b></span><span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">: November, 06, 2016 ===============================</span><br />
<span style="background-color: transparent; color: black; font-family: inherit; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Just learned that Fosubo is now Pariseworthy - a new company, and not a rename! A common move when you want to hide your liability to your future investors. </span></div>
Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com6tag:blogger.com,1999:blog-24947835.post-27257445923114517902015-01-03T20:20:00.003-05:002015-01-03T20:20:37.404-05:00Three Common Struggles of Agile TeamsI have seen three common issues that many Agile teams struggle with. I will try and address them here for future references.<br />
<br />
<b>We need to increase our sprint length...</b><br />
<br />
This usually comes up after a team has gone through a few months of sprinting. Most teams start with 2 weeks of sprint (you cannot go wrong with this choice for an established company/team). Some smaller teams, specially startups choose 1 week of sprint (highly recommend it for startups since product is usually in exploratory stage). However, most teams find themselves not being able to finish what they plan to deliver early on. While it is demoralizing, it is perfectly OK to find yourselves in this situation. Every team goes through this stage (if you hear otherwise, they are lying...:-)). A quick fix for this would seem to be increasing the duration of sprints, right? Wrong. <u>Sprint length as the cause of the problem here is a red herring</u>. The fallacy lies in the thinking that having more time would allow the team to finish everything they plan for. It is a classic fallacy as aptly captured by <span style="font-family: Times, Times New Roman, serif;"><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;"><b>Parkinson's law-</b> </span></span><br />
<br />
<span style="font-family: Times, Times New Roman, serif;"><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;"> <i>"</i></span><i><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;">work expands</span><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;"> so as to </span><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;">fill</span><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;"> the </span><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;">time available</span><span style="background-color: white; color: #545454; line-height: 14.5600004196167px;"> for its completion"</span></i></span><br />
<br />
The issue commonly lies in estimation. There are a few things that cause estimation issue in an Agile environment:<br />
<br />
a. Not being able to break stories. Right sizing stories is tricky and requires experience (trial & error).<br />
b. Not taking into account other regular commitments (production support, company activities, non-project meetings etc) by team members<br />
c. Bug fixes, ad-hoc requests<br />
<br />
All these and other similar activities are most likely taking team's time away from actual project work and not getting reported/visibility for the planning. Team needs to identify those and plug those leaks.<br />
<br />
However, not being able to finish what a team plans to deliver should not come as a surprise at the end of the sprint.<b> </b>This should become apparent thorough the effective use of "<b>Daily Scrum</b>." If it is not happening for your team, revisit how Daily Scrum is being conducted.<br />
<b><br /></b>
<i>The most important aspect of a good Agile team is to be able to <u>proactively manage expectation and eliminate surprises.</u></i><u> </u><br />
<br />
<b>I cannot contribute to estimation as a non-developer (e.g., tester, analyst etc)....</b><br />
<b><br /></b>
Relative estimation can be confusing for people coming from traditional project management. Heck, it is still a conundrum for many of us doing Agile for a while. We understand the basic idea of it. But, probably not comfortable effectively using it in practice. A common question comes up usually from the non-developers on the team is -<br />
<br />
"<i>I'm not a developer so I don't know how long it will take for us to implement.</i>"<br />
<br />
That is a fair concern. However, this concern stems from the assumption that we are estimating only the programming (programmers) aspect of the development. That is partial view of the estimation. The correct way of looking at it is-<br />
<br />
<u>How would you size this story compared to a known story for all the work <b>YOU</b> (not others) need to do in your role (e.g. tester, designer, analyst etc.)? </u><br />
<br />
For example,<br />
<br />
<i>A 5-point story means it is going to take approx. 1.5 time more work for everyone involved compared to the known story estimated to be 3 points</i>.<br />
<br />
Another important distinction of relative estimation from absolute estimation is that we <b>Do Not Add up Points</b> estimated by each role or individuals. We just pick the agreed upon point. Now we could use some heuristics in picking the point estimate after discussing the differences in our estimations. Examples of such heuristics are-<br />
<br />
a. Pick the largest one (it is a safe play).<br />
<br />
b. Pick the majority one (common in practice).<br />
<br />
c. Pick the one based on the nature of the story- e.g., if a test heavy story, give precedence to the estimates by the testers. If it is a design/UI heavy story, e.g., give precedence to the estimates by the designers/front-end developers. You get the idea.<br />
<br />
Couple things to remember about relative estimation:<br />
<br />
a. It is important to be consistent with regards to how you pick the point estimates.<br />
<br />
b. Over time, the team will get efficient with estimation. So, do not worry if it takes longer in the beginning!<br />
<br />
<br />
<b>I don't understand why we need to break our requirements into smaller stories when we know we need the whole thing...</b><br />
<br />
Product owners new to Agile inevitably find it difficult as well as frustrating to be required to break feature sets into stories appropriately sized for implementation in a sprint. While describing requirements as stories is intuitive, breaking stories into smaller stories yet maintain meaningfulness from a user/business perspective is not. It requires practice by trial and error. However, sometimes the importance of breaking large stories into smaller ones are not apparent to the Product Owners. Here are few important advantages of breaking large requirements into smaller stories:<br />
<br />
a. Allows you to roll-out the most important part of the feature set early and get feedback and adjust accordingly.<br />
<br />
b. Allows you to address business risk, or technology risk first with just enough time & money commitment.<br />
<br />
c. Allows the team and the customer/sponsor to maintain a high level energy & momentum derived from the satisfaction of making steady progress (very important, but often neglected aspect of team dynamics).<br />
<br />
d. Avoids implementing unnecessary features. It may not be apparent what parts of a feature set are *actually* necessary. The only way to figure out is by delivering and validating them in small chunks.<br />
<br />
Still not convinced? Would love to hear your particular situation and discuss in the comments section.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com7tag:blogger.com,1999:blog-24947835.post-16523884582472659472013-08-23T21:43:00.000-04:002013-08-23T21:43:06.103-04:00<div class="post_title" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); background-color: white; box-sizing: border-box; color: #444444; font-family: 'Helvetica Neue', HelveticaNeue, Helvetica, Arial, sans-serif; font-size: 22px; font-weight: bold; line-height: 1.3; margin-bottom: 10px; outline: none 0px;">
Refactoring is the hardest skill to master</div>
<div class="post_body" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); background-color: white; box-sizing: border-box; color: #444444; font-family: 'Helvetica Neue', HelveticaNeue, Helvetica, Arial, sans-serif; font-size: 14px; line-height: 19px; outline: none 0px; padding-top: 2px;">
<div style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); box-sizing: border-box; margin-bottom: 10px; outline: none 0px;">
I see a lot of discussions around how to spot a great software developer from an average one. Mind that <strong style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); box-sizing: border-box; outline: none 0px;">I did not say rookie vs. experienced</strong>. I hear many criteria. Years of experience should not be one of the criteria for many reasons. Based on many recent job postings by many hot startups, it seems someone who can whip up solutions to complicated algorithmic problems (a specialist skill), does test-driven development (might show discipline), creates/contributes to open source projects on Github (shows initiatives), active on Stackoverflow (shows initiative and willingness to help besides experience with similar issues), and has a blog (shows initiative and willingness to share) is seen as a great programmer. While I understand the thinking behind them, but I recently realized that a great programmer is someone<strong style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); box-sizing: border-box; outline: none 0px;"> who is proficient at refactoring</strong>.</div>
<div style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); box-sizing: border-box; margin-bottom: 10px; outline: none 0px;">
It is relatively easy to write something from scratch. But it is really hard to incrementally make an existing codebase better while adding new functionality or modifying existing ones. Everyone wants to write new codes for exactly this reason. Let’s face it, we developers never like working on even our own codes written a while back, let alone someone else’s codes. Not only we have to overcome this huge mental block of working with existing codes, but also muster up the courage to deal with the unknowns that come with such efforts- breaking something else, uncovering unpleasant traps, reverse engineering business logic, or writing missing test codes etc. Refactoring requires great design skill, aptitude for quick learning, forensic-style debugging, and discipline as well as patience and grace.</div>
<div style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); box-sizing: border-box; outline: none 0px;">
If you are looking to hire a programmer, why not just ask the potential hire to refactor an existing code that he/she is going to work on anyways, if hired. And observe not only what he does, but also how he does it, and ask why he did the way he did.</div>
</div>
Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-52079435291115251022011-09-14T17:41:00.001-04:002014-07-10T16:06:11.297-04:00Game mechanics in the Enterprise softwareIt boggles my mind how we still tolerate all the incredibly stupid apps (B2B or Enterprise software in general) that we use at our workplace everyday. While consumer apps have shown us what Web apps should look like in the 21st century, enterprise software, even the ones that are currently being built (might I say in the process of re-platforming- from Mainframe to Java / .Net), are still in the dark ages. There are a few reasons for these,<br />
<br />
1. Strict adherence to specification, hence no room for innovation,<br />
2. Strict focus on correctness of features rather than usability & user engagement,<br />
3. Fear of challenging status quo,<br />
3. Generational gap (not in literal sense) between the people (developers) who work on enterprise apps vs who work on consumer apps.<br />
<br />
Recently I came across <a _mce_href="http://www.feld.com/wp/archives/category/enterprise-20" href="http://www.feld.com/wp/archives/category/enterprise-20">a few posts</a> by Brad Feld on the same topic dubbed as <b>Enterprise 2.0</b>. These posts are a bit dated (in 2007/2008). It is now almost the end of 2011. I guess Enterprise is not quite social yet. I would still agree with Brad that the <b>Enterprise software is ripe for disruption more now than ever before</b>. However, I would look at this disruption from a different perspective- <b>usability and engagement</b> than <b>social</b>. In consumer space, apps became social (interaction with friends) first before they became usable and engaging (through game mechanics). While making the enterprise software social (interaction with colleagues; see what I mean <a _mce_href="http://www.feld.com/wp/archives/2008/06/facebook-for-the-enterprise.html" href="http://www.feld.com/wp/archives/2008/06/facebook-for-the-enterprise.html">here</a>) may seem interesting, I contend that it is not as beneficial as making these apps highly usable and engaging in and of itself using game mechanics.<br />
<br />
Here are <a _mce_href="http://blog.syedrayhan.com/2011/08/7-usability-guidelines-for-developers.html" href="http://blog.syedrayhan.com/2011/08/7-usability-guidelines-for-developers.html">few trends in usability</a> that enterprise software can easily adopt. Applying game mechanics on the other hand could be tricky and will require analysis of the domain as well as business goals. Nevertheless <b>badges, points, voting, recommendations, check-ins</b> coupled with <b>clever data visualization</b> can be put together in a way to foster right collaboration and coopetition among employees (in other words encourage right behavior) to achieve business goals faster. In fact, enterprises can tweak these elements in a way to encourage a work culture that is unique, and thereby gain competitive advantage.<br />
<br />
Are you using any application at your workplace that has these features already? Or are you currently working on a project where you are going to implement / experiment with some of these features? Or, I would love to hear how you would incorporate game mechanics in the apps you use at your workplace.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-33819833317235940312011-08-19T14:44:00.005-04:002011-08-22T18:56:57.676-04:00A simple guide to effective loggingOne of my coding pet peeves is lack of useful log messages. While logging is the simplest, yet effective tool in a developer's arsenal, it is often the most neglected one. We developers do not take the time to think through what and where we should add log messages in our codes.<br />
<br />
We tend to use only "<b>error</b>" and "<b>debug</b>" level log messages. We use "<b>debug</b>" messages to help test our codes during development stage. But we add these debug messages on an ad hoc basis. And, our applications usually do not have debug level turned on in production (and we don't want to). The only other time we log messages is when there is an error or exception. This is partly because traditionally developers are not required to provide operational support for the software they write. They are usually removed from production support by 1 or 2 levels- a support team in the client's organization and then another in their own organization. With SaaS model, this separation is going away to some extent, but the issue persists. Well thought out log messages can save a lot of time & frustration with debuging production issues. <br />
<br />
Here is a set of rules I use when I write codes,<br />
<ol><li>Use a good mix of 4 levels of log messages- error, warn, info, and debug. </li>
<li>Usually "<b>info</b>" to "<b>debug</b>" ratio is 30%. </li>
<li>"<b>Info</b>" is the most important log level from operations perspective, yet the most neglected and misunderstood one. Systems should run at info level. I see it as the "<b>system's</b> <b>heart beat</b>." At any point in time, anyone should be able to say how the system is doing by reviewing info messages. The trick is to achieve that using the minimum number of messages with just enough useful information.</li>
<li>Use "<b>info</b>" message to trace high level application flow.</li>
<li>Use "<b>debug</b>" message to trace detailed level application flow. Never use "<b>system.out</b>" messages. </li>
<li>Use "<b>warn</b>" level messages when system can recover from a failure. Also use warn when a user is doing anything unusual, i.e. multiple attempt to login, or trying to access functions that they are not supposed to etc. This is specifically useful in the SaaS systems. "<b>Warn</b>" messages can serve as an early warning signal.</li>
<li>Send email when an "<b>error</b>" message is logged. Do not use "<b>error</b>" level if you do not want to receive an email about it.</li>
<li>Be vigilant about what data you write out in a log message. Only enough data to help track activities, but never any security sensitive data (in the context of the domain).</li>
<li>Add context to the log messages. For example, date & time, line#, class name, method name, session id, user id etc. Logging frameworks available in most languages now-a-days are designed after "<a href="http://logging.apache.org/log4j/1.2/">log4j</a>," one of the most well-designed framework by <a href="http://ceki.blogspot.com/">Ceki Gülcü</a>. Log4j and similar frameworks make it easy to automatically add this context to all messages. </li>
<li>Format log messages in a way so that it is easy to plop them into a tool like Excel for easier analysis. Here is <b>an example of a good formatted log message</b>,</li>
</ol><blockquote><i>[ DEBUG] | 110817 21:28:58 | pid-609 | user 2 | session 12345 | controller | effective_logging.rb:17:in `descope_multiple' | wi 12 descoped </i></blockquote>Here is an example code showing a good mix of log messages used:<br />
<script src="https://gist.github.com/1157557.js?file=effective-logging.rb">
</script><br />
<br />
<br />
What guideline do you follow for logging?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com35tag:blogger.com,1999:blog-24947835.post-85675815459779311002011-08-10T15:42:00.000-04:002015-01-03T20:21:18.664-05:007 usability guidelines for developersOver last year, as we worked on improving the usability of ScrumPad, we learned a few things that are not so obvious to us "<strong>Developers</strong>." The conventional wisdom is that usability is something developers don't understand, or should defer to interaction designers. Some aspects of interaction design probably require specialist skills. But, here are seven things that we developers could easily do to improve usability by an order of magnitude. <br />
<strong>1) Choose an appropriate default behavior.</strong><br />
Most applications have a default use case. This is usually implemented through some parameters with some default values. But, we do not take time to carefully analyze and understand this default use case. It is an after-thought or an ad hoc decision most of the times. Worse, we defer this to users by making them go through an elaborate setup process to pick the default values. We feel that <u>users would feel empowered</u> if we make them explicitly set these values themselves. As it turns out,<u> most users want to get up and running right away</u> and expect the application to just work. Customization, if necessary, should be "<strong>as and when</strong>" needed, and should be presented to the users in the context of their actions (and not as a separate action). We call it "<strong>on-demand incremental context-sensitive customization</strong>." For example, in ScrumPad, users can create a project with 2 weeks sprint as a default (they don't have to do anything extra). When they define sprints, the system would set the end date 2 weeks apart from a given start date. We even help pick the start date based on the last sprint / current date. We also pick the name of the sprint as "<em><u>Sprint#count<count></count></u></em>." However, users can change the length of a particular sprint by changing the pre-populated dates, or they can change the name of the sprint, if they want to, when creating the sprint. It may seem trivial, and it is, but this little thought about default behavior can greatly enhances the user experience. <br />
<br />
<strong>2) Minimize required information.</strong><br />
Most applications have forms to collect different data. Some of the elements on these forms are required and some are not. We tend to make more data required than we ought to. What we found is that most of the time we over think what we should make mandatory when we collect data from users. We should really question our assumptions about what we think are really necessary. We need to allow users to move forward with the minimum information and let them provide rest of the information "<strong>as and when</strong>" necessary. We call it "<strong>on-demand incremental context-sensitive data collection</strong>." Amazon does it really well. You can start shopping without needing to login. You are prompted for login at the last possible moment. We see this also in signup process for most of the new breed of Web applications. In ScrumPad, we used to force users to pick tags when adding stories. We thought we were helping the users by forcing them to think about themes / grouping for their stories at the time of creation. Our users did not see it that way, instead they found it annoying / limiting. We changed our mind and now it is an optional element, and the users are happy!<br />
<br />
<strong>3) Trust users, not constrain them.</strong><br />
We tend to design our applications around the idea that our users, if allowed, would do things that they are not supposed to. If somehow we prevent them from doing "<strong>not allowed</strong>" things through different roles, we would help them. This Also gives us a false sense of satisfaction that our applications would become more secured. This was the case with ScrumPad when we initially designed it. Scrum promotes three roles- Scrum Master, Product Owner, and the team members. As any purist would do, we segregated these roles very strictly. As a result, we were forcing our users to fit into these straight jackets and made their lives difficult. As we faced with different real world situations, we started to relax some of these constraints by allowing users to be in multiple roles. Still with that, it felt like it was a work-around rather than natural. We started to question our assumption that we need to prevent one role from doing things that usually is expected of from another role. We came up with two reasons why we do this. One, we are afraid that we won't be able to track who did what. We could easily address this concern by implementing tracking "<em>change history</em>." Second, we are afraid that people will be confused about what a role entails. If this is the case, then we have a bigger issue than what a tool allows us to do. However, we are certainly not suggesting that we should allow everyone to do everything. Of course, we need to draw some lines among different roles, but we should minimize them to improve user experience with our system.<br />
<br />
<strong>4) Mange the context.</strong><br />
All user actions have contexts. <u>The context depends on what action was taken just before, what role a user is in, the location a user is coming from, what time of the day it is now, etc. etc. among many other things.</u> Most applications don't do a good job of taking all these into account and making it easier for users to perform the action. For example, if you go to "<em>Groupon</em>" site for the first time, it forces you to choose a city or login/signup before you can see the current deals, whereas if you go to "<em>Livingsocial</em>" site, it recognizes your location, and allows you to go the current deals page for that location. Which one do you think is more user-friendly? Manging the context is becoming easier and richer (with location and other contextual inputs from other connected apps- i.e. social networks) now-a-days. It is in fact expected of applications to manage the context more intelligently.<br />
<br />
<strong>5) Personalize interactions.</strong><br />
Personalization has become popular among applications now-a-days. We see this commonly implemented as "<strong>My page/data/tasks<page data="" tasks=""><page data="" tasks=""></page></page></strong>," popularized by "<strong>iGoogle</strong>" type personal Web portal sites. However, it is more static in nature, and requires the users to set it up. We can harness the power of personalization even more by making this more dynamic in nature. For example, what it means in ScrumPad is keeping track of report / search queries recently run, or the projects/stories recently viewed, or discussions recently participated in, or even better, organizing menus based on the usage pattern.<br />
<br />
<strong>6) Don't interrupt, allow "undo".</strong><br />
Traditionally we have designed applications with many little interruptions in the form our pop-up prompts. This form of interaction design has been popularized by Microsoft. Here is a good illustration of this by <a href="http://businessofsoftware.org/video_09_jspolsky.aspx">Joel Spolsky in his Business of Software conference talk</a>. The most common and popular of such interruptions is a "<strong>delete prompt</strong>"- asking user to confirm their intent to delete something. The thought behind it is users might accidentally clicked "<strong>delete</strong>," when he did not mean to. We know these situations are rare. We are interrupting all users most of the time for those rare occasions. Google has shown how we could avoid these type of interruptions by implementing "<strong>undo</strong>." We don't have to implement/support "undo" for all users actions. Given the context and domain of the applications, we could pick and choose actions that could benefit from "undo." <br />
<br />
<strong>7) Learn and accommodate.</strong><br />
We are just starting to see more and more applications are designed to learn user behaviors and adjust accordingly. An example of this is Gmail. Gmail recently introduced tracking important emails. It tries to determine whether an email is important based on the context and the past actions by the users- whether the user opens an email from a certain user or with certain subject line for example. Also the users can explicitly tell Gmail which emails are important. Overtime, Gmail gets better at isolating important emails from regular. Recommendation engine (i.e., friend recommendation, content recommendation etc.) is another example where "learning" is applied. I'll use Zynga as an example to illustrate where an application could implement "<strong>learning mechanics</strong>." We all played Zynga's one of many popular games. One thing they encourage is to post status messages from time to time to Facebook. While I understand the motivation behind this, but it provides poor experiences to users who always choose to skip posting such messages. A better thing to do would be to learn the behavior of individual users and stop prompting for posting messages for the users that always/most of the time skip such actions. Instead, Zynga could provide a visible action button to post a message, just in case these users do feel to brag once in a while.<br />
<br />
We can summarize these 7 usability rules into just one as Jared Spool would put it- "<a href="http://www.uie.com/brainsparks/2006/04/20/dividing-user-time-between-goal-and-tool/">increase goal time, reduce tool time</a>." In other words, we should do everything we could to not require users spend time in learning & using the tool (<strong>tool time</strong>) so that they can have more time doing things that they actually want to do (<strong>goal time</strong>).<br />
<br />
The ultimate test of usability lies in how much training users need (in-person training, or help screen casts, or help FAQs) to start using a product. "<strong>A perfectly usable product</strong>" would not need any user manual, or training, or FAQs. <br />
<br />
Do you have any insights for improving user experience? <br />
<br />Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com1tag:blogger.com,1999:blog-24947835.post-47832259872789461222011-07-18T15:02:00.000-04:002011-07-18T15:02:58.919-04:00Using Scrum of Scrum (SoS) as an early warning systemTypically we use Scrum of Scrum (SoS) as a platform to address issues between teams on a multi-team agile projects. Mike Cohen has <a href="http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting">a good post </a>on the basics of SoS. SoS (as the acronym aptly captures this intent) is a good way to synchronize teams and resolve issues as they arise. However, it is a reactive approach. A better approach would be to turn SoS into an early warning platform so that teams can be proactive about imminent issues and prevent them from becoming real issues. In the process save everyone "valuable" times, and probably frustrations.<br />
<br />
With that intent in mind, I suggested the teams of a distributed Agile project that I'm coaching now to use these questions:<br />
1. Is anything slowing my team down or getting in my team's way? <br />
2. Is my team about to put something in another team’s way (DB changes, interface changes, UI changes etc.)? <br />
3. What stories or bugs have been completed by my team since we last met?<br />
<br />
Question 2 primarily, and question 3 to some extent serve as the sources of early warning. However, I quickly realized that teams would not knowingly report that they are putting anything that would impede other teams. So, I changed the question to be more explicit about the intent:<br />
<br />
2. Is my team going to make <em><u>changes to any shared resources</u></em> (DB changes, interface changes, UI changes etc.), or <u><em>checking in significant codes</em></u> by the end of today?<br />
<br />
This seemed to have helped. The Scrum Masters now need to listen in their daily scrum meeting more carefully to understand and be able to answer questions 2 and 3. Additionally, the teams are also tracking any inter-team requests at the SoS meetings. <br />
<br />
How do you use SoS on your project?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com23tag:blogger.com,1999:blog-24947835.post-61624098618943436522011-07-15T14:19:00.000-04:002011-07-15T14:19:04.469-04:00Remote team building on distributed Agile projectsTeam camaraderie is important on any projects, but it is critical on Agile projects because Agile process requires close interactions. If you have distributed teams, it becomes challenging. It is important that you spend some time to make sure the teams gel together to get the best result for your Agile project. <br />
<div> </div>Ideally, you would want to bring the teams together at one location for a sprint at the start of the project. The team members will get an opportunity to know each other while they start working on the project. You may want to do some explicit team building activities. Then you want to bring the teams together every so many sprints, maybe rotating the locations where they come together. Here is <a href="http://jeffsutherland.com/SutherlandFullyDistributedScrumXebiaAgile2008.pdf">a nice case study</a> on this. <br />
<div> </div>Yes, it increases the cost of your project. Given how the economy is, you may not get the budget approved for the travel and associated costs. This is what happened to the project I'm working on as an Agile coach. As an alternative, we came up with a remote team building activity, which truned out to be very helpful. <br />
<div> </div><strong>Some backgorund on the teams</strong><br />
We wanted to faciliate a team building activity between two teams- one located in the West coast, and another in the East coast. The two teams did not know each other. This is the first time they are working together. One team was staffed by people from the client, and the other was by the vendor. As a result, there were some work culture differences. The teams were communicating through Scrum Masters and Proxy Product owners. Developers did not know each other and shyed away from communicating directly. Also getting in the way was the 3-hour time differences between the two teams. Overall, annonimity resulted in lack of trust and was contributing to the overall frustration between the teams. <br />
<div> </div><strong>Remote team building</strong><br />
We decided to faciliate a remote team buidling session using a vedio conferencing session. Prior to the event, we did the following: <br />
<div> </div>1. We created a team profile for each team. It included some intro info about each person with a picture. <br />
<div> </div>2. We paired each member of one team with another from the other team. <br />
<div> </div>3. We sent them a list of questions and asked each pair to interview each other over the phone prior to the team event. A sample set of questions that we used to help prime the conversation: <br />
<div> </div> 1) What is your role on the project? <br />
<div> </div> 2) What is (are) your domain(s) of expertise? <br />
<div> </div> 3) What new capabilities are you learning on the project? <br />
<div> </div> 4) What are your pet peeves at workplace? <br />
<div> </div> 5) Tell us one interesting thing about you that no one knows. <br />
<div> </div> 6) What is your favorite hobby? Why do you like it? <br />
<div> </div> Additonally we asked everyone to pick a question to ask their buddies. <br />
<div> </div>4. The team event was divided into two parts. In the first part, we asked each pair to introduce their buddies to the whole team. In the second part, we made it free form (quizzed the team on what they learned about each other) with a deliberate effort to instigate conversations about things that the teams are struggling with. <br />
<div> </div>Overall, everybody found the team building activity helpful. At the least, it broke the ice between the two teams, got them talking about issues (as you would expect in "<strong>storming stage</strong>" of <a href="http://en.wikipedia.org/wiki/Forming-storming-norming-performing">a team/goup development</a>), and opened up the communication. Some norms are starting to form from the storming. <br />
<div> </div>I do not expect the trust to be built overnight. Still we need to continue to make deliberate efforts in making that happen. But, it was a good start. We plan to do this on a regular interval. <br />
<div> </div>Some of the fun facts about these two teams<br />
<ul><li> One team is a all-women team.</li>
<li> Eleven languages are spoken between the two teams.</li>
<li> Six countries represented based on birth places.</li>
</ul>Do you have a similar experience of team building?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com12tag:blogger.com,1999:blog-24947835.post-9651088546880180442011-04-20T13:45:00.000-04:002011-04-20T13:45:08.739-04:00Product backlog sedimentation patternAre some of your stories in your backlog moving down in priority when new stories are getting added daily and getting scheduled for implementation? Are you worried that you will never get to finish the original scope of your project? Worry no more. It is, in fact, a good sign of a healthy project.<br />
<br />
"<b>Backlog sedimentation</b>" is a pattern seen on an healthy agile project where some of the high priority stories get pushed down by new stories and or lower priority stories bubble up. As the project progresses, you start to collect these original stories at the bottom and hence the sedimentation. This is a result of active feedback at the end of every sprint from users and customers as well as the progressive learning of the team about the domain & technology, and the project. <br />
<br />
If you are happy that your team is making a great progress towards the original scope because they are diligently working down the list of stories you originally put on the backlog, I have a bad news for you. You are most like not delivering what your customers actually want.<br />
<br />
A great sign of a healthy Agile project is an active engagement of the users and customers. The most important sign of actively engaged customer is the quality of feedback that comes out of every review session at the end of each sprint. The outcome of a quality feedback is "<b>new stories</b>" that get prioritized over "<b>existing stories</b>". <br />
<br />
<br />
Now the flip side of feedback is that you may find yourself only working on feedback and never get to make any progress towards the original goal (not scope, mind you). At least, it may feel like so. I would argue that it is a sign of either "<b>the project is</b> <b>not well conceived</b>" or "<b>the priorities are not well understood.</b>" Either way, it is a time to take a step back and have a conversation with your customers and users.<br />
<br />
Ideally the project should reach a harmony between work done based on feedback and work done from the original scope of the project such that the project is moving towards the intended goal. That is the most important job of a successful product owner.<br />
<br />
Have you experienced this on your project? Would love to hear how you are coping with this?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-49415728920702031532010-09-28T14:13:00.002-04:002010-10-01T12:40:55.353-04:008 reasons why Investors won't invest in my startupI 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 <a href="http://37signals.com/rework/">37signal's way</a> to growth and profitability.<br />
<br />
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, <br />
<br />
1. I am building <span style="background-color: white;">"</span><b><span style="background-color: white; color: red;">yet another</span>" project management tool</b>. See <a href="http://onstartups.com/tabid/3339/bid/11978/The-10-Most-Tempting-Software-Startup-Categories.aspx">Dharmesh's post</a> on "<a href="http://onstartup.com/">Onstartup</a>" about this.<br />
<br />
2. My startup is in the B2B space (which takes longer and costs more), when all the craze is in the consumer space. <br />
<br />
3. I'm a 41-year-old, first time entrepreneur, and not charismatic. These days, most entrepreneurs are in their <a href="http://www.siliconbeat.com/2010/01/05/the-innovation-age-bias-at-sequoia-capital/">early twenties</a>. Stats are stacked against my generation.<br />
<br />
4. I don't have <a href="http://venturehacks.com/articles/elevator-pitch">a great elevator pitch</a>, nor do I have <a href="http://venturehacks.com/articles/deck">a great deck</a>. <br />
<br />
5. I don't have a great <b>UX expert</b>, nor do I have a great <b>Customer development / Inbound marketing expert</b> <a href="http://500hats.typepad.com/500blogs/2010/09/dont-startup.html">on my team</a>.<br />
<br />
6. I don't have a popular personal or <a href="http://blog.scrumpad.com/">product blog</a>. In fact, last time I checked, our product blog had a blogger grade of 26 (by the way, I love the graders tools by <a href="http://hubspot.com/">Hubspot</a>.)<br />
<br />
7. I don't live in the Mecca of startup- <b>Silicon Valley</b>, for that matter, not even in <b>Silicon Alley</b>, or <b>Boston</b>. <br />
<br />
8. I'm a first generation immigrant without any "<a href="http://en.wikipedia.org/wiki/Social_proof">social proof</a>." <a href="http://www.businessweek.com/smallbiz/content/jul2010/sb20100723_230223.htm">Stats</a> are again stacked against me. <br />
<br />
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.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com1tag:blogger.com,1999:blog-24947835.post-30482024692769080382010-09-10T16:53:00.001-04:002010-09-10T16:57:16.231-04:00Twitter - "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:<br />
<br />
<b><i> /send myresume @<job poster=""> #LI</job></i></b><br />
<br />
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 <b>realtime news,</b> <b>interactive customer service</b>, or<b> marketing</b> <b>outlet</b>,. However, I believe we are completely missing another aspect of a potential use of Twitter. This is the use of Twitter as a "<b>virtual remote control</b>" of our social networks like <b>Facebook</b>, <b>Linkedin</b>, <b>Foursquare</b>, <b>Social Games</b> (e.g., <b>Zynga</b> games) etc. This will put Twitter in the middle of our virtual social life. Let me explain what I mean.<br />
<br />
To IRC users, the use of commands to control and manage the network is not new. For computer geeks, it is also known as "<b>control data</b>" 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 /<command verb=""> it is intended for the server to take some action in the context on behalf of the sender. For example, if you type </command><br />
<br />
<b><i> /invite Syed #ScrumPad</i></b><br />
<br />
It is interpreted by the IRC server to send an invite to the user "Syed" to join "<a href="http://www.scrumpad.com/">ScrumPad</a>" 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 "<a href="http://factoryjoe.com/blog/2009/11/08/slashtags/">Slashtag</a>." This was introduced by <a href="http://factoryjoe.com/blog/about/" title="New microsyntax for Twitter: three pointers and the slasher">Chris Messina</a>, the guy who also introduced us to the world of "<a href="http://factoryjoe.com/blog/2007/08/25/groups-for-twitter-or-a-proposal-for-twitter-tag-channels/">Hastags</a>."<br />
<br />
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 @<username> in the message). Here is <a href="http://zurairifm.wordpress.com/2010/01/26/a-guide-to-writing-good-on-twitter/">a good guide</a> on how to use them correctly. Most of these evolved organically by the Twitter community. Here is a <a href="http://www.ted.com/talks/evan_williams_on_listening_to_twitter_users.html">TED talk</a> by Twitter founder Evan Williams on the evolution Twitter syntax. </username><br />
<br />
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 "<a href="http://en.wikipedia.org/wiki/Facebook_Platform">InApp</a>" - applications running inside Facebook application. It transformed Facebook from just a social network to "<b>a platform for social network-aware applications</b>." In the same way, if Twitter directly supports and facilitates the flow of control data among different applications, it can become "<b>the hub of our virtual world</b>." It can allow us to have our own "<b>Virtual Remote Control</b>." Let's just call it "<b>TweetMote</b>." Here is what the world would look like with our <b>TweetMote</b> (just checked <i>tweetmote.com</i> domain is not available. Is there any domain available these days?),<br />
<br />
<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3QSnEUuU8TctzHOw2xchooUfDFBxxIRQdlyOkiUFxbn2RYRRshkeX6KEKS4rbm4VXHWXpsf2S4oiqZn4DxwHaKcgSlq1FJsUCIlr5QMgpkACpWN7DRmfIwwpUnUv9ZaJePfl5/s1600/TweetMote.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3QSnEUuU8TctzHOw2xchooUfDFBxxIRQdlyOkiUFxbn2RYRRshkeX6KEKS4rbm4VXHWXpsf2S4oiqZn4DxwHaKcgSlq1FJsUCIlr5QMgpkACpWN7DRmfIwwpUnUv9ZaJePfl5/s320/TweetMote.gif" /></a></div>Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-18547415671214451092010-09-07T14:31:00.002-04:002010-09-07T18:20:38.115-04:00Synchronized dance between customer and product developmentThis 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.<br />
<br />
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 <a href="http://www.scrumpad.com/">ScrumPad</a>, 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 "<a href="http://geeksonaplane.com/">Geeks on a Plane</a>" 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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
<b> Match product development cycle with customer feedback cycle. </b><br />
<br />
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.<br />
<br />
In an essence, a successful transition to "Lean Startup" model requires establishing a rhythm between customer development and product development first.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-74335395311287623382010-03-29T18:02:00.004-04:002010-03-31T16:54:57.308-04:00Iterative funding of startups- an entrepreneur's perspectiveI am a first-time entrepreneur, and have not raised any external funding yet for<a href="http://www.scrumpad.com/"> my venture</a>. 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.<br />
<br />
As I am dabbling with the concept of <a href="http://www.slideshare.net/venturehacks/the-lean-startup-2">"Lean"</a> model of building startup, what I see is missing from the model is the "<b>funding</b>" side of the equation. Traditional sources of external funding are Angels and VCs. We all start our venture with a "<b>big</b>" dream. Yet, the success in our minds is subconsciously anchored in getting "<b>funded</b>," instead of building a "<b>sustainable business</b>." 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 "<b>carefully crafted pitch</b>" and a "<b>big plan</b>." 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 "<b>big waste</b>" hiding in there somewhere. That is why <a href="http://37signals.com/rework/">37signal</a>s guys are so dead against raising money.<br />
<br />
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 <a href="http://www.slideshare.net/dmc500hats/startup-20-from-silicon-valley-to-hong-kong">this presentation</a>. 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 "<b>progressive learning</b>." Dave's funding model has 3 stages-<br />
<br />
1. "<b>Micro seed"</b> (3-6 months) corresponds to "<b>Customer Discovery</b>" stage of "Lean Startup" model. Expect to spend between 0-$100K.<br />
<br />
2. "<b>Seed" </b>(6-12 months) corresponds to "<b>Customer Validation</b>" stage of "Lean Startup" model. Expect to spend about $100K-$1M.<br />
<br />
3. "<b>Series A"</b> (12-18 months) corresponds to "<b>Transition to Growth</b>" stage of "Lean Startup" model. Expect to spend about $1M -$5M.<br />
<br />
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 "<b>iteratively</b>." If externally funded, we set up an MoU with the investors to enable "<b>incremental funding</b>" as opposed to "<b>big upfront funding</b>." The whole model would look something like this,<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvRSmhzYEtyU5jKxgO03h6AMTcsVASM4HOYB6fHu9xJm34PiyAySPWvJosUayBnu3QvaNJTL525p2AiO3Ad2WUMXAa1EyL21sfyLmN6T5yucj07kwl4ZZenQl3F6UZWFZPuPUN/s1600/LeanStartupEngine.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvRSmhzYEtyU5jKxgO03h6AMTcsVASM4HOYB6fHu9xJm34PiyAySPWvJosUayBnu3QvaNJTL525p2AiO3Ad2WUMXAa1EyL21sfyLmN6T5yucj07kwl4ZZenQl3F6UZWFZPuPUN/s400/LeanStartupEngine.jpg" width="400" /></a></div>The goal of funding should be "<b>just enough</b>" funding to "<b>sustainable growth.</b>" 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.<br />
<br />
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.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com10tag:blogger.com,1999:blog-24947835.post-55621928391608474822010-03-26T13:19:00.005-04:002010-03-31T14:13:48.567-04:00Startup wisdoms are plenty, but data are scarceIf you are trying to implement "<b>Lean</b>" model of startup or building <b>SaaS</b> business, you probably are looking for answers to these questions like me-<br />
<br />
<i>What is a typical time a company spends in "<b>customer discovery</b>" (problem-solution fit) in a specific category of application in my industry?</i><br />
<i>What is a typical time a company (in my industry/category) spends in "<b>customer validation</b>" (product-market fit)? </i><br />
<i>What is a typical customer "<b>acquisition</b>" conversion rate in my industry?</i><br />
<i>What is a typical customer "<b>activation</b>" conversion rate?</i><br />
<i>What is a typical customer "<b>churn</b>" or "<b>retention</b>" rate?</i><br />
<i>What is a typical customer "<b>referral</b>" rate?</i><br />
<i>What is a typical <b>CAC</b> or <b>CLTV</b> in different stages of development?</i><br />
<br />
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?<br />
<br />
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. <br />
<br />
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 href="http://cracking-the-code.blogspot.com/">a great blog </a>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 "<b>SaaS Satrtups</b>" without revealing the identity of individual companies. There are some examples of brave individuals- <a href="http://www.balsamiq.com/blog/">Peldi of Balsamic</a>, <a href="http://onstartups.com/">Dharmesh of Hubspot</a> 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<br />
<span class="Apple-style-span" style="font-size: small;"> </span><b><span class="Apple-style-span" style="font-size: x-small;">Stages of Development</span></b><br />
<b><span class="Apple-style-span" style="font-size: x-small;">Industry Category Metric "Customer Discovery" "Customer Validation" "Transition to Growth" Growth</span></b><br />
<b><br />
</b><br />
With a shared database of these metrics, we can become more efficient with our capital, and we all will be better off.<br />
<br />
What do you think of the idea of sharing these data? Am I missing something that would <b>"really</b>" get in the way to start sharing data anonymously? Or, do you think it is not an issue and hence not worth solving for?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com2tag:blogger.com,1999:blog-24947835.post-75828917347896117582010-03-19T11:05:00.000-04:002010-03-19T11:05:20.793-04:00Meet your customer at the doorRecently, I read an interesting <a href="http://market-by-numbers.com/2010/03/natural-experiments-in-product-market-fit-how-to-know-you-dont-have-it/comment-page-1/#comment-415">blog</a> 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.<br />
<br />
We also unknowingly implemented an effective process for exploring product-market fit. Essentially it was <b>embedded</b> in our "<b>customer acquisition</b>" <b>workflow</b>. This is how it worked:<br />
<br />
<b>1.</b> Customer would signup for <a href="http://www.scrumpad.com/">ScrumPad</a> for a 30-day free trial.<br />
<b>2. </b>At any time during the trial period the customer can cancel the trial subscription.<br />
<b>3.</b> We would notify them of upcoming end of trial by email and remind them of explicitly canceling the subscription.<br />
<b>4</b>. If they choose to cancel the subscription, we ask them to take a short "<b>exit interview</b>" (which was optional; we allowed the users to skip the interview) with four questions:<br />
<b>a.</b> <i>Reason for cancellation?</i><br />
1. Speed, 2. Usability 3. Lack of Feature, 4. Price, 5. Any other<br />
<b>b.</b> <i>Switching to another tool? If yes, which tool?</i><br />
<b>c.</b> <i>Reconsider in the future?</i><br />
<b>5.</b> If not canceled before the trial period ended, the account "<b>automatically</b>" rolled into a "<b>paid subscription</b>" (since we do not have any "<b>tiered pricing</b>").<br />
<br />
Requiring explicit cancellation turned out to be a very effective "<b>product-market fit</b>" exploration tool. We almost got <b>100% </b>participation in the "<b>exit interview</b>." There were users who would forget (even after all the reminders) to cancel. When they would get an invoice (the <b>controversial aspect </b>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.<br />
<br />
However, we also quickly learned that some customers considered this to be an "<b>annoying</b>," even "<b>deceptive</b>" practice. Although we <b>never</b> intended to use "<b>auto opt-in</b>" as a way to mislead anyone, we understood how this could be misconstrued as a "<b>bad practice.</b>" It is important for us to do what feels right to our valued customers. So, we now changed the process from "<b>auto opt-in</b>" to "<b>explicit opt-in</b>" (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.<br />
<br />
We have now embedded <a href="http://survey.io/">survey.io</a> 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.<br />
<br />
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.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-25326905375929328232010-02-26T14:11:00.005-05:002010-03-18T18:34:58.986-04:00Why is "Continuous Deployment" challenging for most companies?<a href="http://www.startuplessonslearned.com/2009/06/why-continuous-deployment.html">Continuous Deployment</a> (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 <a href="http://martinfowler.com/articles/continuousIntegration.html">Continuous Integration</a> (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 <a href="http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/">this practice</a> a step further at his company <a href="http://www.imvu.com/">IMVU</a>. 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.<br />
<br />
<b>Review by the product owner.</b> 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 <b>customer development</b> team. At least, the product owner is not someone from the <b>product development</b> team. Even the team is co-located, and there is daily interaction between the development team and the product owner, the product owner should <b>review</b> 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 <b>human review</b> 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.<br />
<br />
<b>Risk vs reward.</b> 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 "<b>scheduled maintenance window</b>" (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.<br />
<br />
<b>Non-backward compatible database changes. </b>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.<br />
<br />
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).<br />
<br />
Are you doing CD? Am I missing something?<br />
<br />
***********************************************************************<br />
<b>Update: </b>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.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-55923744469548329622010-02-05T21:06:00.011-05:002010-02-25T13:33:14.362-05:00Retrospective on ScrumPad Product/Market FitAs I am beginning my journey of Lean Startup with our ScrumPad service, I plan to share my experience along the way.<br />
<br />
The first stop in the journey is "<b>Product/market fit.</b>" 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 <a href="http://www.businessmodelalchemist.com/2005/11/what-is-business-model.html">business model</a> that would work the best, and <a href="http://www.amazon.com/Four-Steps-Epiphany-Steven-Blank/product-reviews/0976470705/ref=cm_cr_pr_helpful?ie=UTF8&showViewpoints=0">a repeatable sales model</a>.<br />
<br />
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.<br />
<br />
<b>Version 1- Free ScrumPad: 2008 Retrospective</b><br />
<b>What was our hypothesis?</b><br />
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. <br />
<br />
<b>How long did we spend to validate this hypothesis?</b><br />
6 months.<br />
<br />
<b>What did we do during this period?</b><br />
<ul><li>We primarily focused on adding functionality (product development, not <a href="http://www.startuplessonslearned.com/2008/11/what-is-customer-development.html">customer</a>.). We thought more functionality = more satisfaction = more users. </li>
<li>We were releasing incremental version of ScrumPad every two weeks using <a href="http://www.scrumalliance.org/learn_about_scrum">Agile/Scrum</a> process.</li>
<li>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). </li>
<li>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.</li>
<li>We did not charge for our service. We thought we need to first build out the full product (not thought about an <a href="http://venturehacks.com/articles/minimum-viable-product">MVP</a>) before we can start charging.</li>
<li>We did put some basic tracking- <a href="http://www.google.com/analytics/">Google analytics</a> 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. </li>
</ul><b>What was the result?</b><br />
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.<br />
<br />
<b> New <span class="Apple-style-span" style="font-weight: normal;"><b>Bounce <span class="Apple-style-span" style="font-weight: normal;"><b>Avg. <span class="Apple-style-span" style="font-weight: normal;"><b>Time <span class="Apple-style-span" style="font-weight: normal;"><b>Pages </b></span></b></span></b></span></b></span></b><br />
<b>Visits rate on Site per visit</b> <b>Conversions</b><br />
3,521 48% 00:02:50 2.61 5%<br />
<br />
<b>What did we learn?</b><br />
<b>Our product is better than the opensource counterparts</b>. However, as a paid service, we did not learn anything about whether we have a market yet as a paid service.<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>Version 2- Commercial ScrumPad: 2009 Retrospective</b> </div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>What was our hypothesis?</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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 <a href="http://www.kenan-flagler.unc.edu/">UNC</a> helped).</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>How long did we spend to validate this hypothesis?</b> </div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">All of 2009.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>What did we do during this period?</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"></div><ul><li>We changed our logo, updated the UI, and continued to tweak the interface to improve usability. </li>
<li>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. </li>
<li>We started actively asking for feedback. We in fact incorporated a short exit interview during the cancellation process. </li>
<li>We started charging for our service. </li>
<li>We still did not do any CPC marketing. We wanted to focus on word of mouth. We added affiliate program instead. </li>
</ul><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>What was the result?</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">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 "<b>trial to subscription</b>" business model, we finished the year with a few paying customers, but no new customers through our affiliate program.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b> </b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b> New <span class="Apple-style-span" style="font-weight: normal;"><b>Bounce <span class="Apple-style-span" style="font-weight: normal;"><b>Time <span class="Apple-style-span" style="font-weight: normal;"><b>Pages per <span class="Apple-style-span" style="font-weight: normal;"><b>Conversion</b></span></b></span></b></span></b></span></b><br />
<b>Visits rate Avg. <span class="Apple-style-span" style="font-weight: normal;"><b><span class="Apple-style-span" style="font-weight: normal;"><b><span class="Apple-style-span" style="font-weight: normal;"><b>on<span class="Apple-style-span" style="font-weight: normal;"><b> Site visit</b> <b>Trial Trial to Paid</b></span></b></span></b></span></b></span></b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> 7,578 38% 00:04:23 3.72 4% 4%</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><b>What did we learn?</b></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Since we have customers who are now paying for our service, <b>there exists a market who are willing to pay for our service at the price-point we are offering now</b>. 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.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">In hindsight, I believe what we achieved in 18 months or so, we could have learned even more in 6 months or less using <a href="http://www.startuplessonslearned.com/2008/09/lean-startup.html">Lean Startup</a> techniques. More on what's next from here. </div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div>Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com7tag:blogger.com,1999:blog-24947835.post-32697203037477383182010-01-29T03:41:00.002-05:002010-01-29T04:06:44.856-05:00Three Startup triplets that I likeRecently <a href="http://onstartups.com/About/AboutOnStartupscom/tabid/5219/Default.aspx">Dharmesh Shah</a> blogged about <a href="http://onstartups.com/tabid/3339/bid/11539/Startup-Advice-In-Exactly-Three-Words-StartupTriplets.aspx">Startup triplets- startup advice in exactly three words.</a> 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.<br />
<br />
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.<br />
<br />
<b>Just do it.</b> 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<b> beginning</b>, there is no <b>being</b>. We will make mistakes. We will fail. But we will know that we tried, which is lot better than then living with "<b>what ifs</b>." <a href="http://kevindewalt.com/blog/about/">Kevin Dewalt</a>, summed it up nicely on<a href="http://kevindewalt.com/blog/2009/11/19/5-reasons-to-start-a-company-that-will-fail/"> his blog</a> and I quote,<br />
<blockquote><span class="Apple-style-span" style="color: #111111; font-family: Georgia, 'Times New Roman', Times, serif; font-size: 14px; line-height: 22px;"><i>Entrepreneurship tests us like few things in life. Jobs are trivially easy in comparison.</i></span><i> </i><span class="Apple-style-span" style="color: #111111; font-family: Georgia, 'Times New Roman', Times, serif; font-size: 14px; line-height: 22px;"><i>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</i></span></blockquote><br />
<b>Build, measure, learn.</b> The essence of "<a href="http://www.startuplessonslearned.com/2008/09/lean-startup.html">Lean Startup</a>." 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.<br />
<span class="Apple-style-span" style="color: #414141; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small;"><span class="Apple-style-span" style="font-size: 13px; line-height: 21px;"><span class="Apple-style-span" style="color: black; font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium; line-height: normal;"><br />
</span></span></span></span><br />
<b>Support customers maniacally. </b>This is our ultimate goal. Anything else we do are means to this end. I recently stumbled on <a href="http://blog.scoutapp.com/articles/2010/01/26/developer-run-business-advantages">a post</a> by the guys over at <a href="http://scoutapp.com/">Scout</a>. 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 "<a href="http://venturehacks.com/articles/customer-development">customer development</a>." <br />
<br />
What's yours and why?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0tag:blogger.com,1999:blog-24947835.post-64135205118515870892010-01-19T12:06:00.001-05:002010-02-23T23:05:10.489-05:00Retrospective from a first-time entreprenure<div style="text-align: left;">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.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><b>Getting used to no-paycheck is difficult.</b> I quit my fulltime job to focus on my startup, <a href="http://www.code71.com/">Code71</a>, (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).<br />
<br />
<b>Brother and wife as co-founders. </b>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.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><b>Emotional roller-coaster. </b>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.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><b>Clients amplify emotional roller-coaster effect.</b> 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.</div><div style="text-align: justify;"><div style="text-align: left;"><br />
</div></div><div style="text-align: justify;"><div style="text-align: left;"><b>Saying "No" is difficult.</b> I would say "Y<b>es</b>" 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 "<b>No</b>" to a "<b>potential revenue source,</b>" 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 "<b>carrot</b>"), 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.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><b>Product vs Service.</b> 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 <a href="http://www.scrumpad.com/">ScrumPad</a> 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 <a href="http://www.startuplessonslearned.com/2008/09/lean-startup.html">lean startup</a> 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.</div></div><div style="text-align: justify;"><div style="text-align: left;"><br />
</div></div><div style="text-align: justify;"><div style="text-align: left;"><b>It's not a sale until you get paid.</b> 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.</div><div style="text-align: left;"><br />
</div><div style="text-align: left;"><b>Client feedback can be harsh.</b> 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.<br />
<br />
Are you an entrepreneur too? Please drop a few lines to compare notes.</div></div><div style="text-align: justify;"></div><div style="text-align: justify;"><div style="text-align: left;"><br />
</div></div>Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com2tag:blogger.com,1999:blog-24947835.post-35701273525333051272009-12-14T10:03:00.019-05:002009-12-15T10:42:18.316-05:00They stole my startup ideaI recently came across <a href="http://steveblank.com/2009/12/03/someone-stole-my-startup-idea-%E2%80%93-part-1-are-those-my-initials/">a series of posts</a> by <a href="http://steveblank.com/about/">Steve Blank</a> on how couple of his ideas were stolen. This reminded me of somewhat similar thing happened to me a few years ago. I want to get it off my chest by sharing it here. So, here it goes.<br /><br />In 2004, I was toying with a business idea that I had for sometime and finally decided to put it on paper and get some feedback. I was still working a full-time job then. The idea was about leveraging the growing popularity and penetration of mobile phones in the villages of <a href="http://en.wikipedia.org/wiki/Bangladesh">Bangladesh</a> (that's where I am originally from). Although the poor farmers were using the phones to find out prices in the market, but it was limited in scope. The farmers were still going through the middlemen who were taking advantage of the price arbitrage that existed because of lack of market information available to the farmers. So, I thought what if we enabled a market place over this growing network of mobile phones and help cut out the middlemen. Fittingly, I called my venture " <span style="font-weight: bold;">Grameen Bazaar.</span>" I thought who would be better to seek advice from than the person behind the company called "<a href="http://www.gp.com/">Grameen Phone</a>" that, in partnership with the "<a href="http://www.grameen-info.org/">Grameen Bank</a>" (the organization behind the micro lending), brought the phones to the poor. My expectation was to see what he thought about the idea and possibly convince him to get involved in some capacity. So, I contacted him by email and sent him my biz plan. Then scheduled a phone call to discuss my idea. I was excited to talk with him on the phone only to be disappointed. He was less than encouraging. He was busy with other ventures that he would not have time to help me out. So, what I did as most wanna-be entrepreneur would have done- shelved my idea and moved on.<br /><br />Fast forward a couple years. It was 2006, I finally quit my job to plunge into my first entrepreneurial venture (<a href="http://www.code71.com/">Code71</a> and <a href="http://www.scrumpad.com/">ScrumPad</a>). I had to travel to Bangladesh (that is where I setup our offshore development center). At that time I came across this new company called "<a href="http://www.cellbazaar.com/web/">Cell Bazaar</a>." I naturally got interested and did some digging around. To my surprise, I found out, you guessed it right, that the founder of the company sure enough was the younger brother of the person I had spoken to about "Garmeen Bazaar." I was sad to learn this, not because they pursued my idea, but because I was not acknowledged in some manner- privately or otherwise.<br /><br />I was happy to see someone working on an idea that I also thought worth pursuing. I subscribe to the idea that <a href="http://www.squidoo.com/seth">Seth</a> always preaches- spread ideas, don't protect them. I understand that the fact of the matter was I just had an idea and did not act on it, and someone did. I guess I just wanted to see a little professional courtesy extend to me when they had decided to pursue the idea by dropping me a line-<br /><br />"<span style="font-style: italic;">Hey, My brother decided to pursue the idea you shared with me. If you are still interested, let's chat again.</span>"<br /><br />Am I being too sensitive about this whole thing? What do you think?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com5tag:blogger.com,1999:blog-24947835.post-50863208057531810802009-12-09T16:45:00.019-05:002009-12-20T15:59:18.434-05:00Lessons learned as a SaaS startup product ownerIt's been almost 2 years since we (<a href="http://www.scrumpad.com/">Code71</a>) embarked on a journey of building a SaaS product called <a href="http://www.scrumpad.com/">ScrumPad</a>. I have been playing the role of a product owner (PO). Although I have played the PO role on projects/products for our customers, being a PO of your own product is quite different. I thought it would be good to take some time and jot down my experiences so far. So, here it goes:<br /><br /><span style="font-weight: bold;">Minimum viable product (MVP).</span> Initially I did not really think in terms of let's build an MVP and put it out there for feedback & iterate. We took on this initiative to meet our needs based on our dissatisfaction with the choices available in the market at the time. So, I gave a free reign to my team to build out features. We were stung by that "<span style="font-weight: bold;">SNT</span>" bug as <a href="http://onstartups.com/tabid/3339/bid/6739/Entrepreneurs-and-Hey-There-s-A-Shiny-New-Thing.aspx">Dharmesh</a> puts it. The results was, you guessed it, a sprawling a set of features. When we realized that we had piled on too many features too quick, it took us sometime to cleanup the clutter. It still is not easy, but I am getting better at restraining my and my team's enthusiasm around new features.<br /><br /><span style="font-weight: bold;">Usability and performance.</span> We were focused on features rather than usability in the beginning. We thought getting the features right is more important than making them feel right. Boy, were we wrong! It hurt us more than anything else. We are still working on getting this right. I realize that this is an on-going effort. You are <span style="font-weight: bold;">never done</span> with usability and performance. In the Web 2.0 world, it is in the front and center of any product development. I now have <span style="font-weight: bold;">at least one story in each sprint</span> that focuses on usability and performance.<br /><br /><span style="font-weight: bold;">Brand.</span> I thought a nice logo and a design theme can always be added later. So, I continued to put it off until when I realized lack of it is causing inconsistency in user experience. When we added a well thought out design with logo, the impact was clear. I wish we did this at the beginning. We could have saved some rework and retained some early adopters. A product without a design theme is like a boat without a radar.<br /><br /><br /><span style="font-weight: bold;"><span style="color: rgb(51, 51, 255);">Idea</span>, Build, <span style="color: rgb(51, 51, 255);">Product</span>, Measure, <span style="color: rgb(51, 102, 255);">Feedback</span>, Learn.</span> Yes, this is the "<a href="http://www.startuplessonslearned.com/2008/09/lean-startup-comes-to-stanford.html">lean startup</a>" cycle introduced by <a href="http://www.startuplessonslearned.com/2008/10/about-author.html">Eric Ries</a>. This is Agile applied to Startups. Although we were doing Agile/Scrum even before we started working on our ScrumPad product, it was limited to only our engineering process. I came across the "<span style="font-weight: bold;">lean startup</span>" framework when I met <a href="http://500hats.typepad.com/500blogs/about-dave-mcclure.html">Dave McClure</a> and Erik Ries this September during the "<a href="http://geeksonaplane.com/">Geeks on a Plane</a>" trip to Europe. I realized what is missing from what I am doing as a PO is driving product development decisions based on the rigor of "<span style="font-weight: bold;">measurement-based learning</span>." We had a basic tracking (e.g., basic Google tracking, custom "project activity index") setup. It was not anything close to what Dave describes in his <a href="http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-startonomics-hawaii-nov-2009">AARRR</a> (<span style="font-weight: bold;">Acquisition, Activation, Retention, Referral, and Revenue</span>) framework for startups. Even the minimal tracking (project activity index) we put early on helped us quickly detect a potential issue we had with our initial setup process after registration. However, I always was torn between working on <span style="font-weight: bold;">"</span><span style="font-weight: bold;">a product feature</span>" vs. <span style="font-weight: bold;">"</span><span style="font-weight: bold;">a tracking feature</span>." Always the former would win over the later. Now, I realize it is not one or the other. They are one and the same. I need to rollout a feature along with the ability to track and measure its impact on one or more AARRR metrics.<br /><br /><span style="font-weight: bold;">Charging early.</span> When we decided to open the door to our service for others, we offered it for free. It did not feel right to ask people to pay for a product that is in early development phase and not stable. I thought I would not get people to use our product and provide us "<span style="font-weight: bold;">useful</span>" feedback if I charged. The reality was quite the opposite. Yes, we saw people singing up for our service. We were excited. We were getting some feedback, but none took the time to point out what was working and what was not. So, we continued to focus on thnigs that did not matter to our users. Sure enough, when we finally thought we were ready to start charging for our service, the users fled in all directions. It was demoralizing for us, but interesting to me to experience it first-hand the importance of "<a href="http://onstartups.com/tabid/3339/bid/105/Web-2-0-Revenues-Charge-Early-Charge-Often.aspx"><span>charging early, and often</span>.</a>" It took us some time to build our user base back again. This time with the fees in place, we see a stark difference in the quality of feedback. It is because now the users have a skin in the game.<br /><br /><span style="font-weight: bold;">What kept us alive?</span> As you can see I made all the mistakes I can make as a first time entrepreneur PO. However, I believe we did a few things right that helped us survive our mistakes so far. <span style="font-weight: bold;">First</span>, we were putting out a new <span style="font-weight: bold;">release every two weeks</span> since we started working on ScrumPad. <span style="font-weight: bold;">Second</span>, I was able to muster up courage to stop adding new features and <span style="font-weight: bold;">focus on re-factoring</span> to get us back on track. <span style="font-weight: bold;">Last but not least</span>, I ignored the temporary inconvenience to users when we were making changes to the look and feel incrementally, even if it meant some parts of our site looked completely different from another.<br /><br />Now with 2010 around the corner, I am ready to drive our product development pivoted in the lean startup concepts. I'll report back on how it is going some time next year.<br /><br />Are you a PO of a startup SaaS product? I would love to compare notes. Please drop a few lines.Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com4tag:blogger.com,1999:blog-24947835.post-53935918979243997102009-11-20T08:56:00.004-05:002009-11-20T10:15:30.174-05:00Why open-source project management tools do not flourish?Unlike other open source tools, the open-source project management (PM) tools are miles behind from their commercial counter parts. I have always wondered why? Most of the projects have very low development activity, if at all. Did you wonder why too? Recently, I attended a DC Scrum user group meeting where we were discussing why we chose the tools that we are using to manage our Agile projects. Suddenly, I had this "<span style="font-weight: bold; color: rgb(51, 51, 255);">aha</span>" moment.<br /><br />If we think about it for a moment, we will realize that we all have different ideas as to what to expect from a PM tool. We all know what some of the core features should be, but we most likely would disagree on how to go about implementing them. These differences are not technical in nature. We can be very opinionated about the details of these requirements. It is like choosing what to ware. As a result, most project management tools embody the view of the development team, the product owner to be specific. As a user, we choose the one that most closely matches our view of the world. Even if we somewhat like one, we would move on to something else and would not have the patience to wait for the tool to catch up to our taste. We act like we have ADD when it is about choosing a PM tool.<br /><br />Since these open-source projects do not have a passionate product owner, there is no single ownership of a cohesive view to pursue. As a result, a developer will start working on implementing one because he has this unique idea about what this PM tool should look like, but will find it difficult to have other developers to agree with that view. Worse, he will find it even more difficult to find users who will like his view and support his effort by actively using the tool. Heck, even the developers would not use their own tool to manage their project. We know an open-source project would need an active user base to sustain and flourish.<br /><br />The only way to have a project management tool to survive is a team's persistence with the tool in the early stage of the development. This is only possible in the commercial world. Each of these companies are pursuing their unique vison of what a PM tool should be in the hope that there is a large enough user base (who subscribes to this vision) to sustain their development. Thanks to all these companies sticking to their guns irrespective of the diverse nature of a very discerning users group (that is us).Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com2tag:blogger.com,1999:blog-24947835.post-70363299931201729032009-11-11T15:33:00.010-05:002009-11-17T01:33:47.466-05:00Should fixing bugs contribute to a team's velocity?I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define <a href="http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1110">velocity</a>. Let's look at both in more details.<br /><br /><span style="font-weight: bold;">Value perspective.</span> If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "<span style="font-weight: bold;">incremental value</span>" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.<span style="font-weight: bold;"><br /><br />Cost perspective.</span> If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- <span style="font-weight: bold;">feature-delivery</span> velocity, and <span style="font-weight: bold;">bug-fix</span> velocity. This is in a way going back to the first option.<br /><br />I personally am in favor of using "<span style="font-weight: bold;">value</span>" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "<span style="font-weight: bold;">customer value</span>." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in <a href="http://www.scrumpad.com/">ScrumPad</a>.<br /><br />Are you including your effort spent on bug fixing in your velocity?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com6tag:blogger.com,1999:blog-24947835.post-57051127941431269662009-09-30T15:22:00.005-04:002009-09-30T16:09:58.146-04:00Freemium model for SaaS pricing is broken!Recently I got this email from one of the SaaS companies that they are going to increase the subscription fees. The reason they stated was that their costs have gone up due to a surge in subscription for their free plan. That got me upset because what they are essentially asking is that we the paid customers have to subsidize the others who are using their service for free. Although I appreciate their candor (albeit it is a mistake from marketing perspective), but I find it difficult to accept. It is not right to pass the costs you incur for your "<span style="font-weight: bold; color: rgb(0, 153, 0);">free plan</span>" on to your paying customers.<br /><br />It got me thinking that the popular "<span style="font-weight: bold; color: rgb(0, 153, 0);">freemium</span>" business model is not kosher from ethical perspective. I am sure this company is not the first to find itself in this situation. It is common to offer a free plan to attract new customers. Yet companies cannot continue to pay for the free service as their free customers increase. They are forced to pass the costs along to their real customers- the ones that pay. Not everyone admits this problem. Instead all companies bake the cost of free plan into their paid plans. Don't you think it is unethical? How would you feel about paying for a service that offers a free plan knowing now that you are subsidizing others?<br /><br />There is another issue with the freemium model. You start with the free plan. As you start using the service more, you need to move to one of the paid plan. Did you consider that your costs of using the service is has just gone up both at the aggregate (which is understandable) level as well as unit level (which I have a problem with)? You will never see your unit costs go down. Shouldn't it be the other way around? That is your unit costs for a service should go down as you use more. You should expect volume discount, right? The vendor should encourage more usage of it services by providing volume discount. In reality, we see quite the opposite. Talk about misalignment of goals. Win-lose or lose-win proposition. When customers use free service, customers win but vendors lose. When customers use paid services, vendors win but customer lose.<br /><br />Why not we all only offer free trial and make all out plans paid plans? Nobody subsidizes anybody. Customers get an opportunity to try things out before they pay for it. Vendors do not have to worry about how to pay for free plans. Customers are encouraged to use more and get discounts. That way we all win.<br /><br />What is your thoughts on freemium plan? If you are a SaaS company, how are you paying for your free plan?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com28tag:blogger.com,1999:blog-24947835.post-11804616928775272392009-08-09T11:45:00.025-04:002009-08-28T18:31:41.810-04:00Reality check for Agile projects- working sofware over comprehensive documentationWe all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. We as agile practitioners have our own view of an ideal world. Last year I attended Scott Ambler's session on "<a href="http://www.infoq.com/presentations/Agile-in-Practice-Scott-Ambler">Agile in Practice</a>" at Agile 2008. In this talk, he challenged the common concepts and shared his findings. I found this talk very insightful and would encourage everyone to listen to this. In fact, it inspired me to write this series on Agile ideal views of the world.<br /><br />I will talk about some of the "<span style="font-weight: bold;">aspects</span>" of this ideal agile world in a series of blogs. Last time I talked about "<a href="http://blog.syedrayhan.com/2009/06/reality-check-for-agile-projects_25.html"><span>project management (PM) tool vs. no tool</span>.</a>" The topic today is <span style="font-weight: bold;">"documentation on Agile projects</span>." This is third in the series.<br /><br />The common perception about Agile projects in the market is that Agile teams follow cowboy coding and hence do not document. The myth about "<span style="font-weight: bold;">no documentation</span>" goes so far as that some see this as an incentive to adopt Agile and escape "<span style="font-weight: bold;">over documentation</span>" of the traditional waterfall projects. However, this couldn't be further from the truth. This misconception to some extent stems from misinterpretation of the Agile manifesto that says-<br /><span style="font-weight: bold; font-style: italic;"><blockquote></blockquote><blockquote></blockquote>"Working software over comprehensive documentation"</span><br /><br />The intent of this manifesto is to underscore the <span style="color: rgb(0, 102, 0); font-weight: bold;">importance</span> of "<span style="font-weight: bold;">working </span><span>software</span>" and <span style="color: rgb(255, 0, 0); font-weight: bold;">risk</span> of "<span style="font-weight: bold;">comprehensive</span> documentation." This does not encourage us to do away with documentation altogether. I hope we all agree that the primary goal of any software project is the "<span style="font-weight: bold;">working software,</span>" and the secondary goal is to support on-going maintenance and enhancement of this software. Scott Ambler refers to it as "<span style="font-weight: bold;">to enable the next effort.</span>" We all know that cost of development is only 20% of the total cost of ownership of a software. To contain this cost and associated risks, we need "<span style="font-weight: bold;">right documentation.</span>"<br /><br />A few of the issues with the traditional documents are,<br /><br />1. <span style="font-weight: bold;">Documents are static.</span> They are a snapshot in time. Hence, they quickly get out of sync with actual working software. Outdated documents increases project costs and risks.<br /><br />2. <span style="font-weight: bold;">Documents are created too early.</span> Traditionally documents like requirements, architecture, design documents are created early in the project. As the project progresses, the requirements, architecture, and deign morphs. Either documents become stale or the cost of maintaining documents increases.<br /><br />3. <span style="font-weight: bold;">Documents are bulky.</span> We tend to use Word doc, Excel, Power Point and the like to create our documents. They are disconnected island of information. To keep them in-sync with each other requires a lot of effort. As a result, we see a lot of repetition (wastage). It is also difficult to link information across all documents at the appropriate level using these old-school tools. For example, individual requirements to rules to test cases to decisions to etc. etc. It is difficult to browse the right related information <span style="font-weight: bold;">just-in-time</span> and <span style="font-weight: bold;">just-in-place</span>.<br /><br />DDJ (Dr. Dobb's Journal) partnering with Scott Ambler ran <a href="http://www.ambysoft.com/surveys/modelingDocumentation2008.html">a survey </a>on how much documentation Agile and non-agile teams are doing. The result reveals that Agile teams are more likely to model than a non-Agile team and equally likely to create documentation.<br /><br />Here are a few things I suggest to become Agile with documentation.<br /><br />1. Certainly, no documentation is not Agile.<br />2. Find a way to implement a continuous, collaborative documentation (Wikipedia model). For example, allow end users to evolve and enrich user manuals as needed, when needed. Allow developers or support engineers to update architecture document or operational manual.<br />3. Delay documentation until it is requested. I call it "<span style="font-weight: bold;">just-in-time documentation.</span>"<br />4. Keep the documents nearest the location of use (context sensitive). I call it "<span style="font-weight: bold;">just-in-place documentation.</span>" For example, technical API documentation within the source code. Use tools like NDoc/Java Doc/RDoc to extract APIs accessible from IDE. User manual should be embedded through out the software.<br />5. Use Wiki or Wiki style tool to cross link different elements of documents to form a Web of interrelated information. I call it "<span style="font-weight: bold;">accessibility of documentation.</span>"<br />6. Determine what to document based on frequency of use and number of consumers of the information. Importance of a document can be calculated by multiplying frequency and number of users. This could be used as a surrogate for a real ROI. The higher this number, the higher the ROI from the document. In other words, only document information that will be used by at least a group of people on a regular basis.<br />7. Use appropriate format for documenting information at hand. I call it "<span style="font-weight: bold;">comprehensibility of documentation.</span>" For example, use "As a <role>, I want ...., so that...." for documenting requirements. Use "given ..., when ..., then ..." (BDD style) to document acceptance tests. Use state machine diagram to document a stateful processing of data.<br /><br />Scott Ambler goes in depth about <a href="http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm">documentation on Agile projects</a>. I would encourage everyone to read the article.<br /><br />Yes, documentation is a sticky topic. It is difficult if not impossible to strike a balance between amount (over vs. under vs. no) and quality (useful vs. redundant, correct vs. stale) of documentation.<br /><br />What type of documents are you creating on your Agile projects? What tools are you using?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.com0