How (Prezly) features travel from customer to production

'Listen to your customers', 'focus on your clients' problems' – recurring advice you'll recognise from pretty much every startup book on the market. It's solid guidance. And for anyone running a tech company? A persistent challenge.

The problem is that there are so many different information channels, that trying to make sense of them all requires a near inhuman degree of attention, organisation, and consistency. Meanwhile the feedback loop, if neglected for even a short while, disintegrates.

At Prezly, I don't think we're listening to our customers enough.

And because one man's dirty laundry is another's chance to learn how to wash up, I've decided to analyse our current process to try to find ways to close the feedback loop and apply customer insights across all the various parts of our company and product.

Our client feedback toolset

Here is a list of the tools we use when it comes to processing customer feedback:

• Intercom: Live chat and email support
• Slack: Internal team conversations
• Zoom: Calls (both internal and external)
• Notion: Knowledge base
• Vitally: Our customer success CRM
• Productboard: Feature prioritisation and insight processing
• Linear: Project management/delivery

That's quite a few tools and, what's worse, that's not all. Three years ago I wrote a much more detailed post on Reddit about the different tools (and associated costs) we use to run our business.

From conversation to feature

Often the clearest way to depict a process is through a workflow diagram, so that's where I started my dissection.

The yellow section on the left shows all the different sources through which we receive feedback. It could be something a customer complains about on our live chat, a suggestion from a team member in Slack, a customer call, and so on.

In addition to these more continuous insight streams, we also have an archive of notes logged in our customer success CRM (Vitally), and a small database of user research notes that we logged several months ago as part of interviews aimed at solving a positioning challenge.

Processing feature feedback

We try to store all feature-related feedback as notes in Productboard. Those notes are then processed by someone from product, usually either myself or a member of the design team. Every note can include multiple feature ideas, as Productboard lets you highlight different sections of a single note and associate each to a particular feature or feature idea.

Here is an example of a processed note where one insight (a user interview) resulted in three different features ideas.

Organising feature ideas

All those different feature ideas are organized in a huge feature tree that can span different product areas and components. This helps keep things organised and easy to find.

All features automatically get assigned a 'user impact score' based on how you scored the importance of that feature in the initial note. You can also fill in the 'effort score' (i.e. how hard a feature is to build) and stack this against multiple user impact scores (how important it is for your customers) to generate an overall 'prioritization score', which can be very useful for deciding which features to work on when.

These numbers (together with a lot of other meta data) can then be used to slice and dice your feature tree, sort them by importance, and kick off development. That's the idea, at least. Some examples of slicing/dicing/viewing that data:

In reality, I find that we use Productboard much like a filing cabinet that we dip into from time to time when we suddenly remember to do some research.

Turning insights into Specifications/Planning

We have been using Basecamp's Shape-Up method for over a year now at our company, and it has served us well. I recommend having a look for yourself, but long story short, it allows anyone in the wider team to pitch product ideas.

Ideally, those product ideas come out of speaking with customers, using the product for yourself, seeing what a competitor is doing, noticing an evolution in technology, or going through logged customer insights. In actuality, most pitches are the result of a more direct thinking process: 'This would be cool to build, so we should build it!'

To tackle some of this problem, we encourage people to sprinkle their project pitches with insights/feature requests from Productboard. This is particularly relevant to the problem statement part of the pitch, which is best seen through the words of a customer (i.e. Productboard insights).

Often, multiple different feature ideas/insights can be combined into a single pitch. For example, when we decided that we were going to explore automatic story translation (at the time of writing, a work in progress), it was through a combination of 14 insights on various features:

• Feature: Google Translate Integration (6 insights)
• Feature: Make translator accounts free (1 insight)
• Feature: AI-powered translations (4 insights)

If a feature is small enough and easy to build, we will skip the Shape-Up pitching process and plan the work straight in our task management tool, Linear, where the CARE team can pick it up as and when they are able (the CARE team consists of developers and designers not currently assigned to an active project).

Picking which projects to build

I could (and perhaps should) dedicate an entire post on the complexity of the betting session. In our Shape-Up FAQ we try to answer the question for the team

Reading this now I feel that this is missing some specifics. Here are all the things that go into betting:

• What are the most important problems?
• Team allocation/holiday?
• Is this project something 'exciting' we can do marketing with?
• How long has this problem been lying around?
• Is there any time-pressure to pick this project now?

We've recently opened the betting sessions from a 2-person co-founder meeting, to a 4-person recorded betting session. That recording is then shared with the team and notes are shared with the authors of pitches that were discussed during that betting session.

The development stage

This could be a blog post all of itself, but to keep things brief: we use Linear to organise our work. We have different teams in product and every picked Shape-Up project gets its own project in Linear.

With a few exceptions, we prefer short projects usually spanning a two-week cycle. During the execution of the project, the team assigned to it writes regular updates that are automatically shared in the relevant Slack channels.

As a rule of thumb, we break projects into separate components that are deployed whenever the team feels there is enough value for our customers. A six-week project, for instance, will ideally have multiple different components going live throughout its timeline.

For features that we're less certain about, we use feature flags to enable their functionality for a subset of customers and see how things progress. If we want more eyes on a feature, we promote it to the 'feature labs' part of our tool so that clients can enable and test it for themselves.

Informing customers

Every time I speak to a customer, I am surprised how little they are aware of our new features. Although we try with our monthly newsletter, a public changelog, an in-app changelog, and a 'what's new' section on the login page, it's clear that we still have a long way to go when it comes to informing our customers about our new features.

Part of this is remembering that people in general feel themselves time-poor, and are unlikely to seek out information – or even open a company newsletter – unless they're really invested in what's going on. It's something we're working on.

When it comes to launching a new feature or an update, it makes sense to contact directly our most relevant audience – i.e. the people who requested that feature in the first place. This is where Productboard again comes in very useful, since it's easy to see any insights linked to a feature request and create a mailing list accordingly.

So we reach out to those people, tell (or better, show) them the new feature, and ask them to try it out and let us know what they think. This is incredibly useful in helping us understand whether we've correctly identified a common customer problem and presented an adequate solution – something that is great after the fact and indispensable during smaller rollouts along the longer six-week project timelines.

On paper, it reads like a solid plan, but even as I write this I'm painfully aware that speaking with customers is the weakest link in our entire feedback flow. Specifically as we're currently struggling with positioning and the question 'what makes Prezly different vs..?' I think that the our the answers are in deeper/better conversations with our customers which we simply don't do it enough.

The challenges

As mentioned in the introduction, I feel that we aren't learning enough from our interactions with customers. It became even more obvious when my colleague Kate started this conversation in our internal Discourse:

I think that a lot of the interactions we have with our customers are one-directional. For example, we invite customers for a user research session mostly because we want to learn what to build. That sounds logical, but it isn't how relationships work.

At no point do we deliberately try to build a partnership where we listen to their challenges, try to come up with the best possible solution, and then return to them to validate and/or iterate.

And there began the idea for this blog post.

Going forward, I want to rethink our process with new requirements:

• Work on the most important problems that our customers face (assuming they fit our mission)
• Always inform customers when we build something they asked for
• Make it easy for anyone to follow up on what happened with their feedback
• Turn insight discussions/debates into company-wide conversations (for people that want to participate)
• Better spot recurring problems and work on those
• Make insights an important input of planned work (context for developers and designers)

With that in mind, I'm going to play around with the Productboard integrations, research what techniques and tools are out there to help us take this to the next level, and share my findings here. My hope is that this approach will help me organise my thoughts as well as bring you into the conversation, and as a byproduct, maybe even save other founders some of this pain.

As always, any advice or experience you want to share – I'm all ears.

Gijs