Drinking from the Fire-hose - Lessons I learned from the Startup Lessons Learned Conference : Part 1

I spent a good chunk of Friday drinking at the Cambridge Innovation Center attending the Boston Simulcast of the Startup Lessons Learned Conference (#sllc) Oh, I mean drinking from the proverbial firehose.

IMG_0640

While every talk was pretty good, I am first going to summarize those from which I learnt the most (in the order in which they appeared in the conference). You may also want to check out the list of my tweets from the conference. This is Part of 1 of the Lessons that I learned from the conference. (Update : Part 2 never materialized because I was busy “getting out of the building” and building awesome scanner software that people are willing to pay fo)

  • **Kent Beck on **To Agility and Beyond: Kent made a case that the  ”Build” -> “Measure” -> “Learn” loop is actually backwards and that it ought to be “Learn” -> “Measure” -> “Build” or put more elaborately, it is to say :
  1. Make an assumption

  2. Identify how you will validate it, and

  3. Build something to validate it.But as  Ash Maurya comments on Kent’s blog post, I think the loop is just as fine, depending on your definition of “Build” (Build can be something as small as a dummy landing page or a mockup). The larger takeaway for me was how Kent expanded the Agile Manifesto to Customer Development. Specifically, these extension points were the most interesting to me.

[table id=1 /]

And finally, Kent highlighted that Good engineering is not the same as Good Startup Engineering. Good Startup engineering involves making the transitions from “hack” mode to “scale” mode to “optimize” mode, transitions which define the success of a startup.

  • Ash Maurya on **Continuous Deployment: I was originally amazed when I first read about Eric Reis mention 50 builds a day. **My most important takeaway from this was that it is not necessary to think of continuous deployment as a mega project. In fact, that is against the spirit of being lean. Start somewhere meaningful, and keep chipping at it.

  • IMVU Team on Scaling Customer Development : This was the most informative talk of the conference. It was great to get insights into a how a moderately big-size company does Customer development and if the concept Scales. Well, it does! But you have to watch for some traps.

  1. Too much emphasis on customer facing changes will likely increase technical debt: I can definitely related to this. This is precisely while we have instituted a “Kaizen Sprint” at OfficeDrop. The Kaizen Sprint is a short sprint at the end of every 3 sprints, with the goal of reducing the technical debt accumulated during the prior sprints.

  2. “Big bet” projects could become next to impossible and a missed opportunity : Yep. When your “radar” is defined by two sprints ahead and you are constantly thinking “Minimum Viable Product”, you absolutely run the risk of doing this. One way to mitigate the effect of such narrow/sharp focus is to institute “hack weeks”  (or the Atlassian-inspired variation - FedEx Days that we do at OfficeDrop). Developers can work on whatever they want for that time period and at the end of that, the Product Owner decides on incorporating it back in the product or adds it to the backlog.[Update : Thanks @bdurrett for links to the slides and video from the conference]

  • **Eric Reis’ chat with Randy Komisar : **This was the highlight of the conference for me. Randy’s “sage-advice” was that once a startup gets funded, the business plan goes to the trash and gets replaced by a Business Dashboard. No, there is no template for that Dashboard, because that would then be relegated to the same usefulness as the plan. Fundamentally, the dashboard culturally represents your company, is relevant to your industry _AND most importantly, _is helpful to you to provide  a sense for where the company is headed. Here are the key components of what should be in a Dashboard
  1. Your “leap-of-faith” questions: These are the fundamental questions that will determine if your product will succeed. For example, for the Sony Walkman, the question was whether people would stick in headsets in a subway, rather than talk to other people.

  2. What you measure to track those questions: These would include the typical vanity metrics, but also those that are specific to your product / business

  3. What are your alternatives if you don’t track against those metrics : This basically forces you to ask the question of “Do we pivot”?

I still have a ton of goodness to write about, including wicked cool stories about Aardvark, KISSMetrics, DropBox and an inspirational talk by Steve Blank. Some teaser questions for you until then (one easy, one not-so). Do you know who founded GM? Do you know who was the rockstar CEO of GM in the early 20th century?

Picking a company name - Part Deux

As a follow-up to Ivana Taylor’s interview with Healy Jones, here is another in-depth look at our re-branding effort and how we went about the process of “Pixily is now OfficeDrop”. As a longtime reader of onstartups.com, I think it is pretty cool that Healy got to blog about our re-branding effort in this popular blog.

An interesting and insightful read, I assure.

Changing your company's name the "Lean" way - A real life case study

I had recently mentioned that Pixily is now OfficeDrop. There were several valuable lessons that I learnt in how we went about the process. More importantly, not only was the process very successful (Strong positive feedback on the new name, from pretty much everyone that I have spoken with), but also done in a very cost effective way. Maybe a rose by a different name, might not smell as sweet.

We applied the essence of Customer Development to the rebranding effort. After a lot of brainstorming within the company (and how the entire company was involved, as noted by Matt), we actively engaged current customers and potential leads. After further culling of the names based on domain availability, weird meaning in Spanish etc,. we kept revising our shortlist, while engaging customers every step along the way (Think of it as “minimum viable name” ).

For a complete blow-by-blow account on why we felt the need to change the name, how we went about it, and to chime in your thoughts on the new name, check out Ivana Taylor’s interview today with Healy Jones, our head of Marketing. Plenty of insights, information on what tools we used, tips and tricks await you there.

Have you gone through a similar exercise? What did you learn from it?

Quick update from Department of Shameless promotion

As we are all getting ready for tonight’s Oscar awards, I figured this is a good time to sneak in My “acceptance” speech at the MITX Technology Awards. OfficeDrop (then Pixily), won the Technology Award for Innovation in the Cloud Computing category.

Pixily is now OfficeDrop

I am excited to announce that my company has changed its name to OfficeDrop . There were several key lessons that I learnt during the planning and implementation of the re-branding effort (which is still in progress). We engaged our current and future customers in the name-selection process and thus far the response to the new name has been quite positive.

Our friendly customer service (which I am very proud of), simple user interface and world-class operations are all the same. We will continue to be a very easy to use document management and document scanning service for small businesses. Now our name reflects that better.

I also got to edit the video where Prasad (my partner in crime and CEO of OfficeDrop) talks about the name-change, (inspired by my recent purchase of a brand spanking new Canon camcorder). Here it is, in all its HD glory, to know more about why we changed our name.

Exciting times, and hopefully I will get the time to blog about all those lessons learnt.