What? No Updates?

So it’s _almost_ been a week since there have been updates posted on the blog, but it’s not due to lack of progress.  It’s more due to the progress is unseen to you.  I know there are a lot of usability issues that need to be resolved, but I’ve been plugging away at a simple REST API.

The API is for other developers, but we will be our first customers by using it to create an iPhone Application.

n’joy

Tobin (:

Monday, October 12, 2009   ()

Feedback Overload!

Feedback is a double edged sword.  It’s good in the way that it can validate your ideas, spawn new ones, and in general revitalize your energy in regards to what you are working on.  However there are times feedback can catch you and completely overwhelm you.

Last night the NY Lean Startup Meetup Group held a Feedback Round-Robin session where we practiced getting feedback on our respective products.  Lee Hoffman of Veritocracy (Veri.com) organized this specific event and provided some great insight on how to conduct use test/feedback sessions. For me I wasn’t so much concerned with the feedback I was getting, but I was more focused on how I was conducting my feedback session and learn how to steer less.

Through the week I had been getting feedback from a bunch of great people and also viewing the results of multiple split tests I had done for various sections of the site. Although I was focusing more on how to conduct a feedback session, the results felt a bit overwhelming.

One moment I was elated with the feeling of validation, but quickly the feeling of suffocation started to settle in about what I envisioned lay ahead of me.  All the feedback I received quickly added up to multiple pages of “things to do” where a majority of them were labeled as “URGENT”.

I realized I needed to defuse, so I simply went home and “turned off”.  No coding, no blipping, maybe some reading or tweeting, but largely no “productive work”.  I did spend some time thinking about the feeling of suffocation and what I could do to change that because my list wasn’t going to go away, but I didn’t do anything about it since I realized I wasn’t in the state of mind to do anything productive.

When I woke up this morning I realized I could look at my “To Do” list as something other then a PM styled task list.  I looked at it as small fragments of proposed solutions to problems I am trying to solve.  So instead I decided to make a smaller list that identified and grouped the user problem I am trying to solve.

I then ignored the original task list and wrote down next to each problem how I propose to solve that problem.  This felt a lot more manageable and helped me align my product vision to the problems I am trying to solve.

Thursday, October 8, 2009   ()

Observations of continuous deployments

Since I set out to develop Buddy Blip I’ve been using continuous deployments to publish code changes for the public facing website.  I really like this methodology, but the concept can be quite frightening at first.

For a typical deployment the team would set up a timeline/milestone to get bug fixes and new features deployed to live.  This is a nice practice as it allows you to smoke test significant changes, however one thing I’ve noticed is that a portion of your team has now “forked” off to handle the deployment and they are no longer working on features.  Depending on the scope size of the milestone, a good portion of time would be taken up by one or more people to prepare and execute the deployment.   I’ve seen cases where this is limited to 30 minutes of work for 2-3 people, but I’ve also seen that this take an entire dev team a full day to synchronize code to a release branch (and tag) and deploy it.

When using continuous deployments for deploying web applications the process typically takes 5-10 minutes for a single developer.  For me the process is checking in my code to the trunk, making a branch from the latest release, merging my changes to the branch, tagging the branch as a release and then deploying the code to live.

I still like to maintain the “trunk” as a progressive development version so I set up a branch and only merge in the changes I want to deploy to live.  This is so I can maintain and back up versions of code that aren’t ready for live yet.  For significant development changes that would take multiple weeks I will typically branch off of the trunk, but for small features that only need a few days of work and testing I will continue to work off the trunk.

In all I like the continuous deployments, however I’m curious to see how well the methodology holds up as the team grows and scope increases.  However I feel if the scope increases then I’m no longer practicing Customer Development/Lean Startup methodologies.

My observed benefits of Continuous Deployments

  • Morale is increased due to momentum of getting things done
  • Quicker route to testing new ideas with real users
  • Focus on obtainable feature sets and things that matter
Tuesday, October 6, 2009   ()

How would you spend $20K - Revisited

buddyblip:

“If you had $20k to use towards your own technology business/startup, how would you manage it and spend it?” – That was a question I asked other nextNY members in May of 2008. At the time I had created a small fund for myself to allow me to bootstrap my startup and I wanted to find out from my peers about what they would do.

Some had humorous responses such as a huge launch party or aeron chairs, but what I really wanted to know was what should I put my money towards to most benefit my chances at success.  Some of the more serious answers included development of prototypes, customer & market research, and marketing.

Looking back I feel my questions was a bit naïve.  However over a year later I have a much clearer thought on what I’d do with that money.  I’d spend as little as possible. Specifically I’d minimize my costs to find the cheapest way to validate my product idea.

I would start spending the money only when I feel I have a product that I feel confident would garner interest from my customers. Once I knew more about my product, customers, and distribution channels I am certain I would be confident in where spending would be effectively applied (be it development, marketing, research, distribution, etc).

Monday, October 5, 2009   ()

The most meaningful advice I've heard given to an entrepreneur...

This past week I put together the Feedback Forum where we discussed Klickable.TV with Roger Wu. First, what is the Feedback Forum?

The Feedback Forum is a monthly gathering of NYC entrepreneurs and technology-based startups or businesses in the NY metro area.
Each month we focus on a specific company and discuss critical operational challenges in an open environment that creates a learning opportunity which can benefit the broader NYC entrepreneur community.

There was a great discussion all around but there was one comment that was made that stuck out in my mind the most.  David Rostan of SocialYell.com gave a really solid piece of advice in regards who to talk to or try to talk to when finding champions for your product in an organization.

Find the people that want to see you succeed.

To me that means find those who if you succeed, they succeed as well.  So if you’re challenging an existing thought find the person who will benefit the most by adopting your solution.

Saturday, October 3, 2009   ()

October 3rd, 2009 Buddy Blip Update - We got images! (:

buddyblip:

While on my flight from ATL to California I was able to do a bunch of coding.  The biggest thing I did was allow users to post images to comment streams and private conversations.  It mostly started with my friend Kenji posting a link about getting some Korean food in NYC’s K-Town.  I thought it’d be cool to show what I’m expecting!

Take a look:

Yum! (=

Okay, aside from that I spent time working on some API REST services and administration tools.

n’joy!

Tobin (:

Saturday, October 3, 2009   ()

October 1, 2009 Buddy Blip Update & Thoughts on Usability

For the past two weeks I’ve been collecting data through casual user tests, A/B testing, Feedback Army, and general analytics.  The most significant thing I realized from the feedback is that I’m not doing much communicating on the site.  I’m not explaining to the user how I envision they use Buddy Blip.  I’m only telling them what it can do and leaving them to figure out how on their own.

I came to the realization that I’ve been focusing on usable features instead of communicative features.  Communicative features are functionality that helps the user understand what a product does by communication and functioning at the same time.  This goes above just a simple blurb that tells what the user should do.  A communicative feature should also assist the user in performing an action on your site while guiding them how to do it. A perfect example of this is Tumblr.com.

I LOVE Tumblr.

The first time you create an account and log in to Tumblr, you are presented with an introduction to how to use their service.  These aren’t just splash screens though.  They guide you to creating a post and customizing your Tumblr account while collecting data.  After three steps you’re all set and already experienced on how to use Tumblr.

Here are a few examples from Tumblr:

Tumblr instructs users how to customize their account

Now they show you how to find cool people

These are great practices and have prompted me to spend the past week building a similar set of functionality.  This past week I’ve been focusing on creating a system that allows me to create communicative features on the site. If you want to take a look at how it works, just sign up for an account! Don’t worry, if you already have an account it will still guide you through the process.

Noticeable updates:

  • Fixed image upload bug that “lost” user images after uploading
  • Added “welcome” guide to help users get started
  • Added an announcement system to the dashboard that allows me to send updates to users when they log in.

More to come soon.

n’joy!

Tobin (:

Thursday, October 1, 2009   ()
()

Regarding Search Engine Marketing (SEM) on $5/Day

buddyblip:

The other day I was discussing the thought of SEM on $5/day with a few peers.  The general consensus was that $5/day is not really effective for generating leads on Google Ad Words, but after giving it some thought I was able to turn around the notion that the “SEM on $5/day” was outdated.

If you’re building a customer product/service that’s re-segmenting an existing market then chances are high that you are going to be running into a lot of competition.  You will often see valuable keywords for your ads with high Cost Per Click (CPC) bids.  When trying out Ad Words for Cupid’s Lab, I was seeing CPC bids starting at $5-$6 for keywords associated to dating. In other cases there were keywords that were a bit less costly, however they were still $1 CPC.  You’re not going to get very far on $5/day.  Or are you?

If your intention is to scale and bring in as many customers through the door, then $5/day is not going to work for you.  However, if you’re starting out and you really have no idea how users are going to react to your product then you should spend no more then $5/day.  If you are the latter, then you really aren’t in a position to scale in the first place.  So fight the temptation of increasing your ad spend to introduce more people to your product.

Do you know what the current conversion rate for your product is?  How many visitors do you have to your service before they become customers?  Do you have a solid number or do you have an assumed number? Assuming that 1% will automatically convert is not realistic unless you actually see 1% convert and understand why.

If you don’t know these numbers, then you the $5/day allowance is where you should start.  This allows you to begin the validation process of your assumptions by collecting qualitative data. From there you’ll be testing two things.

First you’ll be collecting valuable metrics about what users are responding to through your ads and whether or not you are targeting the proper keywords.  You’re going to spend a lot of time refining and increasing your Click Through Rate.  Don’t worry about the # of impressions your ads get, focus on the percentage of users that actually show interest in what you are selling by clicking your ad.  Your actionable data should be which ads and keywords yield the best click through rate.

Next you should be prepared to collect actionable data from the users that click your ads because the sale does not end there.  If you have a multi page flow for the user to follow, you need to determine the abandonment rate and why the user is dropping off through split testing your pages.

When it comes to this sort of testing you do not need significant data to find emergent behavior.  Having 100 visitors test your assumptions most likely will yield the same results as if you had 1000 vistors.  This where SEM $5/day works well, it helps you collect qualitative data without breaking the bank.

Once you have a clear understanding of how your customers are behaving you can begin to increase your ad spend and see if your assumptions are scalable.  Until then, stick with the $5/day until you can validate and tweak your conversion rate.

Monday, September 28, 2009   ()

September 27th, 2009 Update

buddyblip:

The day job has been keeping me a bit busy, but I was able to manage to squeeze in some BuddyBlip.com time.

Here are some of the noticeable updates:

  • New Temporary “Logo” & Header
  • New landing page
  • Task notification system on the dashboard

Other things I’ve done is modified the server side caching on uploaded images.  I’m dynamically processing the images based on how they are used.  There was a small bug where the resulting image was not being cached properly

Another change was the use of Google Web Optimizer for doing A/B Tests on the landing page.  I don’t think either of the landing pages are going to yield any significant conversions, but this is largely a test in exploring the process of collecting actionable data.

I have some cool things in the works for this week in regards to how Buddy Blip is used.  I can’t wait to share them.

Tobin (:

Sunday, September 27, 2009   ()