The it-agile Startup March: Lessons learned

This last month six colleagues and I carried out a little experiment: the ‘Startup March’. We decided that instead of doing development, training, and consulting for our customers, we would dedicate all of our time to work on an idea for a startup. We wanted to put the ‘Lean Startup’ method, as made popular by Eric Ries’ book, to the test. Here’s a list of learnings we came up with and my personal interpretation of them:

• Co-location: Communication gets orders of magnitude more difficult when a team is distributed. In the early days of a startup, there is plenty to talk and to argue about. Not being in the same room will inevitably slow you down. We also found it helpful to be somewhere else than our normal offices, away from all the distractions that would pull us back to the day-to-day duties for our customers.
• In the beginning focus on individual users: We tried to make informed decisions about our product, depending on statistics, from day one. This is hard when all of your data is statistically irrelevant. So, we decided to interview people and focus on our early adopters and their needs first.
• Know your metrics tool(s): Your metrics about your fancy experiments will be useless if you don’t know what they mean. What is a unique visitor? Is someone coming back during the same session? Someone on the same device? Are you counting yourself? If you don’t know this, don’t bother measuring it.
• Don’t neglect growth: It’s usually more fun to spend time on working on features that create more, but you also need to constantly think about how to get more people to use your tool. In order to do this, you should understand as precisely as possible who your customers are and which problem you are solving for them.
• A moderator can be helpful: We made all the decisions along the way in the team without having an authority like a Product Owner. In the end, we concluded, however, that a moderator like the Scrum Master role would have been helpful during some discussions. This doesn’t have to be the same person all the time, but it might be helpful to have this dedicated role to keep discussions from dragging on longer than they have to.
• Sync often: Most of the work was done in groups or pairs. To get everyone up to date, we did brief stand-up meetings throughout the day. Usually between two and four of them. With most of the system changing all the time it is important to keep everyone pulling in the same direction.
• Release more often and know when to clean up: In a startup environment, you are optimizing for customer feedback. This is very different to a project that has been going for a couple of years. Clean code is important in the later, not so much in the former. I am not telling you to intentionally write bad code, but to make a conscious decision about the time you invest in cleaning it up. The half-life of code in a startup is very short. There is no point in writing the cleanest code you can for an experiment you are going to throw away tomorrow. When some functionality has stuck around long enough and is actually valuable to your users, and you keep breaking it unintentionally, it’s probably time to write some tests and start refactoring it.
• Explain your features to your users: It may seem obvious to you why and how to use your tool, but it’s not obvious to your users. So, explain features and what value they will provide.
• Present to an independent audience about your idea early on: We presented our idea and our first findings on Lean Startup after three weeks to an independent audience at an evening event. This forced us to review our results thus far and we received valuable feedback by the participants.
• Don’t force a process on yourself: If you’ve got a team of experienced people, don’t force yourself to use a specific process. Scrum by the book is intended as a starting point for teams that are stuck. A team that has understood agile values will figure out its own process.
• Decide on the general topic and the techno stack and get to know them ahead of time: If you are planning on doing a similar experiment, where you spend a limited amount of time with some colleagues to work on a startup idea, do yourself a favor and get to know the problem domain and the technology ahead of time. This way you can jump right in on day one. Otherwise, chores, like setting up your dev machine and working through a tutorial, will eat up your precious time. BTW, we went with Rails, which was great to get off the ground quickly.
• Get a designer on the team: Most developers know how to make a piece of software work, very few of them also know how to make it look good. No-one will use your tool if it looks like it was developed in the ‘90s.
• Have a team event early on: It will help your team gel quicker. The work will be more effective and more fun.
• Team size: There was no agreement on this amongst the team, but I have an assumption that a smaller team would have been more effective. I base this assumption on another assumption that a smaller team would have needed less time for communication, both synchronizing and debating. Others argue that, if we took the four team members with the most opposite opinions it would have taken us just as long to debate and if we took the four team members with the most aligned ideas we would have had less innovation. I still think in the early days of a startup, as long as you got all the necessary skills on the team, a smaller team will outperform a bigger team, because of the frictional losses for synchronizing about all the moving parts.

All in all, for me the focus on experiments to prove one’s assumptions is the most important contribution of Lean Startup to my personal toolbox.

Further reading:

• A list of all resources regarding it-agile’s Startup March on Stefan’s blog
• Our startup idea: discuss2decide.com

Photo by Biegun Wschodni