mult.ifario.us

I was talking with a budding entrepreneur in the open source "big data" space (with my Entreprementor hat on), and we talked about his sales pipeline and potential customers. He had a list of a couple dozen companies that had expressed some interest, and that much was great. Just the same, I asked about the elephant in the room: Interest in what? Interest in your wonderful open source doohickey might get you Internet Famous like the Star Wars Kid but isn't likely to pay your bills let alone be something to build a company on.

This brings me to the subject of product management for the busy entrepreneur.

Product Versus Business

It's easy to get confused about the difference between a product and a business. A business is a machine that turns something you have into money. (One that produces more money than it consumes is a good business...) A product is a describable, sellable thing that your business can produce over and over and customers can consume over and over without too many changes. Products can be broad, like professional services, or very specific, like machine parts, but the aspects of commonality in description and delivery need to be there.

The point of a product is that the commonalities enable scale in a business's internal processes, from production to sales to accounting. It is also that commonality that makes a business an investment prospect because you can make reasonable inferences about capital in versus capital out (ergo value). Defining a product involves a bit of intuition and guesswork, but refining that definition is simple: Ask potential customers if they would spend money on it. I've never been able to understand the relative reluctance of some entrepreneurs to get on the phone or hit the street with an idea, maybe out of a reluctance to have their idea trashed by reality, but the customer's money is the one source of Truth. If it's difficult to explain, if it's not something that the customer's business can readily consume, or if the customer doesn't "get" it, then it needs to change.

Rows and Columns

Once you have a panel of potential customers assembled, it's time to sit down with a spreadsheet and figure things out. Customers go down column "A", and potential products go across row 1. Put an "x" and maybe a note in a cell if that customer would pay for that product, and then look for the column with the most x's. Alternatively, you can use the price that the customer would pay as the value for the cell in the column and try to make a more refined decision based on the profitability of the offerings, but the idea is the same — Get real data on what customers want.

There's an aspect to survey design that's important when interviewing a potential customer. To get a real response, ask specific questions and set the expectation with that potential customer that you'll very likely be back to get a check from them. You should expect to iterate on the process a few times, as customers may help you add columns to the spreadsheet, but you should avoid open-ended questions.

Real product management is quite a bit more involved and detailed but equally necessary as your product and base of customers grows and evolves. Nonetheless, this should be enough to get started.

Basic product management is one of those times where stating the obvious is useful: Data is helpful in making decisions.

Every so often, I'm away from my primary home machine (accessible via secure shell on a non-standard port) and I want to shut down Mail or Adium or RemoteDesktop or some other application. The following hack provides a more graceful shutdown than a kill from the commandline:

$ osascript
tell application "Mail"
        quit
end
<CTRL-D>

Where the "Mail" could be "Adium" or whatever.

For anyone who's been wondering why this blog has been up and down over the past week, it's a slow-motion battle between the memory police at TextDrive killing Typo instance that hosts the blog and either a FastCGI dispatcher or a nanny cron job starting it back up. The onus is clearly on me to figure out what's burning memory, and my first inclination was to naively google for Ruby profilers. Here's a rambling account of what I did to conclude that I'm probably out of luck as far as a quick cure for the issues and then to address them.

There are a couple of speed-oriented Ruby performance profilers, the built-in one and ruby-prof, but there are no space-oriented profilers. There was a brute-force approach based on ObjectSpace.each_object in an old mailing list post from Michael Garniss that looked suitable, so I integrated it into the main controller in Typo as an after_filter and fired-up several concurrent wget commands to walk around on a production configuration on my development box at home:

while true; \
do wget -nv -r --delete-after http://localhost:3000; \
done

(There is no reason to try to set it on fire with something like ab.) That won't catch any issues with the vanilla two dispatcher lighttpd/FastCGI configuration that I use on Textdrive, but it should catch any issues with Typo internals, badly behaved sidebars, etc.

With the profiling code integrated, a request that includes the dump takes several seconds to complete, and there are several hits per page; so I added a class variable (@@no_sooner_than) and a little logic so that profiling requests would only run once a minute or so. With several wget walkers working, top reports that the server runs along at a happy 80-90Mb, and eyeballing the profiling output shows memory usage oscillating between <7Mb and ~20Mb without any perceptible upward trend over the course of an hour and a half. (That said, that's all the data I captured, as WEBrick locked up completely after that hour and a half.)

Armed with the information that there wasn't an easy fix for the memory issues, I switched the FastGCI configuration for the production instance to a single dispatcher from the previous two, pointed a couple of wget walkers at it, and tracked memory usage and process id at the commandline, like so:

while true; \
do ps mux | grep ruby | grep -v grep; \
read -t 30; done

I also changed the wget walker command to provide more useful information:

wget -S -r -b -l 4 --delete-after http://mult.ifario.us \
-a /tmp/log_id

where id is a unique number per walker, and so far, so good. Crunching the wget output through shell commands (awk, grep, cut, sort, uniq -c, etc.), e.g.:

cat log* | grep HTTP/1.1 | cut -f 4 -d ' ' | sort | uniq -c

says that mult.ifario.us is consistently returning snappy HTTP/1.1 200 responses about two nines (99.x%) of the time, which isn't great but isn't awful. (Really it's more like 2.5 nines, i.e., −log₁₀(0.003), but who's counting?)

This is one time when I've missed some of the Java runtime environment's capabilities (i.e., the JVMTI) in other language runtimes, but no rocket science was required to get Typo under control.

When I was a mathematician, my preferred tools were a hard-bound notebook, a rollerball pen, and a box of crayons. I drew tons of pictures to help myself make sense of my ideas, and when I needed one for a document, I'd spend some time and draw it up in Adobe Illustrator or write a program in a T_EX macro package to draw it. I've written other entries about why as-plain-as-possible text files are preferable to formatted documents in a system like Microsoft Word or Open Office, and the same applies to drawings, except that in this case, it involves not using a computer at all.

A piece of paper or pieces of paper, fed into a fax machine and then received via j2 (or eFax or another similar service) or scanned with a multifunction machine and converted to a convenient format (i.e., PDF), are more time-effective than a drawing tool like Visio or even OmniGraffle. It takes a few minutes to sketch out what's needed, drop it in a sheet feeder, and then collect the results for use as an email attachment or for cut-and-paste. (At least on the Mac, Preview supports cut-and-paste to other applications as native PDF.) For a related take, see Paper Prototyping Graphics, although the idea of using stickers seems like a step back toward unnecessary frills to me.

In the form of a “do the simplest thing” corollary: If you need to draw a picture, use a pen. If you need to draw a pretty picture, use an app.

We've become almost exclusively digital music consumers. It's easily been six months since we bought our last CD, and a Squeezebox has replaced a CD player as the primary means of playing music in some parts of the house. After some experimentation with SoftSqueeze as a client for the Slimserver that streams music to the Squezebox, I settled on a combination of the headless squeezeslave player with some shell scripts that use the web interface to the Slimserver (via curl) to play, pause, skip, and shuffle, e.g.:

#!/bin/sh
curl -s http://slim.internal:9000/status_header.html\
\?p0=pause\&player=172.16.1.201 > /dev/null

So far, so good with leaving iTunes behind. Now I just need to write a Quicksilver integration...