Unsuccessful Kickstarter – Lessons Learned

My newest venture: Musketeers.me recently tried to fund some new project ideas that we had, via Kickstarter: http://kck.st/QjQZho

As you can see, we weren’t successful.  In fact, we fell extremely short of our goal.  It wasn’t a failure however, because we really learned a lot about our products and made some great contacts and the beginning of a community for them.  We still plan on making these two products.  Just now they will have to be built in spare hours/cycles, instead of us dropping all consulting work and focusing on them fulltime.

But that’s not why I’m really writing this blog post, for things that we’ve learned about our products will come out in time as we do, eventually, release them.  In even better forms than we’d originally conceived.

No, I’m writing to share lessons learned about Kickstarter itself.   Now, all of us at Musketeers.me were familiar with Kickstarter.  We’d watched it, we thought we understood it.  Heck, we even googled for every possible “How to make a successful Kickstarter” article we could find and read them.   And we thought we knew what to expect.  Boy were we wrong.  So I wanted to share some of my own personal findings (some of which are directly about Kickstarter, some are more tangential)

1. Amount of funds
   Obviously in the end, we were asking for far more money than we were able to raise.   The interesting thing is that we had already dropped our asking amount significantly.  We originally calculated that we’d really want to have $200k in order to really have the four of us really focus on making these products up to the point of being fully featured websites that could live a life of their own.   We did quickly realize as we did the math, that asking for $200k was just going to be far too much.   So we backed it down to $50k, which was the minimum we could afford to make that will let us focus 100% on these for a little while.  But, for a ‘non-physical-product’, where people were essentially prebuying a service that they couldn’t even see.  It was just too much.  Unfortunately I’m not sure if there’s anything different we could have done there.  Versus having a completely different kind of product.
2. % of followers
   So part of the calculations that lead us to come up with our number of $50k, was based upon the size of our networks.  Between the lot of us, the Musketeers have around 5000 followers on twitter (and that’s not counting some of our extensive networks on Facebook, Google+, etc).   We erroneously made an assumption that:  “Hey, if even only 50% of our followers would chip in $20, we’ll make it!”  And we were expecting at that point for it to go viral!  (Think Big!).   However;  the reality was that we had 1% of our networks who backed us.   There’s actually a number of reasons for that, but it meant we had started from a very wrong mindset.
3. Noisy Networks
   Everyone talks about how noisy social networking has gotten lately.  But this experience really drove it home to us.  Weeks after we had started the Kickstarter, and all four of us had been pimping it on all of our social networks.  We still constantly run into people in our network who hadn’t heard of it.  Talking to them personally, or emailing them directly, would be greeted with great applause and an instant high backing amount.   But no amount of social network traffic matched that.  (Heck, if you want to see even the worst case of that.  We still to this day run into people who think we are actively working on mojoLive, versus all the posts to the contrary about Musketeers.me)
4. Slow contacts
   Another interesting effect of the noisy network, was how long it would take some acquantances to respond to emails, Facebook Messages, or Twitter DMs.  People that we directly reached out to in the 1st week of the campaign, were suddenly coming out of the woodwork in the last week.  Responding to us saying they thought it was a great idea, and backing us.   With us all being addicts to our social networks anyway, where any direct contact suddenly makes our phones start screaming at us for attention.  This idea was alien to us.
5. Proper network
   We were halfway through the campaign, before we realized this one problem.  Pointed out to us by a good friend.  Simply put, the products that we are wanting to create – are not products that our own networks are the target audience for.  While some ‘tech geeks’ would be interested in these tools.  They really are marketed, if at any specific audience, at more of the self-improvement, “getting things done”, or project management networks.  We started reaching out to these once we realized that.  But since those aren’t part of our core network to begin with, it just wasn’t successful, even after days spent blind emailing prominant bloggers & contacts in that sphere.   The moral of the story here, is that since successful Kickstarter campaigns, start from tapping your own network first.  It needs to be a product that your own network is going to go bonkers over.
6. Higher pledges
   This is a positive thing we learned which we just hadn’t expected (nor really planned for).   We assumed that noone would be interested in backing our project, if they weren’t getting a ‘good deal’ out of it.  So we value priced the primary level at $20 (for a $40 value), hoping to pull people in.   But then something happened.  People started compaining that we didn’t have higher levels.  $100, $200, $300, or higher.  Even if what was being given out was more esoteric (fun?) concepts, versus physical goods.   In the end, we found that the majority of the funding we did have pledged, came from smaller numbers of people, but at MUCH higher pledge levels than our original $20.  Had we planned for this effect appropriately, we would have started off with higher levels, and not ‘value priced’ things so much.
7. It’s all about the video
   Finally now that we are all Kickstarter addicts … we’ve really realized the value of the video.  We spent a day putting ours together.  We shot it on high quality equipment, took a little time planning out what each person would say, spent some effort editing it together, etc.   And it was in the style of a number of Kickstarters that (previously) we’d seen be successful.   But; honestly, it was boring.  And you would see that in the statistics, where only 25% of people who started the video, watched it to completion.   During our campaign, we saw numerous campaigns kick off, who when you think about them have rather abstract concepts behind them, or are charging (in our opinions) way too much for their product.  Yet that get amazingly great, amazingly quick traction.   When you look at the one common trait of all of those campaigns?  Funny, inventive, entertaining videos.   Now thinking about it in retrospect, we are laughing our asses off at some video ideas we would have had that could have gotten the idea of the campaign across, and entertained during the process.   They would have given an emotional response to the campaign, instead of just a basic (if extremely informative) video

In the end, as I said, we’ve learned a great deal during this experience.  You certainly haven’t seen the last of Musketeers.me, and our products which we will continue to work forward on.  You also haven’t probably heard the last of us running a Kickstarter campaign.   But when we do it in the future, we will find a way to do it at a much lower price point, for something our own networks will love, with higher pledge points, and an amazingly awesome video.

Introducing: Treb – A simple framework for PHP

I announced this on twitter yesterday, but figured I should blog about it a bit more today.

As of yesterday, I published a new PHP Framework on github: Treb

Yeah, I know, the world really doesn’t need another PHP Framework, there are tons of them out there.  So why did I create this new one?   Well honestly, I didn’t set out to do so.   You see at numerous previous jobs: Digg, TripAdvisor, HiiDef, mojoLive — I’d ended up building or extending custom frameworks for those specific applications.

In all of those cases, a ‘stock’ framework just didn’t end up making sense.  They locked you into specific ways of doing things, which may not have been what you needed to do in order to scale.  While at the same time, while they provided a lot of structure, they didn’t provide certain features that I felt were necessary (such as built-in write through data caching).
So in each case, something custom got built from scratch (or something existing got customized).   After doing this essentially 4 times.  I was tired 🙂   With mojoLive I got the ability to take the framework that I’d written for mojoLive, to scrub it of anything specific to mojoLive, and open source it.  So I did.

The moral of the story?  It’s just that in the future now, when I need to start a new custom framework for another site, I don’t have to start from scratch again.  I can start from Treb now that it’s open sourced.   Granted right now it’s very rough as it was part of a bigger system and was just ripped out.  But it’s a good starting point.

Will anyone else end up using it?  I dunno, and that wasn’t the goal of releasing it.  I will say that of others that have used this, they enjoyed it, in it’s simplicity.  And new coders to mojoLive were committing code against it on the first day.  So that’s gotta say something.
If you’d like to know more, you can read up about it on Treb’s home, and start reading it’s documentation as well.

NOTE: I’ve already been called out for Treb not having tests.  No, it doesn’t, I wouldn’t argue if it began acquiring them, but it doesn’t have tests written for it because it’s a child of a rapid-startup-culture web application.  I plan on writing up another blog post about that soon.

An intriguing use of lambda functions

I’ve been working hard on Goodsie.com lately trying to bring it to launch. It’s been great being in on a new PHP project from (near) the beginning, as it frees up a number of things.

One of those, is the fact that I can be using PHP 5.3 and all the new features that come with PHP 5.3. While I’ve used my fair share of the short-cut ternary already (?:), the bigger win for me, are the Lambda functions with scoping (anonymous functions).

I found a very specific use out of the blue of Lambda functions that I have now used and I see as a great use-case. Which is specifically passing functions/logic from your Controller to your View.

In the case of Goodsie, I’m using PHP for my templating language and as usual I’m trying to remove as much logic from my View as possible, while still allowing the view to be malleable.

The specific case I had, was a subview that was generating some pagination code for me. You know, the standard ‘previous, page 1, page 1, next’ section of links. The basic HTML template I had, looked looked similar to:

<div class="pagination">
    <a href="<?= $baseurl . '/page:' . ($page - 1) ?>">&larr; Previous</a>
    Page <?= $page ?> of <?= $total ?>
    <a href="<?= $baseurl . '/page:' . ($page + 1) ?>">Next &rarr;</a>
</div>

Rather straight forward, but I quickly ran into a problem. The way it worked, as you see, is that you passed in a base URL, and the page number you are currently on, and it generated appropriate forward/back links. (Ok, there was also some other logic where it determined if you needed the prev/next links at all, but I’ve removed that for clarity)

But I then had a case, where I wanted to reuse this subview in an ajax situation. Where instead of straight URL’s being passed in, I might want to pass in a javascript function, and have that function be called with the page number as a parameter. That would be nice as I could use it in both situations. What pagination looked like, could completely change, and still work on both cases. Perhaps we’d want to give a full list of all possible pages. Or show a couple forward/back, etc. The view could handle all of that without a change to the controller.

But therein lied the problem. When using a URL based pagination, I wanted to concat the page number onto the end of the URL. But when using javascript, it wasn’t pure concatenation, it instead needed to wrap the page number with the function call. Oh the pain a simple ) could cause me.

I started writing code, where I ended up with tons of switch statements and logic inside of the view. I’d have to pass in two different possible values, a URL or a javascript function. The view at every point where it would output a link, would need to see which version was being used, and from that decide what type of output to create. In short, it was a mess.

But then the solution dawned upon me. A lambda function would work admirably here. So what I did, is inside of my controller I created a function on the fly, that would generate the appropriate type of link that I was wanting. It looks something like:

if ($jsfunc) {
    $url = function ($p) use ($jsfunc) { return "javascript:{$jsfunc}({$p})"; };
} elseif ($baseurl) {
    $url = function ($p) use ($baseurl) { return "{$baseurl}/page:{$p}"; };
}

Now I could simply rewrite my original template, to use this lambda function $url to generate it’s URLs.

<div class="pagination">
    <a href="<?= $url($page - 1) ?>">&larr; Previous</a>
    Page <?= $page ?> of <?= $total ?>
    <a href="<?= $url($page - 1) ?>">Next &rarr;</a>
</div>

Now not only would this work for my specific situation, but ANY controller could reuse this pagination subview and define exactly how it wanted it’s URLs to be formed. Now, the view could completely change around how the pagination section is displayed, show as many, or as few pages as it wants to, and all that without ever touching the controller.

This is one simple example, but I’ve become enamored of this approach. Using lambda functions in this way, you are able to have complicated logic represented inside of your view, but encapsulated/created by the controller. Also of note is the fact that the view is managing to use the $jsfunc and $baseurl values, but without actually having to be granted access to them. This allows for another level of encapsulation, as I exposed one function, instead of 2 separate variables. In the future if other data points start being needed to determine what a URL should be, the view never needs know that, as the controller will continue to update the function on it’s behalf.

PHPAdvent entry: Commenting on Commenting

Today’s blog post brought to you by PHPAdvent 🙂   I was asked to contribute, and so did, polishing off a post I had planned for my own blog and submitting it to PHPAdvent instead.

It’s all about commenting & documenting your code, and you should go read it at the PHPAdvent website.