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