Been using it since alpha stage. Love the way I can ramble and it turns it into coherent paragraphs that I can edit for my recap of meetings or to prepare drafts of emails :)
Our product helps software teams “make something people want.”
When teams build or improve software, they crave data to inform their decisions, but calling, emailing, and surveying customers falls short. Product teams can’t afford to get this wrong given limited and expensive engineering resources.
With FeatureKicker, a team can quickly add a “call to action” for a new feature on a website. When a user clicks on the experimental button, our tech opens a modal window and gets user input on the new feature.
Similarly, teams can get feedback on existing features of their website, so they can improve their product.
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.
Ummm... looks like we maxed out the number of concurrent viewers (max: 50) who can see the Google Doc. We're going to move the application to our blog.
"Honestly, I think it's a cool widget! It doesn't sound nearly big enough to get a 10x return on VC though."
I hear ya... we worry about that sometimes. But then I think about what PG says re "it's our Altair." We gotta start somewhere.
How big is the market? There are 5M product managers in the US, according to LinkedIn. Assuming 13 PMs per company, there are many, many companies that should be using this.
I don't think you could or should replace our tech with a click event. I'll agree that 404 tests are a good start... but they lack qualitative data and a rules engine. I believe that's an inferior customer experience.
We've interviewed 100+ product teams at this point. We're getting good feedback -- especially re "getting data on existing features."
Thanks. You're right that it's not just what users say. You have to observe what they do, too. In the next version of our product, we want to provide a "confidence score" for a person's feedback, which is based on what we've observed them doing in the application (e.g., are they a power user? are they freemium or enterprise user? did they leave yes/no feedback + commentary?).
As for the internal scoring system, we integrate with JIRA so you can send your data to your existing prod-dev mgmt tools. We hear KANO analysis is really powerful when it comes to scoring your prod roadmap.
GovindKabra: Thanks for your feedback. Recently my co-founder asked me to build a google map for a feature showing all thumbs up it received displayed by location. Rather than building this feature, I kicked it on our page.
We also have javaScript API's which can be used to show an overlay.
Here is an example of it being used after a customer does a search: "It asks customers, do you like the search results? and can we improve our search feature?"
I have one beta customer showing overlay after 90 seconds have passed on the "buy-now" page and another beta customer showing overlay when anything is clicked besides the "buy" button.
I hope these examples show how beta customers are using FeatureKicker to solicit feedback.
Other incubator. 2012-2013. Came in with B2B enterprise software (invalidated that), and came out with a consumer subcom startup. Bootstrapped that to 6 figures in 12 months. Growth plateaued, but it's a going concern (~$7200 MRR). I spend about 5 hrs a month on it now.
My main squeeze is http://featurekicker.com -- software that helps teams “make something people want.”
With FeatureKicker, you can quickly add a button representing a new feature on a website. When a user clicks on the experimental button, our tech opens a modal window and gets user input on the new feature.
You can also get feedback on existing features of their website, so they can improve their product.
>> "I checked the website, looks promising so congratulations on that. I do have a comment, your entire website is still linking to your Heroku subdomain."
I hear you. We were being as cheap as possible and didn't want to pay for SSL certificates, etc. while building early version of the product. But we're hearing this more and more, so perhaps it's time to move on :)
>> "If I'm not mistaken, this pretty much feels like A/B testing with the implementation being a survey."
It's interesting and refreshing to see someone else boil down our product. Thank you!
So I agree that it "feels" like A/B testing because you're adding a new element (and potentially removing it based on our rules engine). But it's unlike A/B testing because our tool is not designed to split your traffic across page variations.
Here's what I would add to your distillation: it's being able to ask the right user, the right question, at the right time. And this is where our product is like a "hyper targeted survey".
>> "So have you tested users' sentiments about trying to use a feature only to realize it isn't implemented and then being promoted to answer a few questions? I'd speak for myself, I'd rather not see a button to for example Authenticate with my Twitter account if it doesn't work, than to see one of which when I try to use it, I get asked a few questions. I'd feel that's a bummer."
Absolutely. This was our primary risk. After user testing, we're finding that this concern is more of a theoretical anxiety than actual feeling in practice.
>> "To that point, why would I use FeatureKicker instead of a service like Qualaroo, which works fairly well."
I think the tools and use cases are different.
With Qualaroo, you get a pop-in question based on a timeout, and those questions are typically related to overall customer satisfaction or net promoter score. But we believe that using Qualaroo to ask a specific question about a specific feature on a page will not work as well as FeatureKicker. Why? Because the question may be irrelevant to whatever the user is doing at that time. This gets even trickier when you want to ask a question about an unbuilt feature. Then you have to worry about showing the experimental feature only sometimes and coordinating your Qualaroo question to pop-in when you're selectively displaying the experimental feature.
In contrast, FeatureKicker allows you to ask the right user, the right question, at the right time. Let me unpack that. It's the right user because it's the person using a particular (built or unbuilt) feature. It's the right question because you're going to ask something relevant, specific about that feature. And it's the right time, because you're capturing the user at the point of interaction, which is the peak of their curiosity. We believe this explains why we're seeing up to 64% response rates to our clients' questions.
I love that you displayed your "innovation accounting" here. I'm wondering, how do you account for ongoing cost for maintaining/updating the software? I've never seen software that didn't require some TLC over time...
I disagree that no good can come from "paying for access."
First, we must define what is "good". After participating in DreamIt Ventures in 2012, I can say that we extracted immense value by quickly invalidating a B2B software concept. It was taking me months to get one meeting with an enterprise client on my own. With the help of DreamIt's mentors, I secured dozens of meetings in less than six weeks. We learned that the software we were building was ill-fated through those meetings. This was undoubtedly "good" for us, and we paid a mere 6% for that kind of access. In retrospect, I'd do it again in a heartbeat.
But your mileage may vary. The value we obtained was highly correlated to the fact that we were pursuing a B2B venture, a sector where DreamIt's mentors could best leverage their networks. In contrast, I saw some consumer-facing companies extract less value from the accelerator program.
In sum, you have to carefully (and honestly) weigh the value that "paid access" can yield. Feelings of frustration in connection to "paid access" likely stem from a miscalculation of the cost/benefits that the access could provide.
First, congrats for asking the question, "Did we do something wrong?" Getting more sign-ups is laudable, but are they qualified signups that are improving metrics you care about? Removing the demo, you're potentially removing an important lead-qualifier for your traffic.
The real test is "which cohort achieves higher [metric you care about]?" For example, let's say you care about revenue. Does the "demo button present" cohort generate more or less revenue than the "demo button absent" cohort?
I have to agree with you. We had a blog post, that percentage-wise, was by far the most popular in terms of traffic. But it also had the worst "path to conversion rate." We hypothesized that this was due to the post being interesting in search results but not necessarily attractive to our target customer.