Tag Archives: lean startup

Fail slower


Disclaimer: I feel a great philosophical affinity to the lean startup community, although I wouldn’t necessarily call myself a card-carrying member of the club.

I’ve explained in my previous post how despite an unfavorable expert opinion we decided to keep going with just❤liked. Your comments, which are as welcome as ever, have given me a little more time to think about whether there was some message in there for the greater lean startup community.

Let me just come out and say it: Yes, I am trying to coin a phrase. So as unfortunate as many misinterpretations of the meaning of “fail fast” may be, enter

fail slower…

The point of fail slower is that you should not fail too fast if it means that you miss out on an important swath of knowledge which has to do with learning what doesn’t work.  I am convinced that there is value in this kind of learning as well, and for first-timers like ourselves these insights are of critical importance. Something has to feed and inform the pivot (couldn’t resist) and it has to be learning-based.

I should clarify what I mean by learning here. Have you ever tried to learn how to program by reading a “Learn X Programming in 72 Hours”? If so, you should know that this stuff (1) is no fun and dry as hell, (2) doesn’t stay with you, and (3) has not given the world its best programmers. What I am trying to say is that someone telling you something is a different kind of learning from first hand experience, search, discovery, wrong turns, running into walls and tearing your hair out by the roots. And if it means you have to fail slower to tap this knowledge, I am fine with that.

PS: I know the situation would be a bit more complicated if you have investors footing the bill. I am not suggesting you learn this way at someone else’s expense.  Also I imagine that if you have investors to begin with, you’ve already had a chance to do this learning at some point in the past and you’ve done it well enough.


Startup – the anxious business of business building


There are many possible motivators for starting your own business. Whatever they may be it’s still a viable business that you are after. It’s not a hobby or a diversion or a side project, it’s building a business that is the ultimate goal behind starting a startup. The other goal, one that is no less important, is to learn as much as you can about business building itself.

It should come as no surprise that when you set up on your startup journey, you set off with a set of proposed assumptions and inherent biases that you then work to prove.  I claim that proving existing assumptions wrong and finding new patterns that have no prior assumptions attached to them have different emotional implications for the founders. Even though “customer development” and “validate everything early and often” are all the rage, we still tend to hold our assumptions and biases as something deeply personal.

Well, last week brought a sobering of sorts. The assumptions that my co-founder and I have considered provable have come under harsh scrutiny of an outside expert, someone I trust and someone who has a solid track record of success and beyond-doubt credibility in this space. You may call it a watershed event, a cold shower – as my cofounder called it, but it was certainly, in its immediate aftermath, a source of great anxiety, concern and new doubts.

We heard the feedback, but we decided to keep going because we still believe we are working on something worthwhile. Expert opinions are expert opinions, but they lead to no revelations. Learning leads to insights, and if it takes another couple months for our users to second the expert opinion it would carry that much more weight in our minds. I think the users should be the ultimate judges of our undertaking. Also, it is my sincere hope that engaging with users will lead to more insights than a simple thumbs up or thumbs down from an expert.

Are we as surefooted as we were a couple of weeks ago? No, of course not. We always had very little surefootedness to speak of. Are we ready to throw in the towel and turn the project that we thought was a business into a hobby? No, that’s not what we intend to do either. We still feel that justliked was worth starting both for the sake of the learning experience it affords and as a business we believe in.

4 Things That Drive Early Adopters Away


We’ve had the alpha sign up page up for couple of days now. So what are we seeing? Not much, to be honest.

The people who leave their emails are the people whom I know personally, and who have ignored the ominous warning that says:

It’s preferable that you are not related to or are friends with either of the founders so as to allow yourself to lash out against our vision without fear of breaking the bonds of friendship or family.

So why would the rest be turned away?

  1. Lack of trust or credibility. Leaving your email is a gesture of trust since it involves passing your personal information to another party. At the end of the day you don’t know what’s going to happen to it. And if you don’t know us, your first inclination is to keep your distance. That’s perfectly natural. Moreover, in our case neither co-founder has a well known public persona that could boost credibility or count toward reputation.
  2. It’s not clear what you get. So you sign up, then what? Are you going to be among the privileged few who get to play with the app or are you being recruited for alpha testing? Well, a little of both actually. But why would you volunteer your time? You wouldn’t unless you know us or have something to gain. I keep hearing about early adopters all the time, but where do they actually come from? Are early adopters just a euphemism for fools, friends and family or is it something more?
  3. It’s not obvious when you get it. Our sign up page is purposefully vague on when the app is going to be ready for alpha. It’s vague because we do not yet have a good handle on our own bandwidth and velocity in the coming weeks. As we are making progress we are getting better with time estimates, but the margin of error is still pretty high. What we do know is that we are probably done with 70% to 80% of what we set out to do for alpha.
  4. Scarcity or urgency is not fully conveyed. There is no indication that this is somehow limited availability. Should we have said that we are accepting 20 alpha users only with the counter indicating the number of spaces left? I don’t know, but I feel like trying that soon.

Thanks, but no thanks!

The recurring theme with the four points above is clarity. In the coming days we will attempt to increase clarity along those four dimensions and see if that brings in some new folks, preferably the ones we don’t know personally.

Have you tried recruiting early adopters and motivating them to sign up? Please share your collective wisdom in the comments below.

Some thoughts on API use and design


All software is building blocks. Exceptionally good software is constructed from orthogonal pieces that fit together like they belong nowhere else, are interchangeable and make the overall structure only marginally more complicated than the components from which it is built. The “seams” or the interfaces between the blocks are the APIs, and it is here, I claim, that most engineering magic happens.

In my experience API design is extremely labor intensive, generally under-appreciated, hard to learn and harder still to teach. The design is almost never right the first time around (or the second time around, for that matter), yet the difference between good APIs and bad ones can be appreciated by looking at software structures that given API makes possible. To give you another analogy from architecture, bad APIs give us shacks cobbled together and teetering on the verge of collapse and good APIs give us Notre Dame cathedrals.

Increasingly software design is all about combining of-the-shelf components into a coherent whole. I’ve noticed it in my day job and while working on JustLiked. The amount of software packages freely available on the internet is staggering and each comes with its own API. In the end we do less in-house API design and more gluing. And every time we need to glue something together, we are faced with the question of what and how to glue.

I think the temptation to reinvent the wheel is huge, so the answer to the question of what and how to glue is often “let’s roll our own”. I don’t mean we are just tempted to write more software–we are tempted to write software which is designed for more reuse than it will ever see. The latter tendency preempts the process of selecting from available  components with designing our own with its own API. I’ve fallen into this trap myself recently, and all I have to say is:

Don’t reinvent the wheel, instead trust the API you are given.

In my view it’s much better to err on the side of more glue than designing a new self-contained, interchangeable building block to fill the void. The more “exposed” and “universal” you want to make these new building blocks and their APIs the less likely you are to succeed on time and on budget. It’s my subjective opinion, but it’s served me well over the years.

Once you find the component you need, use it in the way that it was intended to be used. Every technology has its sweet spot where it shines, so let it shine. Even if you can’t find something that fits perfectly, don’t kludge together a brand new component with its marginally better API because there are hidden dimensions, the secret sauce of API design that you haven’t mastered yet and it will come back and mercilessly haunt you way past your project deadline.

And even when you know what you are doing, make sure that what you are about to do actually gets you any closer to a business objective. Chances are it doesn’t, unless of course you are building an SDK.

Help us name our startup and app!


We are building an online social application that lets you stay on top of and enjoy things that your friends find interesting, good, likable, cool, irresistible and noteworthy, or things they just liked for no reason.

“Things” in this context include places they visit, foods they try, music they listen to, books they read, etc. There is really no limit what one may enjoy in life, is there?

Needless to say we are looking for something that has that special ring to it, that is easy to remember and not too lame.

For now we have shortlisted the following three names. Please help us decide!

If you have other ideas or suggestions, you can let us know in the comments.

*Domain names would be irresistib.ly, likewisely.com or likewise.ly, and justliked.com.

Keeping it frugal (or running a startup on less than 25c a day)


Ok, this is how frugal we are. Consider it a part of the overall leanness assessment.

Currently our total monthly bill is $6.30.  This goes to assembla.com for hosting of our project code base, tickets, release plans and time tracking (Disclaimer: I am not affiliated with them in any way, but no complaints so far).

Other things we use:

  • Fee App Hosting – Google App Engine
  • Free Document storage and sharing – Google Docs
  • Free voice calls and video conferences – Skype
  • Free blogging – WordPress

The next “big” expenses will be the domain name(s) and a real Google Apps account.

Getting to alpha will cost a total of $200-300 excluding the cost of labor. :)