Hasta La Ideas

Kickstarter made some interesting changes to the rules Project Creators must follow last week. What’s really interesting about these rules, is that they mainly affect only Product Design and Hardware projects.

Let me take you through each rule change, tell you how I think they will effect Product Design projects, and then finish up with something I think Kickstarter should consider.

Change #1: Risks and Challenges section

Located at the bottom of a project’s home page, this is a Creator written overview of the risks and challenges a project will/could face. It’s now in effect for all Kickstarter projects.

This is a great idea. Backers should know upfront what needs to happen to make a project a reality and it reinforces the idea that Kickstarter is not a traditional store.

Ultimately, this rule will be more beneficial to Creators than Backers. The more you think through potential pitfalls, the better prepared you will be. Many of the Creators I see doing product design projects on Kickstarter are novices and don’t think about this until it is way too late (crying to themselves at 2AM, ten months past their estimated delivery date).

I actually think Kickstarter should take this a couple steps further, with Backers receiving more background information on the Creators. Things such as the number of people on the project team, how far along in development they are, what their professional/educational background is, and how much manufacturing experience they have, should all be made available for Backers.

One thing I want to note: The projects I’ve seen use this new Risks & Challeneges section don’t seem to have put enough thought into it. On one project I saw, the Creator wrote a three sentence description that boiled down to, “There are many steps to complete,” with no explaination of those steps. Perhaps Kickstarter could give a basic outline that would help Creators fill this form out and make sure they answer important questions?

Verdict on Change #1: A good change that should go further.

Change #2: Product simulations and photorealistic renderings are prohibited. Pictures of prototypes in their current state, technical drawings, CAD designs, sketches, and other parts of the design process are allowed. This only effects Product Design and Hardware projects.

The problem Kickstarter is trying to address is the right one, but the way they’re trying to solve it is wrong.

Here is what’s currently happening: When Backers see a hot looking computer rendering, they (understandably) think what they are looking at already exists and support the project believing that the project will ship with no problem. This is bad.

The problem isn’t renderings, it’s that Backers don’t know how to interpret renderings. Most of them probably don’t even realize they’re not photographs. However, you don’t solve this communication problem by eliminating renderings, you just create new problems.

Kickstarter’s solution is to only allow pictures of prototypes as they exist at the time of the project launch.

Prototypes are really important and should be required for all Product Design and Hardware Kickstarter projects. You learn more about how your design works and will be produced from making a physical mockup than you would from 100 renderings.

But here’s the thing, prototypes can be just as misleading as renderings. It’s easy to make a single prototype, just like it’s easy to make a photorealistic rendering. The trick is actually mass producing that thing. I can’t tell you the number of projects I’ve been on where we get what looks like a finished prototype back in a month but then it takes another year to get it through production.

Eliminating renderings does not make manufacturing easier, it just makes it harder to describe to Backers what you are trying to do.

Here’s how I would solve the problem. Make prototypes required, but also allow renderings. The difference will be when Backers see images of those things, they need to be clearly labeled as to what they are with Kickstarter provided explanations of what a rendering is and what a prototype is. That way, Creators would still have the tools they need to tell their story and Backers would have an explanation of what they’re looking at and a better understanding of the level of development that has gone into the project so far.

Verdict on Change #2: This rule doesn’t solve the real issue: Backers need to be educated on what they are looking at.

My recommendation: Kickstarter should start requiring prototypes, but renderings and simulations should still be allowed. In either case, both must be clearly labeled as to help Backers understand what they are looking at.

Change #3: Offering multiple quantities of a reward is prohibited. This only effects Product Design and Hardware projects.

In the past, Creators were able to offer different quantities of a single product. Say my project is to develop a “widget”. I could offer a reward tier that would allow you to purchase one “widget” and another reward tier where you could purchase five “widgets”.

Kickstarter’s hypothesis is that by limiting the quantity of “widgets” that are produced, it will help make life easier for Creators. This is a fundamental misunderstanding of how to streamline manufacturing.

Producing large quantities of a single item actually helps Creators. It allows them to make larger purchases with their vendors, giving them more clout with that vendor, which keeps Vendors motivated to help the Creators. Smaller orders always get less priority, leading to delays. Larger orders can also mean more efficient use of a Vendor’s equipment. Once a production line is up and running, the difference between producing 500 and 5,000 can be minimal.

For Creators, large quantities of a single item can lead to bulk discounts. If 1,000 “widgets” costs $1.00/unit to produce, 5,000 “widgets” might cost $0.50/unit to produce. This is hugely beneficial to Creators, especially when the unexpected happens. It’s common on Kickstarter for shipping to end up costing more than estimated or a project turns out to need more development than anticipated. We shouldn’t punish Creators for things that happen all of the time in even normal product development.

(more…)