How Public Product Roadmap Help Us to Understand Our Users

To what extent do you allow your users and customers guide your development process? This is a question we have grappled with over the last year and, frankly, continue to debate passionately at our morning pow wow. But, today is the first time we have shipped a purely user-requested feature and it feels like a significant milestone.

For context, the requested feature allows you to start customising the appearance of DID.app’s sign in pages to ensure your authentication aligns with your brand. Here’s the feature request on our roadmap. And here’s the output in our docs].

This is a significant moment for a couple of reasons, first off, we allowed ourselves to be guided completely by our users. We probably wouldn’t have come up with this feature because we, like doting parents, believed our creation was perfect and beautiful and perfect and even more beautiful snookums, kissy kissy, oochycooo cockapoo.

And of course, we are right. Right? Actually our users helped us to see something we couldn’t see and prioritise a feature that had real value to the amazing people actually using our product.

Left to our own devices we would probably be releasing a more technical feature, such as WebAuthN integration (also on our roadmap). This will undoubtedly be an exciting feature for our audience but it would have been at the expense of what was most pressing to our users at the time. Unless you have ten dev ops on the team one simply has to prioritise one feature in front of another.

The second reason I believe this is significant is that it can be hard to ensure your vision really resonates with your audience and achieves what you set out to achieve when you’re also trying to sell it to people.

A typical prospect chat goes something like this:

Prospect: “Well sure we’d love to give your product a go and pay for it but really we need it to do X first.”

Product founder: “Sure, we can do that. Give us a week and we’ll have it ready!” - barely concealed undertones of excitement at the prospect of acquiring paying customer.

Prospect: “Splendid. Speak again in a week’s time.”

Product founder: “OK!” - hangs up. Realisation that they’ve just committed themselves to developing a niche feature that is only relevant to this one user, will take a full week of development time up and stop us from developing everything else on our roadmap.

In this scenario, your vision risks being put on hold.

Then the question arises, is your vision resonating with your audience? Do your users want what you’re making?

This one is really hard to answer. A week spent now developing a niche feature to win 1 customer might prevent you from developing a more widely adoptable feature that helps you win 10 more customers in a month’s time. This is more commonly known as ‘opportunity cost’.

I think the lesson learned from publishing our roadmap is that listening to your users at volume is the number one thing any product development team should be doing. Every user you speak to has a different opinion, a different feature idea and a different view on life but they are probably all united behind your vision to ‘change the world’.

The greater number of conversations you have, the more you can see if certain features (or variants of) are discussed. There comes a point where a feature request reaches something akin to statistical significance if you will. If this is the case and it aligns with the vision it's a perfect fit for you.

In our case, our vision is to deliver passwordless authentication on equal terms to websites and end-users in a way that respects privacy. Users requesting features like WebAuthN integration, custom styling or a Netlify guide fit well with the overall vision and these are specific requests that enable us and the user to more easily fulfill their requirements.

Something like a feature to add password auth as a fallback is completely at odds with the vision and doesn't feel right at all, even if it does mean 1 customer might come on board if we offered that feature.

Defend your vision. It’s the reason you get up in the morning and the reason you’re loyal tribe of users support you. If a feature request comes in from a new prospect that doesn’t align with your vision then think very carefully about whether the business relationship is a good fit for you.

If the feature request aligns with your vision and is just another small step along the road to the goal then go for it. Your product exists for your users.

One feature I really like about the roadmap is that users can upvote features. This seems the simplest and fairest way of putting feature development into some kind of order.

And now, our developing days are guided exclusively by our public roadmap. If it’s on the roadmap, we’re doing it. We’re excited by the way users engage with the roadmap by leaving comments and ideas. It’s really helping users get on board with our journey to achieving the vision we’re all behind and I am delighted that we have been able to take a purely user requested feature from suggestion to production now for the first time.

The first of many I am sure.

I’d love to know your thoughts on publishing public product roadmaps. If you do already, has it worked for you? If you don’t publish a roadmap is there a reason why and what is that reason?

Previously published at https://dev.to/richardlikestea/what-we-learned-from-publishing-a-public-roadmap-and-listening-to-users-ke9/edit