4 startup lessons. Discipline and despair!
As I am on the train heading to FailCon 2012 in Paris, I am taking the opportunity of this three hours journey to reflect on the last few weeks and the imminent launch of Dokker.com.
Not surprisingly, we have been working harder than ever before to get to this point: Dokker is almost ready for its first general release, probably Wednesday 26th or Thursday 27th September.
What have we learned during this time? A lot as one would expect. But Jon (who works with me on the product build) and I should probably highlight the following:
1 – We efficiently managed requirements:
Managing requirements is key for any project. However, when you are the one expressing the requirements and building the product, it can become your doom!
We chose to maintain a very simple spreadsheet (I’ll post the the template on on Dokker very soon) and to be tough and bold in regards to the calls we were making every time we were checking our progress against it.
Basically, everything that was considered as the bare essentials to have a credible product from the start was tagged as priority 1. The rest was dutifully tagged as 2 (next coming releases) and 3 (nice to have). Despite the temptation of delaying the project to deliver “more”, we managed to stick to this priority list.
However, it needs to be noted that during testing we tried to listen as much as possible to our testers and integrated some functionality that was clearly missing otherwise!
“More” is evil. Get rid of it!
2 – We have not undone or rewritten Dokker’s code since we started building it.
Right from the start of the project we decided to think before acting. We went through a very valuable few days of brainstorming and wireframing to define exactly how the solution would look like and work.
God bless wireframing! Really! It’s a cheap way of ensuring that you can visualize the final product without writing a line of code; it’s also been reassuring to revisit it from time to time and see that we did not depart from our vision.
We stuck to our guns and delivered!
3 – We messed up the list of testers and the naming convention of project test phase, barely survived it:
As soon as the product was coming off the ground, we decided that we would have to organize an “alpha” test phase with a handful of users. It took us time to come up with a list. Most of this list was made of people in our close network or simply friends. How wrong of us!
A significant number of our friends, relatives and close professional network connections did not look at the product. We had to stalk them and, in the end, turn to less emotionally involved people to ensure we would get enough feedback.
Why? I have been thinking about it carefully. My theory is that they don’t want to judge your work and be negative about it. It’s better to ignore the pleading requests rather than having to bring up (even constructive) criticism. I also believe that some of them were simply not interested.
Mixing up friendship and business is a bad idea!
Fortunately, in the end, we managed to get a bunch of awesome people (some clearly outside from our first circle of connections) who dedicated time to the solution and provided amazing feedback.
To add to the difficulty of motivating people to test, we called this phase an “alpha release”. This was a major mistake that we could have better anticipated when presenting the early version prototype. A couple of people told us that it looked more like an almost finished product than a prototype.
We should have called it “private” beta. Testers would have been more confident about the level of quality and readiness that they would have had in the solution. Communication is already key during testing phase!
4 – We underestimated the challenge of launching a product in different languages
Don’t get me wrong here. From day one, we defined our software architecture to support multiple languages. But, my god, how hard it is to get the translation work done. It is VERY time consuming.
First, you have to come up with meaningful text in both languages (for instance English and French). Then you need to ensure that the meaning is consistent across both languages. Finally, you need to put up with the opinion of everyone about your translation. …A very humbling experience for your self-esteem.
Language localization is challenging. Make sure you really want to put your startup through it first!
I hope this firsthand experience will help you go over some of these hurdles. Would you like to share some of your lessons learned? If yes, please do comment my post! Thank you.
You can follow me on twitter @FredDucrot. You can also have a look at the Dokker Team Blog here.
blog comments powered by Disqus-
fredducrot posted this
