Startup Resources – Tricks Of The Trade Pt. 1

Posted: November 7, 2011 in Tools And Resources
1
I’ve compiled a list of some great articles and presentations around many of the key concepts that anyone building a consumer facing startup should know about to be successful. I’ll continue to build on this set of resources as I dig up more interesting stuff from my library and the web at large, but here’s the first set of resources to get you started.

The concepts outlined in no particular order are as follows:

Lean Product Management
Dan Olsen posted a great deck on SlideShare about how to do Product Management in a Lean Startup:  http://www.slideshare.net/dan_o/lean-product-management-for-web-20-products/

A/B Testing

Measuring Customer Conversion, Growth, and Engagement

Site Analytics Tools:

Site Traffic, Engagement, and Revenue - To track overall sales, page views, vanity metrics, and PPC/Affiliate Campaigns.

Growth, Cohort Analysis, and User Behavior

Continuous Deployment
Continuous Deployment is a process introduced by the Lean Startup where companies like WordPress currently do about 16 releases a day into production…believe it or not…through this process. It’s becoming a widely implemented norm at the many tech startups. Here’s an article about how Continuous Deployment is done at WordPress: http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/

The Success Planning Meeting

Posted: October 31, 2011 in How we did it.
Tags: , , , ,
1

As Eric Ries predicted in The Lean Startup, when implementing Lean methodologies on our technology and business teams, we had a bit of a struggle getting everyone to understand the process of coming up with a hypothesis that validates customer value for every new feature we introduce into our product.

To solve this problem, I created a new type of meeting for our team called the “Success Planning Meeting“. The Success Planning Meeting is held prior to development for every new feature to outline the hypothesis and discuss the engine of growth that applies to the feature or product. In each meeting we include both the business and technology teams and brainstorm what we hope to achieve with each new feature and determine how to best measure the hypothesis including what conversion funnels to create and track on a regular basis.

To introduce the topic, I created a high level presentation which I have shared on SlideShare. You can download it here: Success Planning Presentation.

At the beginning of the success planning meeting we always start off with a reminder of the ground rules:

  1. Topics of discussion that are out of scope for success planning go in the Parking Lot.
  2. This is not a forum to discuss legacy business problems.
  3. Topics that take longer than 10 minutes to discuss will be shelved for later review either at a follow-up meeting or at the end of the meeting (time permitting).
  4. No idea is crazy – We’ve found that it’s important to promote an environment of creativity and encourage people to bring up their crazy ideas.
During the first meeting, it was important to go through every slide in the deck to introduce everyone to the lean principles and methodologies. In all following meetings, we will always start off with the first 2 slides to reinforce the focus of what we’re trying to achieve and the ground rules for the discussion.
When moderated well, the Success Planning Meetings have been great and typically both the business and technology teams leave the meting with a cohesive vision of what we hope to achieve with a given feature and a contract with how we will measure the success of that feature.

We now have Success Planning Meetings for every new feature that we introduce into our retail website and have even had meetings to discuss the hypotheses for all functionality currently in place on our website and are implementing MixPanel to track user behavior and perform cohort analysis to validate all hypotheses.

These meetings have been terrific for our business and have lead to new insights into our customer behavior and identifying how we can add further value to our customers and drive conversions.
Have fun planning for success!

And so it begins…

Posted: October 11, 2011 in How we did it.
1

There has been A LOT of movement on our efforts to go lean since my last blog…

First of all, I wanted to set our development team on the path of understanding the core concepts behind the Lean Startup Movement and gave them an intro via the Inc magazine online article on the book and Eric Ries. Then, I encouraged each of them to buy the book and expense it to me :-) .

Next I put together a team focused on implementing lean practices across our development team and discussed where we are versus where we need to be. We found a couple of problems that we needed to address:

Source Control and CI (Continuous Integration)

We are a Microsoft dev shop and have been using Microsoft’s TFS (Team Foundation System) for our Source Control, Continuous Integration, Work Item tracking, and project planning efforts. However, we already knew that it was a stretch to leverage TFS for true Agile (but do-able) and we were already struggling with some limitations and workarounds to put a seamless Agile development process in place. When you factor in all that’s required for a true Continuous Deployment process…it becomes painfully obvious that it just won’t work that well and may actually be an inhibitor to progress. So we decided to make a change.

We converted to the hosted Jira Studio which includes Subversion for Source Control, JIRA for work item tracking, Green Hopper for our Agile Kanban planning and task boards, and Confluence for the Wiki. We decided to leverage Cruise Control.Net for CI and Deployment versus Bamboo (which is included in the Jira Studio) and each of us have CC Tray already running in our task tray notifying us every time someone breaks the build :-) . Automated deployments are already in place between each of the environments and now we’re cooking with gas.

Agile Task Board

One of the things that we like about Green Hopper, is that while it isn’t as mature as Rally, it’s pretty feature rich and allowed us to customize the workflow of Green Hopper to tweak the Task Board to add some new states and transitions to support the Lean Startup approaches we wanted to apply. We added a Validated column after Built to ensure that every new feature that’s developed must be validated before it transitions to Done. Additionally, we added a column to the task board called Hypothesis that requires that we document the hypothesis we are trying to validate for every feature that leaves the backlog. We also customized the JIRA Work Item template to add fields for storing the hypothesis for each work item.

Therefore, our Green Hopper Task Board columns look like this:

To Do –> Hypothesis –> In Progress –> Built –> Validated –> Done

For our next trick, we will be designing the architecture for a “feature flipper” for our .Net environment as well as the innovation accounting framework to track user behavior, funnels, etc.

Future posts will also describe the work going on from the business end to begin applying Lean Startup principles to customer development, marketing, and all that good stuff.

 

Day 0 – Where are the gaps?

Posted: October 3, 2011 in How we did it.
0

After reading The Lean Startup, I had a ton of ideas about how to apply what I had learned to build a more sustainable business and technology to support it. But I first had to realize where we were and how far we have to go to get to a place of Zen…where we truly know who are customer is and how to put a product of value in their hands with a continuous deployment process that would allow us to deploy code to production without cringing every time we hit the magic Deploy button.

Here are the technology problems that we need to solve:

  1. We have a technology platform that is not testable – “Testability” is paramount to a well oiled CI and Continuous Deployment process, and the current production website was built using 2 very proprietary technology platforms that are not very testable.
  2. We currently don’t have any feasible options for A/B and multivariate testing.
  3. Our framework does not support any true level of Innovation Accounting.
  4. Our only reporting consists of widely adopted Vanity metrics with very little insight into sales conversions and what triggers them.
  5. We currently do not have any automated deployments between our environments.
  6. The very thought of multiple production pushes a day given our current architecture would scare my development team to death :-)

From the business side, we have some interesting challenges as well:

  • Our business team came to the realization the “Technology is our product” shortly after I joined, but our business team is predominently focused on building the products that are sold through our technology versus tuning the technology itself.
  • We currently only use vanity metrics to gauge progress on our website. Our metrics don’t give us a true indication of what works and what doesn’t regarding promotions, etc.
  • We need to build a framework to enable the business to truly do some innovation accounting to better understand our customers and the value growth as we release new products and functionality.

Across the board, we have a lot of work to do to get us through the Build-Measure-Learn loop efficiently, but we have a lot of talented, bright team members focused on making a difference…so we’ll get there!

And so it begins…