Lean Marketing Workshop

A few weeks ago at a local Silicon Valley Rails Entrepreneur’s meetup group we had a workshop about Steven Blank’s Customer Development process. We actually devoted two meetups to this topic: the first night, we had a presentation explaining the process. Afterwards, the Q & A discussion was like reviewing case studies.

We devoted the entire second night to reviewing people’s startup/project/etc. This workshop format was fantastic; it’s a great way to learn.

To focus the discussion, our moderator Tristan Kromer, provided a list of key questions/topics for the presenter to explain his startup and problem. This was very useful for the discussion.

I thought I would document that list here — along with some explanatory notes.

Lean Marketing Workshop

The questions are partly based on leandeck.com

Marketing Issue

What is the current issue you’d like to discuss?

  • Another way to think about this is: what do you want to achieve?
  • What is your chief complaint?

Problem Hypothesis

What problem are you trying to solve?

  • This should be one problem. If you are trying to solve multiple problems, that is an of itself a problem.
  • Ideally this should be one sentence and easily understandable by everyone in the room.
  • Your hypothesis should also give a general answer, “for whom?” As in, “we’re solving the problem of information overload.” “For whom?” “For twitter users.”
  • The problem hypothesis is a major component the market part of Product / Market fit. You may find that your customers find other uses for your product that you did not forsee.

Customer and Market Hypothesis

Who are your customers?

  • This is ideally a complete picture of the typical customer, their habits, places they hang out, what they do now to solve the problem, etc.
  • This should also include an understanding of whether it is a new, existing, or re-segmented market.


Solution Hypothesis

How does your solution solve the problem?

  • This is relatively self-explanatory, but it should discuss benefits, not features. Features are not useful for marketing (in general).
  • e.g. “Eliminates trigeminal autonomic cephalagias by reducing stimulation of the perivascular nociceptive nerves” is a feature. “Stops headaches fast” is a benefit.
  • Benefits must be “for” the customer and must related to the problem and the customer. “Stops headaches fast” is not a benefit unless you have a headache.
  • The benefits to your solution will become the content of your marketing message.

Customer Acquisition Hypothesis

How are you acquiring customers?

  • What is the current marketing effort?
  • What channels are being used?
  • What is the cost of customer acquisition including manpower?
  • In general, this refers to how you convey your marketing message (solution hypothesis) to your customers.
  • In this context, we’re looking for a single case that people are testing that they want help on, but we can discuss broad categories as well.
  • Generally, if the marketing isn’t working, the customer hypothesis is probably not well defined.

Business Model Hypothesis

How are you going to make money?

  • Ideally, a business model canvas as advocated by Ostwerwilder is ideal.
  • In the simplest case a basic one sentence description is fine,. E.g. “I will sell advertising.”
  • (note: A complete business model canvas would include all your other hypotheses as well.)
  • In relation to marketing, this is only needed briefly to understand how the constraints of the customer acquisition costs. Different models will have different cost constraints.


How are you measuring your progress towards solving your current marketing issue?

  • What is the metric?
  • What is your conversion funnel?
  • What is the condition under which you have validated your hypothesis? (note: This is a trick question.)
  • What is the condition under which you know you are failing?
  • Which hypothesis will be disproven if you fail?
  • Bring real data to discuss.


Bootstrapping, the Lean Startup, and the Customer Development process

Recently I’ve had discussions with a variety of people about Startups. These discussions varied naturally with our relationship: potential client, potential partner, friend, etc.

Nonetheless, part of the discussion was very much the same. I find myself always referring books and blogs related to several key topics:

* Eric Ries’ The Lean Startup
* Steven Blank’s Customer Development process
* Founders

So, this is post is really because I’m lazy…..and trying to be DRY

the Lean Startup

The Lean Startup is a term coined by Eric Ries. His very popular blog LessonsLearned, is a must read! The key characteristics of the Lean Startup are: use of open source platforms and free software; use of agile methodologies; and, use of the Customer Development process.

Since the first two things here should be familiar to the reader (if not, they are very well documented elsewhere), I’m going to focus on the third item.

Customer Development process

This is Steven Blank’s contribution which is described on his blog, and his book, “The Four Steps to the Epiphany.”

Some of the key concepts for me include: you should have a vision for your customer, problem and solution, however, you must treat these as hypotheses. This can be tough for some people who, in the beginning, really “own” an idea. But, you must be willing to change your vision – to pivot – in blank’s lingo. How do you know when to pivot or what to pivot to? Well, by engaging with your customer, early and often. Blank has a post that really captures this perfectly with nice anecdote.

For software developers this is approach should feel very familiar — it’s just like getting feedback in Agile methodologies.


Excellent introduction to Customer Discovery, the first step in the Customer Development process: The Entrepreneur’s Guide to Customer Development

I also highly recommend Ash Maurya’s blog focused on web startups.


VentureHacks is blog with fanatastic advise for startups in general. Great book list.

As for Founders: I highly recommend one of their products (I think it only costs $9) which is an interview about “How to pick a Co-Founder”.

And lastly, I recommend the book, “The Partnership Charter“.


Sinatra, Datamapper, Sass and Heroku

Here are a few notes on a simple prototype I just built with Sinatra, deploying on Heroku. It’s easy, but like everything (it seems) there are always a few tricks you need to remember.

To start, here’s an edited listing of my pthingy project directory (pthingy stands for phonethingy). The main ruby file is pthingy.rb. It essentially contains everything except the templates which are in the views directory.

doug@zeus ~/code/spikes/pthingy (master)
$ la
doug@zeus ~/code/spikes/pthingy (master)


Note you have to require libraries explicitly such as haml and sass. For datamapper, you can require just the specific libraries you need or the big kahuna: datamapper.

require 'rubygems'
require 'sinatra'
require 'dm-core'
require 'dm-timestamps'
require 'haml'
require 'sass'


The keys here include requiring the correct libraries you need as well as performing a setup. Note the class definitions include the association assignments.

## Models / DB
# If you want the logs displayed you have to do this before the call to setup
DataMapper::Logger.new($stdout, :debug)

DataMapper.setup(:default, ENV['DATABASE_URL'] || "sqlite3://#{Dir.pwd}/pthingy.db")
configure :development do
  enable :logging, :dump_errors, :raise_errors

# log = File.new("sinatra.log", "a")
# STDOUT.reopen(log)
# STDERR.reopen(log)

class Event
  include DataMapper::Resource

  property :id,         Serial   # An auto-increment integer key
  property :event_tag,  String   # An event key string.
  property :created_at, DateTime # A DateTime, for any date you might like.

  has n, :posts


class Post
  include DataMapper::Resource

  property :id,         Serial   # An auto-increment integer key
  property :url,        Text     # URL of image.
  property :created_at, DateTime # A DateTime, for any date you might like.

  belongs_to :event
  has n, :comments


class Comment
  include DataMapper::Resource

  property :id,         Serial
  property :posted_by,  String   # IP address of submitter
  property :body,       Text
  property :created_at, DateTime # A DateTime, for any date you might like.

  belongs_to :post


require  'dm-migrations'
# Create or upgrade all tables at once, like magic
# DataMapper.auto_upgrade!

Need to go back and see about auto-upgrade!


You can set the default format with the set command. You can set utf-8 for content in a before filter. You can use the haml command to render haml views.

set :haml, {:format => :html5 } # default Haml format is :xhtml

# filter
# set utf-8 for outgoing
before do
 headers "Content-Type" => "text/html; charset=utf-8"

## Handlers
get '/' do
 haml :root


Helpers for views can be added and used in a similar way as Rails.

helpers do
  def post_image(post)
    url = post.url
    image_str = "<img src=" + url + '>'
    "<a href='/comments/" + post.id.to_s + "'>" + image_str + "</a>"

  def how_long_ago(comment)
    diff = DateTime.now - comment.created_at
    hours, mins, secs, ignore_fractions = Date::day_fraction_to_time(diff)
    "%02d:%02d" % [ mins, secs ] + " minutes ago:"


I stumbled a bit on setting this up. There are some incorrect posts out there. This worked for me. NOTE: the styles.sass file goes in the ./views directory.

get '/style.css' do
  content_type 'text/css', :charset => 'utf-8'
  sass :style


.gem file

Ok, now to publish on heroku. The first thing to do is create a .gems file in the project directory. While most of these things are very straight forward, you have to add a database adapter. In the case of Heroku that means postgres.Note that in development I was using sqlite3.

Caveat: I don’t think you need to specify both the datamapper library and it’s individual libraries.

sinatra -v 1.0
dm-core --version 1.0.0
dm-timestamps --version 1.0.0
dm-migrations --version 1.0.0
haml --version 3.0.9


Nothing complicated required here.

require 'pthingy'
run Sinatra::Application

And that’s it! It should work….

As long as you didn’t do something wrong, of course.


An Agile GUI War

An Agile GUI War is a UI design game to rapidly develop team consensus.

For this exercise, it’s important that everyone — developers, managers and all stakeholders — should be considered “on the team”.

The game begins with each member taking 5 minutes and draws a quick sketch. Then, each member in turn explains their design to the whole group. Now everyone redraws their design — but they must add two features they liked that someone else presented.

After a few iterations of this process, you should see significant consensus.In addition to consensus on a UI Design, you will often see ancillary benefits such as improved team chemistry or discover new requirements.

Besides, it’s fun!


Silicon Valley Code Camp

CodeCamp at FootHill College.
Chris Sims has asked me to present at a conference:

the Silicon Valley Code Camp!

So, why an Agile GUI War?

Have you ever been on a tean that had a real GUI War?  It’s usually not very pretty. Things can get ugly fast. Positions get fixed — and things become moral issues.

Agile GUI War is an iterative technique to avoid a GUI War by building consensus on a design among the team and stakeholders

Besides, it’s fun! Come and see for yourself!


The Power of Blogging

Well, here it is. The first post of my first blog. I’ve put this off for a long time — for lot’s of great reasons, of course. But finally I was forced to start a blog. Ok, it’s probably more accurate to say I was embarrassed into doing this.

What could possibly force or embarrass anyone to do something as time consuming as writing a blog?

Ironically, for me it was simply reading a section of blog post entitled: “If you don’t have a blog, start one” by Sarah Allen. I think you’ll find Sarah’s words as compelling as I did. In addition, consider this story as a demonstration of the power of blogging. Think about it: months after writing her post, an acquaintance  takes an action directly because of her words. In the next six months, how many others — mostly people she’s never met — will also read it and take action?

That’s pretty powerful.

So, I encourage everyone to heed Sarah’s words and pity those that try to avoid it. I was able to delay taking action for the last few months only because of my prodigious abilities to procrastinate. While it is true that there were business reasons for doing this now and certainly any content here is my sole responsibility; nonetheless, it’s all Sarah’s fault.

BTW: If you happen to see her before I do, please let her know; you’ll probably get a smile.

So, the journey begins!



Thoughts of Doug Goldie on a variety of software issues including: agile, lean startup, customer development, ruby, rails, javascript, node.js, ...