{"id":147,"date":"2017-08-20T15:30:40","date_gmt":"2017-08-20T19:30:40","guid":{"rendered":"http:\/\/54.158.119.27\/?p=147"},"modified":"2026-03-10T02:12:34","modified_gmt":"2026-03-10T06:12:34","slug":"debunking-concerns-public-roadmap","status":"publish","type":"post","link":"https:\/\/canny.io\/blog\/debunking-concerns-public-roadmap\/","title":{"rendered":"Debunking concerns around having a public roadmap"},"content":{"rendered":"
\n
\n

Public roadmaps have become more popular over the past couple years, for good reason.\u00a0Founders have written<\/a>\u00a0about why they have a public roadmap. The main reasons being that:<\/p>\n<\/div>\n<\/div>\n

\n
\n
    \n
  1. Your users will love you for it<\/li>\n
  2. You will improve your product with user feedback<\/li>\n
  3. You will keep your team accountable<\/li>\n<\/ol>\n<\/div>\n<\/div>\n
    \n
    \n

    Making your roadmap public is a\u00a0bold<\/strong>\u00a0way for your team to say:<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    Hello lovely users, your voice is so important to us. Here\u2019s what\u2019s coming up in AwesomeApp. Let us know what you\u00a0think!<\/p><\/blockquote>\n<\/div>\n<\/div>\n

    \n
    \n

    A real win-win-win.<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    Given the above benefits, we still hear some concerns that we\u2019d like to debunk. Here are the most common concerns we hear:<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    My competition will see what I\u2019m working\u00a0on<\/h2>\n<\/div>\n<\/div>\n
    <\/div>\n
    \n
    \n

    Yes, being transparent means that anyone, including competition, can see what you\u2019re working on. Countless founders have\u00a0written about<\/a>\u00a0how they worried too much about competition in the early days. Their conclusion: focusing on the competition is a distraction! Stay focused on executing your roadmap to the best of your ability and let your competition worry about you.<\/p>\n\"Jeff\n<\/div>\n<\/div>\n

    \n
    \n

    If your product is in beta, great! Be transparent about your roadmap from the start. Showing that you care about user feedback builds trust\u200a\u2014\u200athe foundation of all strong relationships.<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    Buffer, champions of transparency, see the advantage of building in the open: \u201cWe think this could raise the bar for all of us, and challenge Buffer to build the best, most valuable features possible.\u201d<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    As Sam Altman says, very few startups die from competition. Most die because they fail to make something users love. And let\u2019s be real, there are several other ways your competition could find out what you\u2019re working on.<\/p>\n<\/div>\n<\/div>\n

    \n
    \n

    We don\u2019t want to tell users we can\u2019t build something they\u00a0want<\/h2>\n<\/div>\n<\/div>\n
    \n
    \n

    The more you can engage your users in your product development, the better. Feedback allows you to be more confident in your decision making. Yes, your users will request features. Here are the two ways this pans out:\u00a0<\/span><\/p>\n<\/div>\n<\/div>\n

    \n
    \n
      \n
    1. You agree with the request and add it to the roadmap. Users keep you accountable to execute. Everyone\u2019s happy.<\/li>\n
    2. You disagree. Maybe it\u2019s not a part of your team\u2019s vision, or a\u00a0slew of other reasons<\/a>. Saying\u00a0\u201cno, and here\u2019s why\u201d<\/a>\u00a0is infinitely better than silence. Your users are people, they\u2019ll understand and appreciate the transparency.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n
      \n
      \n

      There will be times when something is highly requested but doesn\u2019t fit the bill. Great product teams have\u00a0established processes\u00a0to determine what gets prioritized, and what doesn\u2019t. Product development isn\u2019t a democracy!<\/p>\n<\/div>\n<\/div>\n

      \n
      \n

      The feedback will be biased to a small, vocal\u00a0minority<\/h2>\n<\/div>\n<\/div>\n
      \n
      \n

      Public roadmaps are a great way to get:<\/p>\n<\/div>\n<\/div>\n

      \n
      \n
        \n
      1. A pulse on demand of features in the pipeline<\/li>\n
      2. Feedback on how a feature should be implemented<\/li>\n<\/ol>\n<\/div>\n<\/div>\n
        \n
        \n

        You can expect around 1% of your users to voice their feedback on your roadmap. Bias is a problem and can be harmful if not weighed against other sources of feedback.<\/p>\n<\/div>\n<\/div>\n

        \"Users<\/div>\n
        \n
        \n

        Lower the risk of bias by getting feedback from a variety of sources such as a select group of users, your internal team, and quantitative data. Slack\u2019s first PM, Kenneth Berger,\u00a0talks about<\/a>\u00a0the whole range of biases that can occur in product feedback and how to interpret all the data.<\/p>\n<\/div>\n<\/div>\n

        \n
        \n

        A public roadmap is one method of soliciting feedback. There are\u00a0several other methods<\/a>\u00a0that will all give you different signals. Building the wrong thing means costing your team time and effort. The more signals you have, the more informed you\u2019ll be in building your roadmap<\/a>.<\/p>\n<\/div>\n<\/div>\n

        \n
        \n

        We \u2764\ufe0f having a public roadmap<\/h2>\n<\/div>\n<\/div>\n
        \n
        \n

        As users, it feels great to have a say in the products we love using. But often our best efforts to give feedback are met with dead-end, canned, responses. Public roadmaps are a great way to build a brand around transparency while getting valuable feedback in return.<\/p>\n<\/div>\n<\/div>\n

        \n
        \n

        The boldness of putting your roadmap in the public brings advantages that far outweigh any of the above concerns.<\/p>\n<\/div>\n<\/div>\n

        \n
        \n

        Here are some examples of public roadmaps<\/a> we love.<\/p>\n<\/div>\n<\/div>\n

        \n
        <\/div>\n<\/div>\n
        \n
        \n<\/div>\n<\/div>\n

        \"New<\/a><\/span>