Karthik: Thanks, buddy. We are still validating our idea, collecting feedback from beta users and trying to prove to ourselves that this things has legs. Soon though we'll release a native version of FeatureKicker. Something which tags elements and gestures. Imagine shaking the phone, and our overlay coming in to ask, "We think shaking should do X. Is that what you expected?"
What do you mean by "Backend-as-a-service"? Tell me more.
Sandeep: Sorry little late in seeing these comments. Check out startups like StormPulse, Parse, and Stackmob to see what I mean about Backend-as-a-service.
I think this seems like an "easy" thing to build in-house, but we believe getting this right will take a ton of time, which companies could put towards doing what they do best.
Here is what we have:
1. The rules engine, to track visitors and fine control who see's feature experiments and how often.
2. An analytics suite, to capture all data and show it in a form which is digestible and allows a PM to take action
3. Making overlays work cross browser and device.
4. Solution which requires absolutely no-code to get feedback on existing features. A gui where PM's can visually find features on their website, tap on them and configure them to ask for feedback.
Thanks, austenallred. I'm not sure what you mean by "people will go out of their way to get it". Can you tell us more? I'd love to address that in our application.
We have a rules engine, which can be used to really fine tune when and how the feature experiments are shown.
For example, you can setup so
1. feature experiments are only shown to a customer who has logged in at at least X times.
2. You can control so they don't see an experiment after it has been seen once by them.
3. You could say that if they have seen 1 feature experiment, then they shouldn't see another 1 for X days.
4. You could also only show to X percentage of your traffic.
5. And many more rules.
I like the idea of being able to crowd source ideas. It would be a great feature for me to "kick" and see what customers say :)
BTW One question that I think anyone considering an investment would ask is: "Do you use your own product to collect data on features for your product?". :-)
Arethuza: Absolutely. I have been "kicking" every feature my co-founder has brought to me, before I build them. Recently he told me build a feature which shows a google map, with customer thumbs up displayed by locations for a feature. Before building this thing, i "kicked" it by putting a mocked maps image with a button on top saying "enable report". Within days it was clear that this feature was not a top priority.
Also I use FK to monitor our existing features and ask feedback on them. I love that now i don't have to write 4 lines of code to monitor 1 line of code. FeatureKicker's no-change solution to monitor and get feedback on existing features rocks.
FeatureKicker provides both qualitative and quantitate feedback. Besides what the customer has said, you can also see things like how many time was the feature "viewed" and then how many times was it "clicked". How long was it open for, did they highlight things when reading etc. In our next version, we r planning on building something to better digest all this data so customers can take quick action.
6thSigma: Thanks for your feedback :). To answer your question, with our beta customers, we have shown the feedback overlay more than 1K times and have gotten a 60% feedback rate.
We think this is because we ask the right person, the right question at the right time. Its the right person, because this person clicked on the feature, its the right question because the question is about the feature they clicked on and not their age, gender etc. and its the right time because they are in the app, just clicked on the feature and at the height of their curiosity when it comes to that feature.
In regards to frustration, we believe this is a valid theoretical concern, but in practicality with our 27 beta customers, we haven't yet had anyone complain.
We think this is because our customers are using this in a "logged-in" product, leveraging our rules engine to control how often the feature experiment is shown and to who.
If I were you, I'd get rid of the "right person, the right question at the right time" bit in the application and include "we have shown the feedback overlay more than 1K times and have gotten a 60% feedback rate."
I'd think it would be because "right person, right time" would be what everyone else would be saying, while "1K times and have gotten a 60% feedback rate" are hard numbers with 60% being extremely high for this type of thing. If you're pitching to someone who understands how high 60% is, it has more impact than the story.
I think for a general investor or layman, the story would be more compelling because it lays out why it is high (and that it is high for the industry). YC would be in the more technical group and would already know this, so just giving them the 60% is more likely to get their attention.
One is marketing speak showing why you think users would want to give feedback and the other is actual metrics showing a pretty high success rate of getting real feedback.
