3 July 2014 | 21 Comments
I’m currently in the final week of my Kickstarter campaign for the Treasure Chest. This has been a unique campaign because of its simplicity. The contents and structure of the product were determined before the project, and there’s only one version of the Treasure Chest. There are a few add-ons, but they’re separate, external packs (coins and stars).
For the most part, this has made the project run a lot smoother than our previous campaigns. We’ve still managed to engage backers in the comments and by surveying them about future Treasure Chests. Although it’s a bit of a foreign concept for Kickstarter, most backers seem to understand the all-or-nothing concept behind the Treasure Chest: If you want it the way it is, you can back it; if not, you can choose to not back it. There’s no middle ground, no multiple SKUs, no multitude of variations.
But I’ve still received a number of requests–both publicly in the comments and privately–to change certain things or allow for certain exceptions. One backer might want a different color gem, or another backer wants double the gold tokens and no wood. A few backers have requested the Treasure Chest be bigger to hold other components, and some backers have asked that I send them an extra set of Euphoria recruit cards (a free inclusion in every Treasure Chest we recently added).
I’ve said no to all of these requests as politely as possible. I’ve talked about this on the KS Lessons about how it’s okay to say no and the importance of avoiding project creep–we have a very specific strategy with the Treasure Chest that allows us to make and deliver it at scale, inexpensively, and efficiently. But it still doesn’t feel good to say no.
So I was going through my notes, and I stumbled upon an article that explains a better way to get people to understand where you’re coming from when you say no. The article is specifically about winning arguments, but I don’t see it from that angle. I’m not interested in arguing with backers, much less “winning” arguments. But I am interested in helping backers see that a lot of forethought went into the way the project is structured, and that it’s not easy or feasible to change things at a whim.
The key, as I’ve extrapolated from the article, is that when a backer makes a request that you can’t fulfill, instead of saying no, ask that backer to explain to you exactly how their request would become reality. Ask for step-by-step instructions, and help them fill in the blanks when they’re missing information.
This is much more effective than simply saying no, and it’s also more effective than you explaining to the backer how their idea won’t work. When you have to explain exactly how something will work, you often realize for yourself that it won’t work. As the article puts it more bluntly, “Odds are they have not done the work required to hold an opinion.” They’ll end up saying no to their own idea so you don’t have to.
And the neat thing is, every once in a while, a backer will brilliantly explain how their idea can work, and you’ll learn something from them. It’s also a great reminder to project creators like me that despite all the foresight, research, planning, and budgeting I put into a project, backers don’t have all of that information, so I shouldn’t expect them to know if something can or cannot work.
Conclusion: The next time you’re about to type “no” to a backer, instead ask them to explain to you, step-by-step, exactly how their idea would be implemented and executed. I think you’ll be pleased by what happens next.
Also read: The Best Career Advice You’ll Hear Today