Thursday, September 03, 2015

A Cautionary Tale of Co-founder betrayal at Praiseworthy (Formerly Fosubo), a Silicon Valley Startup- 6 Lessons Learned

When we hear that "Co-founder Conflict" 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:
The Back Story:
I met my co-founder Misa Chien 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 "Nom Nom").  She was brought onboard of Praiseworthy (Formerly Fosubo) (our startup) as a CEO in July, 2013 by her then boyfriend Nico and Nico's friend Pato.
Praiseworthy was born out of a hackathon that Nico and Pato participated in Chile organized by AngelHack in May 2013, where Praiseworthy won. Praiseworthy was then invited to present at the AngelHack Global Demo Day in Silicon Valley on September 5, 2013. 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!).
My Praiseworthy Journey:
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 Praiseworthy (Formerly 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 500 Startups and AlChemist, and got rejected by them as well. We also had participated in Women 2.0 in February 2014.  All these were in the first 6 months of our business!
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.
In May 2014, we decided to apply to YC 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.
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.
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.
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 get-to-success-by-any-means type of entrepreneurs, and unfortunately some wrongly interpret that as get-to-success-by-dishonesty!
Lessons Learned:
Here are a few things I have learned the hard way from all of this:
1) Do a reference check on your potential co-founder(s): 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.
2) Hire your own lawyer: 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.
3) Agree only to the same vesting schedule for all: 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!
4) Agree only to equal equity structure: 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!
5) Keep a personal record of your communications: 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!
6) Get to know your investors and clients: 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.

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!

=================== Update: November, 06, 2016 ===============================
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.

Saturday, January 03, 2015

Three Common Struggles of Agile Teams

I have seen three common issues that many Agile teams struggle with. I will try and address them here for future references.

We need to increase our sprint length...

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. Sprint length as the cause of the problem here is a red herring. 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 Parkinson's law- 

                           "work expands so as to fill the time available for its completion"

The issue commonly lies in estimation. There are a few things that cause estimation issue in an Agile environment:

       a. Not being able to break stories. Right sizing stories is tricky and requires experience (trial & error).
       b. Not taking into account other regular commitments (production support, company activities, non-project meetings etc) by team members
       c. Bug fixes, ad-hoc requests

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.

However, not being able to finish what a team plans to deliver should not come as a surprise at the end of the sprint. This should become apparent thorough the effective use of "Daily Scrum." If it is not happening for your team, revisit how Daily Scrum is being conducted.

The most important aspect of a good Agile team is to be able to proactively manage expectation and eliminate surprises. 

I cannot  contribute to estimation as a non-developer (e.g., tester, analyst etc)....

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 -

                 "I'm not a developer so I don't know how long it will take for us to implement."

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-

How would you size this story compared to a known story for all the work YOU (not others) need to do in your role (e.g. tester, designer, analyst etc.)? 

For example,

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.

Another important distinction of relative estimation from absolute estimation is that we Do Not Add up Points 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-

   a. Pick the largest one (it is a safe play).

   b. Pick the majority one (common in practice).

   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.

Couple things to remember about relative estimation:

  a. It is important to be consistent with regards to how you pick the point estimates.

  b. Over time, the team will get efficient with estimation. So, do not worry if it takes longer in the beginning!

I don't understand why we need to break our requirements into smaller stories when we know we need the whole thing...

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:

      a. Allows you to roll-out the most important part of the feature set early and get feedback and adjust accordingly.

      b. Allows you to address business risk, or technology risk first with just enough time & money commitment.

     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).

     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.

Still not convinced? Would love to hear your particular situation and discuss in the comments section.