Startup Product Manager

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.

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.

Pre-Agile	Agile	Extension for Cust.Dev.
Comprehensive Documentation	Working Software	Validated Learning
Contract Negotiation	Customer Collaboration	Customer Discovery
Following a plan	Responding to change	Initiating change

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?