Reward Early Feedback With Features

I’ve invested in hundreds of companies that have started from scratch and I’ve been though some crazy number of product launches, especially if you include all of the TechStars companies I’ve been involved with. These alphas, or betas, or v1.0 or v0.1 launches are exciting moments as they signify the transition from an idea to a product. And, it’s at that point that the real work begins.

Early in the life of your company you want feedback. From anyone. Of any kind.

It’s often hard to get this feedback. You spend all of your time trying to get some people to use your product. When they have problems, you try to fix them. But you are maxed out – with all the various responsibilities you’ve got and all the things you are trying to do to keep things moving forward.

Occasionally you get feedback. Sometimes it’s precise – a feature request, a suggestion for how to do something differently, or a description of something that’s not working correctly.

Reward this feedback with features. Fix the bug and then tell the person who reported it that you did and thank them for pointing it out. Implement the requested feature and tell the person that suggested it that you did it. Write a blog post about it and name the feature after the person. Be public about thanking the person for the suggestion.

In addition to making your product better, this does two powerful things.

First, it creates a feedback loop with your early users so they know they are specifically appreciated and valued. This will encourage them to give you more feedback, use your product more, and be part of your extended early community of fans.

More importantly, it builds a feedback loop culture into your business. You and your team will realize the feedback matters. You’ll show this through action. Your users will realize this. And they’ll value it, and you, more.

What do you do to get feedback from your early users?

  • One way good way to solicit quality feedback, especially in the beginning, is to provoke your users a bit. That is, make changes and add features that will provoke a strong reaction. Make bold moves, take risks, challenge what your users think they want by going in the opposite direction. Often this will lead to a more engaged and passionate set of early adopters.

    In the early stages, when you really have no clue what works and what doesn’t, I’ve found that being intelligently bold is a far better way to get your user base to help you refine your product, as opposed to making incremental changes to get closer to the product your users think they want.

  • His has a different focus, but it looks to me like you and Seth Godin posted conflicting opinions coincidentally on the same day:

    • I don’t think these are conflicting – I think they are addressing different issues. Your early users are likely NOT anonymous. You WANT to develop a relationship with them.

      • Agreed – How to solicit feedback, and yet inure yourself from not being universally loved are two orthogonal themes – both important.

        This reminds me of opening verse of Rudyard Kiplings “If”
        Which wise thoughts often do !

        And yes it ALWAYS bears repeating – ask @JLM over at Freds place 🙂

        So I hate to waste bandwidth but …
        “IF you can keep your head when all about you are losing theirs and blaming it on you,

        If you can trust yourself when all men doubt you,But make allowance for their doubting too;

        If you can wait and not be tired by waiting,

        Or being lied about, don’t deal in lies,

        Or being hated, don’t give way to hating,

        And yet don’t look too good, nor talk too wise”

    • I guess that the main idea is that listening to the mob sucks but you can listen to those who can be called “qualified users” – that’s your main target audience. And I think Brad is right saying that early users are exactly of such type.

  • James Mitchell

    In addition, doing so creates a lot of loyalty.
    Imagine that, a company that actually listens to bug reports and feature
    requests and then implements them! That’s the kind of company I will mention to
    my closest 100 friends.

  • Great reminder post, especially as we head toward our own alpha. It’s a challenge I’ve been struggling with ideas to address. This helps, so thank you.

  • Excellent post. Been struggling with ideas for soliciting feedback as we head toward alpha, and this helps a good deal. Thanks!

  • Well one has to be careful not to create features for an audience of one. The one person who submits lots of feature requests. While it’s always good to respond to each request, sometimes its best to let requests peculate in an open forum until they have a critical mass and become validated. A critical mass may be a low bar, but it should certainly be above a single person.

    • Totally agree – good point.

    • It’s funny how at first you’re grateful for the extreme enthusiasm of that single user who’s always making requests, but after a while you start resenting having to politely dignify all of their suggestions. What I find to be the pits is when the feature requests that are coming in are all of the checkbox feature items that your competitors have. I didn’t set out to build an exact replica of those products – I started my company because I thought those products suck! You have to fight like hell to find the time / organization to get to the green field features ideas. And it’s a real juggling act to prioritize the user requests against the broader vision of what you want your product to be when it grows up. I find this incredibly challenging.

  • We’re close to an alpha and have 15 to 30 users signup on our splash page each day. A couple times per week, we email each user that’s recently signed up and ask “What do you want that you can’t find anywhere else?” It’s not perfect but we’re trying to find out why they signed up and whatever else they want us to consider. Obviously don’t follow everything that’s suggested but trying to find the dominant patterns.

  • The negative feedback is always the most instructive. The positive feedback generally is rather nebulous and doesn’t illuminate much that isn’t already known (about the value of the product). The negative feedback generally applies not only to that one person who told you about it, but factors of 10s / 100s of others who experienced similar frustration but slipped away without saying anything. What’s frustrating on the free trial side is that generally people who did not like the product enough to buy do NOT share any feedback, and it’s difficult to draw that out of them (they invested the time to check it out to begin with, they decided it wasn’t a fit, and most people are weary of raising their hand and inviting further dialogue, b/c they generally assume a pushy sales call will ensue and they don’t want to be harassed to buy). I think the most valuable possible feedback loop is when it’s just built into the product – being able to see what’s being used, what’s not, where the last page was that someone dropped off at, what their last action was.

  • I hope my answers helps some people in similar situations we’ve had.

    Our B2B solution kind of “glues” three disparate technologies together using SaaS. Route to market is B2B distribution by large utility companies to portfolio clients.

    Qualification – The utilities have to be aware of disruptive changes coming to be even remotely interested in what we offer. For this reason we have found that the first rule of feedback is to qualify the source carefully.
    Getting feedback used to be simple – until we hit the nail on the head we just kept asking potential resellers.
    “What do we need us to do now to make you comfortable taking this to your (often Brand name) clients” ?This was key because they are conservative and extremely risk averse but they knew and we knew that when we got it right it would be a “must have” for some of their clients.
    So there was no hurry just dogged determination. The answer often involved completely re-conceiving deliverables, but there were common themes – “Make it simpler, break it down, reduce the fear, quantify benefit”. This makes for a very modular and maintainable solution over time which will be good for market segmentation.
    We recently got to the stage where we are taking it to our first end-user clients, they seem to want “everything” so we are shifting towards another set of direct questions:

    Please explain your priority for new feature requests to us ?
    – Often there is a misunderstanding of an existing aspect that needs clarity !

    What is stopping adoption ?
    – The industry niche is very new and faces a whole raft of bottlenecks (some can be readily mitigated) – happily price does not figure in this much, but lead time can. This is very very important to understanding the market (especially in different geographies)

    How do you plan to act on outputs ?
    – Clients are suddenly realising they could save a shed-load of energy, hence money but have never thought about where to begin. So they need to be guided along a plausible path (Energy savings are never a core business objective for a company).

    This can lead to up-selling opportunity for us, the utility cos. and third parties, it works best in deregulated utility markets where client retention is an issue.

    What assumptions have we made that don’t fit ?

    It happens and a bit of honest humility helps !

  • Just like you should have a source code repository, you should also have a bug/feature tracking software. I’ll plug Joel Spolsky’s product here. I think that is the key to making sure you don’t build a product for one, as somebody here correctly pointed out.

  • chocolate and or a tshirt is more than enough motivation to get people to “share” their opinion with you.
    The hardest part is reacting or not hearing what you want !
    ex.100 reviews, two people mention a feature YOU want
    – Now you have justification to build the feature
    “Our market research shows that……”

  • Feedback is the breakfast of champions. Ah, you’re speaking my language in so many ways! 

    We take feedback very seriously and act on it. We use UserVoice but email as well of course. We have several features named after our users, including the Brad Feld one (wink), the Fred Wilson one and at least another 10 less famous users. 

    The trick is to know which feature to build and which feedback to ignore or delay. 

    If we didn’t get a feature request, a complaint, or a kudo on a daily basis, I would worry that nobody cares anymore. And that would be a sad thing. 

  • We’ve been super lucky that our users have been very vocal on our uservoice suggesting all kinds of features and product improvements.

    In fact it’s been so successful that we’re going to be merging that into our community because there are so many great discussions going on there we want to aggregate them into one place and make it more discoverable for the rest of our users that haven’t yet click on the “feedback” button.

    So much easier to develop a product when you know exactly what your users are asking for. Now it’s just a question of prioritization and execution.

  • it is an incredibly rewarding when a user gets a response back from his/her feedback. You build an invaluable sense of loyalty and help create a super user class that basically markets your product for you. Make it clear to users where they can leave their feedback – whether it is twitter, FB or a dedicated page.

  • I email every single person who joins our service and give them my phone number in addition to my email address. Roughly 1-3% of our users actually reply.

    1 reply on a topic is data. 2 is a likely trend. 3 comments for the same thing is a clear sign of an unmet need.

    Possibly the most enjoyable part of my job as CEO is feedback – for better or for worse – from these folks.

  • DJ

    One thing StatsMix did was add to our main nav. Their site sells the ability to learn more about customers, but we get the most value from people clicking the Inbox link and asking a question. For some reason people seem to prefer that over the help desk system. We get lots of good feedback — and, sigh, bug reports — through this channel.

    Also, it allows you to broadcast messages to subsets of your user base (or all of them if you want).

  • DJ

    Oh, one other thing we did was implement It shows us application errors that users might never have reported otherwise. Extremely useful, and made by the same folks as Intercom.

  • 1) I have purposefully recruited our current group of alpha users in person (at MeetUps and the like). I email them directly to ask their feedback.

    2) I include each one in a Twitter Follow Friday post, once from my personal Twitter, once from the company Twitter.

    3) We currently use Olark and will move to something more robust when the time is right.

    4) The welcome email comes from me, personally, and includes my cell phone number, email address, Skype ID and Twitter handle (obviously this doesn’t scale, but is valuable right now).

    5) I make a point of knowing what each of our users is working on and what is important to them. I ask how we can support with they’re doing and prop them in public when possible. If I see something that might be useful to a user (like this blog post) I send it to them personally via email. I make introductions that I think will be helpful. I try to network with my early users the way I would with any valuable contact.

    6) We balance all the feedback we get from users with the data we can see. Usually, the data helps us accurately interpret what we’re being told by people.

    Next we’ll be looking at how we can gather more passive feedback using technology such as Crazy Egg and

  • Pingback: Rewarding Those Who Care Enough To Write « Elia Insider()

  • Pingback: cheap auto insurance in new jersey()

  • Pingback: Ringwood()

  • Pingback: Pay Day Advance()

  • Pingback: cheap insurance car()