It’s pretty easy to use a ruby script as part of a Linux or Unix pipe process to filter output of another script or set of commands. You can just use something like the following:

#!/usr/bin/env ruby

while line = STDIN.gets
  puts "filtered: #{line}"
end

The STDIN.gets is the magic. It just takes whatever the output of the preceding scripts and pipes it in. Then you can make the script executable and run it. If this script is named filter.rb, then you could run something like:

$> cat log.txt | ./filter.rb

If your log.txt file looks like:

line 1
line 2
line three

Then the results of this program will be:

filtered: line 1
filtered: line 2
filtered: line three

I wrote this up because I regularly search around for this but it was hard to find exactly what I’m looking for, so hopefully it will be easier the next time I search. :)

Ran into a problem where something was installing rake v0.9.0 into my gemset when I ran bundle install. I really had no idea where this was coming from, just before I had:

*** LOCAL GEMS ***

bundler (1.0.13)
rake (0.8.7)

and after running bundle I would get:

*** LOCAL GEMS ***

...
rake (0.9.0, 0.8.7)
...

This caused various problems, which can be seen here (general) and here (Rails 3).

My problem was slightly different than those, in that even after specifying:

gem 'rake', '0.8.7'

I would still get the problem. I figured that some gem that I was installing with bundler was installing the 0.9.0 rake gem. Since I didn’t know exactly what gem was installing it, and didn’t have any better way of debugging this (if you know a way, please let me know), I wrote up a script that continually polled for my installed gems:

while true
  sleep 1
  `gem list >> 1.txt`
  `echo '' >> 1.txt`
end

I then reset my environment, ran bundle, ran this script in another terminal tab, and ran tail -f 1.txt in another. This way, I could see approximately when the offending rake 0.9 installation happened. After bundle ran, I killed all of the scripts and tails, and looked in the text file to see when the first time rake 0.9 was introduced. I compared it to the gem list output directly prior, and got this diff:

64c64
< rake (0.8.7)
---
> rake (0.9.0, 0.8.7)
79a80
> spork (0.8.4)

Aha! After some finagling (read: deleting the spork gem for now), I get things working correctly.

For awhile, I considered just deleting the rake 0.9 gem whenever I did bundle install, but this was hacky. It caused problems when I built on Hudson and when I pushed to Heroku. So I just figured I’d write up the process of figuring out how to solve this since I thought it was interesting and might be of use in the future when you don’t know of a debugging tool that will allow you to see inside of an opaque process. Plus, there might be other gems out there that do the same thing. I’m not sure why this version of spork was causing a problem, but figuring this out would be helpful.

EDIT 20110622 - the spork gem has been fixed (as of May 26th)

If you read through this post, you’ll see some sweet pictures and figure out a potential new way to get cookies and brownies.

I got together with Alex Toumey, Kyle Shipley and Wes Winham on April 16 for an event practicing lean startup concepts.

We started off by pitching ideas that we thought were interesting and needed some validation. At one point, we riffed on one of the ideas by coming up with “Etsy for baked goods.” The idea seemed kind of hokey at first, but the more we talked about it, the better it seemed. We put aside the other ideas for future exploration, and talked about our thoughts on the idea. We came up with a quick description to make sure everyone was on the same page: a marketplace for people to buy and sell local baked goods. Seemed good. What better time to test this idea against cold, harsh reality? :)

Brownies, or bullshit?

Next, we sketched out some basic hypotheses and some questions to test these hypotheses, and contacted friends and family to get some feedback. Someone took pictures of these, I’m sure, but I can’t seem to find them, or I’d post them.

Two keys that I thought we did quite well at this point were:

• not sticking to a set script
• and asking for references at the end of the conversation

At this point in the process, asking for too specific of feedback would have hampered the quality of learning that we were getting. This is something I learned when doing Lean Startup Machine Boston, and Ash Maurya also references this in Running Lean.

By asking for references, we expanded the number and quality of people that we were able to contact in a short period of time. It was a bit surprising how well we did just by calling people we thought might know a lot about baking.

• Person 1
  • Left voicemail
• Person 2
  • Tried to start up a basic Christmas cookie selling business – ran into VA licensing issues and didn’t pursue further
  • Researched commercial kitchen rental opportunities – too much hassle
  • Some temporary licenses available in VA
  • farmer’s markets have vendor licensing
    • produce vs. baked goods difference?
    • produce can be sold easily; processed food is regulated
  • Recommended checking our local county web sites
• Person 3
  • Had read about a tangentially-related case study involving South American women selling baked goods that were shipped to America
  • Feels like cookies are more of an impulse buy item
  • Warmed up to the idea of “ethnic food in your neighborhood”
  • Has a sister who is a pastry chef if further research needed/desired
• Person 4
  • Will contact again later – some hearing issues over-the-phone
  • Has been encouraged to sell at farmer’s markets, but hasn’t taken the plunge
• Person 5
  • Liked the idea
  • Wasn’t very worried about food safety, going to someone’s house
  • Liked the idea of local food that was not going out to eat, seemed healthy and would save her time (no preservatives)
  • could see using night-time meals as well
  • wonders about FDA or other regulators
• Person 6
  • Thinks she would have been excited about the idea when she was a stay-at-home mom
  • Would only consider participating if she could pre-fill orders (guaranteed purchases before she started baking)

After lunch, we worked on a business model canvas for the idea. This is something that I had wanted to do for awhile, so I brought my Business Model Generation book and we took a crack at it. I thought that the process gave us good insight into the challenges of the business.

After fleshing out a couple of sections

The “finished” business model

If we were to continue working with this idea, a solid next step would be to take the most risky assumptions on the business model canvas and start testing them for validity. In my mind, getting a little more perspective on the demand from buyers and sellers for our chosen idea might be a good plan. I’d probably label the riskiest hypotheses with hot pink sticky notes to make them stand out a bit.

In the process, we came up with a few directions that we could head with the baked goods idea that were slightly different (ingredient label maker, targeting more professional services), and also have a list of other backup ideas that seem useful.

I had a really good time going through the process with everyone. I thought we got a lot done in a day going from just an idea to getting a lot of thought on the problem, and building up our customer discovery skill.

Afterwards, we played some Halo 3 and it was a ton of fun! :)

Our next time doing this will be Sunday, May 22nd, 2011. Contact me at panozzaj@gmail.com for more details.

Summary: I have done a few startup weekends and customer discovery events in total and have found some common patterns.

Pregame

Make sure you have alerted friends and acquaintances about the weekend so that they know they probably won’t see much of you. This helps clear any potential distractions. It definitely helps to clear your plate as much as possible. At one of the competitions I had to fix something at work that couldn’t wait, and it took half of Saturday up. As you can imagine, it was frustrating for me and I wasn’t much help to the team.

Before the event might be a good time to start eliciting help for electronic voting. Something along the lines of, “hey, I’m doing a business competition this weekend, and part of our final score comes down to people texting a certain number.”

For the sake of everyone at the event, if you are pitching an idea, do some basic groundwork on the idea. Nobody wants to hear your pitch if the idea has already been done or is way too big for a startup weekend or is mumbled. You are just wasting everyone’s time. If you have an original take on an existing idea, fine. Just make sure you know enough about the environment you are considering working in to actually know about prior art. An hour of your time saves sixty people from hearing and voting on a minute pitch. It might sound equivalent, but it’s a net gain in terms of attention and energy. There were about forty pitches at the last startup weekend that needed to later be voted on, which took time.

Pitches

Along the same lines, when at the pitches, listen for ideas that are pretty well-defined and that preferably have some sort of validation already. About the worst thing you can do is spend half of the weekend figuring out what you actually want to work on. About as bad is trying to do something for awhile and then basic research suggests that the idea has already been executed well by someone else. At that point the team flails for a few hours. Not a good start.

I generally pitch something that meets the criteria above and/or look for an idea and team leader that I think I will be able to work well with. I also check out the people who are joining the team and try to make sure that they are an impedance match. Talking with people before the event gives an idea of who I can most easily work with. You don’t have much time to butt heads, so picking a good team is really useful. Plus, nobody wants to spend the whole weekend working without having a little fun. I want a good story to tell, and picking a bad team, even if only for a weekend, is not a fun story to relive.

If you are just doing a small event, the same pitching process happens, and you can just pick the best idea out of the ones that you have come up with. Make sure to write down the other good ones in the event that you are going to do another event and want some ideas.

A New Team

Being productive with a team of strangers works best when you get off to a good start. Here are some patterns that I’ve observed.

Go around and introduce yourself and explain why you are interested in working on this idea. This lets everyone get to know each other, notice any biases or preconceived notions, and generally start forming around the idea of working on a shared project together. You can see why everyone picked this idea and team as the one they wanted to work on, and it leads effortlessly into the next time block.

This time period is always interesting because people may still join or leave the team. Just stay focused on the process, and the introductions and problem solving will work themselves out.

Next, everyone goes around and says at a high level what they think the idea is as they heard it from the person who pitched it. This puts the idea out there in a few different forms. After this comes a period of adjusting to the different viewpoints and emphases. Hopefully everyone is generally on the same page, and gelling occurs as you work out the key things that need to happen.

Generally at this point, it makes sense to solidify the problem you are trying to solve. Any talk of product or solution should be written down on a separate sheet of paper, preferably at the other side of the room. You must figure out the problem you are trying to solve before you can reasonably attempt to solve it. This will help marketing and development efforts greatly. You may identify many different problems or potential stakeholders, but for the sake of time it makes sense to focus only on the most valuable or easiest segment.

At this point in the process, I think it makes sense to take a step back and do some administrivia. Figure out who will be your team communicator that talks with advisors or other teams and communicates at startup weekend status update meetings. These can consume a lot of time, so it’s best to have one person to handle this. This person is still involved in the workings of the startup, and also has this extra role.

Keeping with administrative tasks, one person should be the head time keeper, in charge of letting everyone know when the next meal or meeting is. At this time, go over the whole weekend and get a lay of the land. You want to budget enough time for everything that you want to do during the weekend. Ask everyone if they are free for the whole weekend. Maybe someone has a soccer game that they need to watch, maybe someone has a party that will take a couple of hours. It’s useful to know these because then it isn’t a surprise and everyone feels that they can do what they need to do without being “that guy”.

Are We At The Solution Part Yet?

Well, if you are using a lean startup methodology (generally most applicable to Lean Startup Machine events), now is the time to validate that this is actually a valuable problem to solve. It’s part of producing the value that you need to produce (validated learning.)

Next, figure out a potential solution path. This should include what specifically you are going to build next, what the goal is for the weekend, and extensions. It’s good to start with a vision of greatness and then taper it down so you can show some progress. For more tips on defining the solution, check out Jared Brown’s post on defining the message of your startup.

If you are using lean startup techniques, at this time you should validate as you are building the solution to ensure that you are building the right thing and that it resonates with people.

Iteratively build until you just about run out of time. I suppose not much needs to be said about this.

Finally, work on the pitch to make sure that you don’t blow your time. Often you will only get a few minutes to describe what you did during the whole weekend to a group of people that has heard nothing of your idea. I’ve seen way too many teams blow this with irrelevant information. You are completely wasting your time if you talk about any of the people on your team unless they happen to be super-famous. The judges don’t care about who is on your team, they want to see what you got done or learned during the weekend.

Although I recommend practicing the final presentation a few times, it’s definitely not enough to have a good pitch and no product. A demo is worth a thousand words, which happens to save you quite a bit of time. You need to have something to show. If you can’t make a full product, make a prototype. If you can’t get to a prototype, lay out some screenflows. Any artifact that represents your thinking and the conversations you’ve had is better than just words. Arguably the screenflows should come before the prototype so that at any point you have something that best represents your product.

Random Thoughts And Question

I’d enjoy seeing some more non-tech startups at startup weekends, and even working on one. Also, some more non-profit or philanthropic companies would be interesting. The key here is coming up with a business model and proving the validity. It seems like this would be doable in a weekend.

Have you done a startup weekend? Does this experience relate to what you have seen? I haven’t won any, so maybe I’m going about this all wrong…

I want to put myself in a position where I can fail. While this might not sound very appetizing, I’ll make a case that it is.

I could wait two years until someone decides I’m ready for the next level, or I can decide that I’m ready–experience be damned. At a certain point, more book learning or current level learning isn’t helpful.

I could talk myself out of taking the next opportunity, or I can just do it and try my very best.

I could whisper to myself that once I learn X, then I’ll finally be able to do that thing that fascinates me. (Hint: X usually changes to Y once you know X. Or you say that you don’t know X well enough yet. And repeat.) I’d rather try using what I know and learning just-in-time and take a chance that I won’t figure it out in time.

Whether adventures are deemed a success or failure, I learn more about myself and gain more skills than had I taken the more known route. What’s more, I gain experience in the skill of advancing by my own will.

One problem with coasting is the opportunity cost of not doing something more interesting or valuable. The best are continually improving, so by standing still you are going backward by comparison. If you are in the top 1% of the world at something, there are still sixty million people to compete with.

When you can’t really fail, there is no downside. However, this means there’s probably little potential upside. Exposing yourself to risk is the key to getting disproportionately higher upsides.

Financial advisors say to take risks with your 401k when you’re young because you can make more money and there is still time to recover from setbacks. I say to be risky with your career when you’re young, because you have a lot of time to use what you learn, and that on average you’ll make more impact (and money) in the long run.

I think most risks are far overstated. Using the analogy above, always taking the safe route is actually more risky in the long run.

Therefore, I propose a life heuristic: if there is little to no chance of failure in what you are currently doing, you are missing out on something.

The actionable advice of this is: actively seek to put yourself in a position where you can fail.

If I am wrong about my abilities or the amount of actual risk, I want to know this as soon as possible so that I can course-correct. Putting myself in positions where I can fail lets me fight my way out of problems. I’ll learn by having the chance to mess up, and then succeed.