One of the biggest surprises of the startup experience so far has been the pleasure of owning. I am not talking about owning a multi-million dollar company or any company for that matter. I am talking simply about making something when there was nothing there before and putting your name on it. It’s not a matter of perceived or objective or any other type of value that can be put on the the thing you are making, it’s just a private joy of building, identifying with and taking pride in what you’ve build.
I am not a stellar programmer, and I have not written that much code in my lifetime. But even when I did write something it was never my own. And now, for the first time, what I write is mine, and that is somehow a very different experience.
One of the premises we are betting on is that social behaviors are the most ingrained and persistent. What we’ve done is actually try to identify (of course this is skewed by our own naive perception of how people operate) the social group dynamics and sustainable behaviors that we can transfer online. In other words, if people are doing this in real life, they should be willing to do it online as well.
This works only as long as there is some incentive, some value proposition over the traditional way of realizing this social behavior. It has to be somehow enhanced, which is hard since we are fighting an uphill battle with existing habits and norms. But if we get this right the rewards are also great, since you are tapping into fundamental drives and needs. This is like Maslow’s pyramid type of stuff.
The enhancement part is tricky too. We’ve zeroed in on a number of limitations that apply to this set of behaviors in the physical realm, and we’ve been basing our strategy on overcoming these obstacles and making it easier, faster, more rewarding for the user to do this online. There are many assumptions, some of them technical, to validate. But of course the biggest hurdle is to verify the core premise that this social behavior is transferable. That’s the main challenge.
Another issue that has bubbled back up to the surface (thanks to a comment here http://bit.ly/bPsbJM by @cindyalvarez) is privacy. We considered it at the very beginning and this is yet another unknown, which is up in the air for the time being. The comment makes me think that we cannot afford to neglect the issue.
Needless to say, it’s getting increasingly complicated to not talk about what the application actually is. The wire balancing act is getting trickier by the post. Moreover the blog is moving much faster than the product, so I will try to mix in other topics that divert your attention from the elephant in the room, which is really what the whole hoopla is about anyways.
I claim that no product ever failed because it was ahead of its time. It doesn’t mean that products can’t fail for other reasons. Of course not. I guess what I am trying to say is that “ahead of its time” is just papering over something else, and this something else comes in two forms:
- The product is behind (as opposed to ahead of) its users expectations. In other words, it’s just a bad product. It doesn’t solve any problem, and if it does solve a problem it does so in a way that is somehow deficient from the point of view of the user. The technology may not be there yet, it’s slow, ugly, whatever. Bottom line is: it just doesn’t live up to the user’s expectations. This is the product/market fit that everyone talks about so much.
- The product is ahead of its ecosystem. Obviously some products just don’t make sense without certain complements, infrastructure, business models, etc. Sometimes the stuff that you have to stand on hasn’t been invented yet. The users would love to use the product, but the product cannot survive on its own, it needs a certain business or technology ecosystem. Agreed, the notion of ecosystem can be very vague, but it’s basically stuff you have no control over. Some of this can be filled in with enough money thrown at it, but mostly the ecosystem problems are too large for one company to tackle.
What does it have to do with what we are trying to build?
Well, 1 is up in the air until we let our first users play with the application. Right now we are running on a set of assumptions about user wants that we need to validate. So once we have the alpha we’ll have the first indication of whether the product is decent, i.e. whether somebody is willing to use it and on what terms. Frankly I can’t wait.
2 is easier. The coast is clear in terms of ecosystem. The things that we think we’ll need are already there. Of course, once we start tracking 1 better, we may realize that there is something in 2 that doesn’t exist and is needed to satisfy 1. We’ll see.
Isn’t 80% of code quality just the choice of font and formatting? :)
As a case in point, the code viewed in our git repository’s web interface somehow seems to much cleaner and more well organized than the same code in Eclipse. Psychologically that’s a good thing, and I’ve trained myself to look at the code online when the urge to refactor comes. If that doesn’t work, I look at the product backlog and listen to all the other stories calling my name. If by this point I am still not convinced, I run the unit tests and see the dots that roll across the console window, appreciating how much I prefer them to F’s (failure) and E’s (exception).
So when you are about to refactor something take a step back and… I don’t know, just say no.
On a more serious note, I think it’s a perfectly natural to want to tidy up the code, make things more ordered, more maintainable, etc., but if there is no immediate business issue behind it (especially if you are at the early stages), I feel refactoring anything is actually hindering your progress since it’s not bringing you any closer to your immediate goals. The odds are you are going to throw that code away anyways or discover that none of the customers want to use it.
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. :)
I think it’s a pretty intuitive and natural idea to start small. My first real boss used to say: first build a Chevy, then build a Cadillac.
We are still firmly in pre-alpha era, building our Chevy, but during the first couple of rounds of discussion there were may be 50-100 tempting features that just sneaked onto the product backlog. Writing them down then was perfectly fine, as long as we didn’t also try to cram them all into alpha (or even beta).
I think the key has been finding the minimum subset of functionality that could be demoed to other people not familiar with the idea. This subset is probably half of what you think it should be, and it takes a certain objectivity and discipline to throw out all the bells and whistles. We settled on getting the basic flow of the application and a few main screens in place. The main requirement was to capture the idea , and not even try to build a prototype (that’s beta). This would be all there is in scope for alpha, and that would be locked until after we show it to a few people. So far we managed to stick to the plan pretty well.
The rule is “once we get the first round of feedback, we can unlock the scope”. And then it’s iterate, iterate, iterate.
I am a skeptic by nature. I seek and find flaws in people logic and arguments. I know this about myself and I fight to keep the criticism on the constructive side. I don’t think there are ever antisocial or egocentric undertones to it, but I can be arrogant and self-righteous when defending my point of view. Nobody is perfect.
When my future co-founder came calling with the original concept and idea, I immediately went to work trying to shred it apart. Not overtly, of course, but more by running through different scenarios in my head. Surprisingly, and this doesn’t happen too often, I was convinced fairly quickly. This was before we started doing research on the competitors, but that’s another story.
In any case, it won me over. There was just this personal belief that a) people needed this, and b) that it could be done easily and cheaply. That’s not a pre-requisite for startup success, mind you, but it was already something I was willing to invest my time in, and more importantly something I would be eager to use once it’s built.
If things didn’t work out, at least we’d still have the system all to ourselves. I think that’s one of the advantages of building something for consumers vs. building something for the enterprise. You can always be your own focus group and your own customer. Yes, the risks for bias are also high, but at least you know if something doesn’t feel right at the gut level it probably isn’t.
It felt right.
I decided to start a blog about my experience trying to conceive of, build, launch and succeed with a consumer internet service. I imagine there are myriads of blogs of this nature on the internet, and I assure you this one won’t be much different.
It will be personal and opinionated. It will be about startups and technology. And I will try to tell a story about our ups and downs that is at least interesting. If it becomes a sort of warning to others, so be it. But I would be especially pleased if it lets you avoid our mistakes. For me, it’s just a way of documenting the daily goings on.
Finally, I am not on a mission to forewarn or share fundamental insights that I’ve accumulated over decades of entrepreneurship. I don’t have them. This blog is about the events that happen as they happen.
Don’t expect well-researched articles about the industry. These consume a lot of time. I’ll gladly leave this work to the experts, and I will refer to them when necessary.
My opinions are my own. When I say “our”, I mean the team that is working together to build this service. At the moment, we are two co-founders including myself. As this blog evolves I will gradually reveal more about who we are and what we are trying to achieve.