For many Product Owners and Managers, there’s an important choice that must be made:

Do we listen to our customers or do we keep control of where the product goes?

This choice is a false one, as it relies on an assumption that is simply not true.

The reason Product people see this as a choice that must be made is because they believe that listening to customers means giving away control of the product.

Fortunately, that’s not the case at all. You can listen to your customers AND retain control of your product with a few simple tweaks to your current feedback process.

1. Create a Product Feedback Policy

A Product Feedback Policy (PFP) is a simple document that helps to set expectations from day one. The PFP sets out your feedback process so that customers who provide you with feedback understand how it will be used.

The important part for the context of this article, however, is that it explains that sometimes you’re going to say ‘no’ to your customers’ requests. If your customers can easily access your PFP, then you can safely assume they’ve read it, and even if they haven’t you’ve done all you can to set expectations.

When the time comes that you have to turn down a request, your customer won’t be as angry because you warned them up front that you may say no.

If you don’t yet have a PFP, then I recommend writing one. It doesn’t take long at all and is an invaluable document to have at your disposal.

You can find a template and example here.

2. Balance Strategy and Demand

Essentially, most product decisions come down to strategy or demand — either your product strategy tells you what to work on, or your users do.

But you don’t have to choose one or the other and then just stick to that choice. You can, and should, attempt to balance both sides of the equation.

For example, let’s imagine that your strategy tells you that you should be working on improving your UX for the next few months. Now, you might already have an idea of what you need to do to improve your UX and so you could simply knuckle down and get on with it.

However, your users probably know what they want from the UX more than you do. So an alternative would be to go and collect some extra feedback specifically about the UX improvements. This way you can be sure you’re building the right thing, but still end up building the improvements you originally wanted to make.

This kind of compromise enables you to listen to your customers and still keep control of the direction you take your product in.

3. Say ‘No’

Listening to your customers simply means paying attention to what they have to say. It doesn’t mean agreeing to build every single thing they ask for.

A lot of SaaS companies find it difficult to say ‘no’ to their customers. They don’t want to upset or anger them, they don’t want to seem like they aren’t really paying attention.

This can often result in companies choosing to ignore feedback altogether. They bury their heads in the sand and hope it goes away.

Actually, though, saying ‘no’ isn’t really that difficult, especially if you’ve set expectations with your PFP.

The key to saying ‘no’ to your customers is to be upfront and honest with them. If you simply say ‘no’ and leave it at that, then yeah, they probably will get pretty angry. If, however, you explain why you aren’t building what they want, then at least they have a reason. Even the most demanding customers would find it hard to stay angry with you.

Plus, make it clear that when you say ‘no’ you might be meaning ‘not right now’. If you think that their idea is something you might return back to, then explaining that can go a long way to helping foster understanding and acceptance.

Conclusions

You don’t have to choose between listening to your customers and retaining control of your product. It’s possible to do both of those things at once.

There are three main steps you can introduce into your existing feedback process to ensure that you take your customers’ feedback on board while simultaneously deciding which direction you take your product.

You need to set expectations with a PFP so that customers understand the process. You need to use your product strategy to decide on direction, but also use feedback to enhance what you’re planning to build next. And finally, you need to learn how to say ‘no’, by being open and transparent when you communicate with customers.

Doing all of the above will enable you to make the product decisions you want to make plus provide you with the useful insights that come from customer feedback.

It’s a win-win.

Receptive helps you to balance customer demand with your product strategy. Why not get started today?

How to Listen to Your Customers Without Giving Away Control was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

B2B SaaS companies pride themselves on constantly releasing new features and product improvements, but a lot of them fall flat when it comes to marketing those new releases.

It’s a shame, because a new release should be a cause for celebration. Obviously I’m not saying that every little improvement deserves a song and dance routine, but for the bigger projects, it’s an opportunity to show off what you’ve done.

Now, the traditional ways of marketing your product, like blog posts, social media, videos, etc., are all well and good, but there’s actually something else that you need to think about, and it’s a pretty underrated aspect of product marketing.

The secret ingredient for perfect product marketing is to involve your customers from day one.

I’m sure you, like pretty much every other person on the planet, watch a movie from start to finish. The pay-off at the end of the movie exists because you were there for the set-up at the start.

When you write a blog post to announce a new feature, you’re effectively showing your customers the end of the movie, without them ever seeing the start.

It’s all pay-off, and no set-up, and so it’s no wonder your customers don’t jump up and give you a standing ovation.

Letting your customers be there from start to finish and involving them in the whole process of building your product is the best way to have them engaged with your product marketing.

You should start by setting expectations. Tell your customers about your feedback process, and what happens when they submit a request.

A Product Feedback Policy is a fantastic way of doing this. You can learn all about PFPs (including a handy template) here.

This way, your customers understand what happens when they submit feedback — in other words, this is the beginning of the movie.

So next comes the middle of the movie. For the purposes of this long, drawn-out analogy, the middle of the movie is the part where you build your product.

It’s important that you involve your customers at this point as well. Before you get to work building those new features and improvements, you should do some research.

Your idea of an improved reporting feature, for example, may differ greatly from what your customers want from an improved reporting feature.

If you don’t include their opinions, then not only are you missing out on some fantastic insights, but you’re also not involving your customers — and if they can’t watch the middle of the movie, they probably won’t carry on to the end.

Which brings us to the climax of the movie, where you’ve finished building those new improvements, and you’re ready to share them with the world.

Well, just hold on a second.

Why not involve your customers one last time and invite them to beta test your new feature?

That way you’ll gather some crucial insights about whether your new feature is ready to be released. Plus, it means your customers are involved once again.

Which brings us nicely to your big release. It’s time to celebrate and now, because you involved them throughout, your customers are celebrating with you.

They’ve been able to play a part in the development of your product, and now their lives are easier because of the new feature you’ve released.

They’ll acknowledge the work you put in to make this happen, because they saw it first-hand. They’ll be more likely to help you out again in future. They may even give you a standing ovation.

Involving your customers from day one is the secret ingredient when it comes to marketing your product, and all it takes is little bit more effort to communicate with them.

Receptive automatically communicates product updates to your customers, saving you hours of manual work. Get started today.

The Secret Ingredient For Perfect Product Marketing was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can’t please everyone all of the time, or so the old saying goes.

Yet when it comes to their products, SaaS companies can’t help but try. This leads to a disjointed product, a Frankenstein’s monster that scares everyone away.

Fortunately, there’s a fairly simple solution that enables you to feed your hunger for keeping everyone happy, AND doesn’t lead to a mish-mashed product.

The key is to align your teams around your product.

What Does that Mean?

When I talk about alignment, I’m talking about making sure everyone knows where the product is heading, and why it’s heading there. I’m talking about ensuring that every team member is on board with the decisions you make, even if they personally disagree.

This is massively important if you want your product to be successful. Your Product team needs to believe in what they’re building, your Marketing team needs to love the product so they can market it effectively, your Sales team needs to be enthusiastic about what they’re selling.

The success of your product, of your business, depends on getting your teams aligned.

How to Align your Teams

So, how exactly do you align your teams? How do you make sure every team member is on board with your product’s direction?

There are two main things you have to do. You have to listen to them, and you have to talk to them. If that sounds startlingly simple, that’s because it is.

But just because something is simple to think about, doesn’t mean it’s easy to execute. If it was easy everybody would be doing it and there’d be no need for this article.

Listen to your Teams

How often do you listen to what your team members think about your product?

If you’re like a lot of SaaS companies, then probably not very often. This is bad for two reasons.

Firstly, it means you’re missing out on a lot of great ideas. Your team members know your product inside-out, and so they can often have a unique perspective on what works and what doesn’t.

Secondly, it makes them feel like their opinions aren’t valued, and in turn that makes them distance themselves from the product — which doesn’t particularly help when it comes to alignment.

In order to listen to your team members, you need to set up an appropriate channel for their feedback, and you need to encourage them to give it.

In terms of an appropriate channel, this could be as simple as a dedicated email address or shared doc, or something more professional like Receptive, depending on the size and structure of your company. As long as it’s easily accessible, and organized well, then you’re good to go.

You should encourage team members to provide feedback by regularly asking them for it. Make sure your team leaders are constantly checking in with their teams to get an idea of what they think about the product. If you think it will help, then providing incentives could always work, though may lessen the quality of the feedback you receive.

Listening to your team members is a great first step. It involves them in product decisions, so even if their ideas aren’t chosen, they’ve had the chance to have a say.

Talk to your Teams

I hinted at this in the last section, but it’s an oft-overlooked aspect of aligning your teams around your product.

Listening to your team members is a fantastic way of involving them with your product, but if you aren’t also talking back to them, then it’s a one-way conversation that benefits nobody.

If you simply listen to your team members without any reply, then how do they know you’re really listening? They’ll feel like they’re talking to a brick wall.

When you receive feedback from team members, make sure to thank them for it, and explain that you’ll review it at a later date.

Keep them updated throughout. If you aren’t going to go ahead with their idea, let them know and explain why. That explanation is crucial in helping them come to terms with your decision and aligning themselves with it.

In fact, explaining is the best thing you can do. Whenever you make a product decision, spend an extra bit of time to offer an explanation as to why you made that decision. If your team members can understand your reasoning, then they’ll more readily align themselves with the product, even if they disagreed.

Talking to your teams, and explaining major product decisions, goes a long way when it comes to team alignment.

Summary

To summarize, you need to align your teams round your product so they can all do their jobs as effectively and passionately as possible.

You can do this by listening to your team members — taking on any feedback, involving them in product discussions — and by talking to them — explaining any decisions you make.

Showing team members the respect they deserve, and involving them in the future of your product, ensure they’re all aligned and prepared for the future.

Receptive helps leading SaaS companies to build better products. We can help you too. Why not get started today?

How to Align Every Team Around your SaaS Product was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

If 2018 was the year of the Product Manager, then it looks like 2019 will be the year that the Customer Success Manager steals the limelight.

Customer Success has grown in stature over the past couple of years. It’s a job title that used to be met with “Huh?” but is now a mainstay in software companies, and perhaps even further afield.

As SaaS becomes the default model for services sold over the internet, companies are tasked with ensuring their customers stick around for the long-term. CS was born out of the need to reduce churn.

CS lies somewhere between Sales and Support, in that they help the customer make the most out of the product, while simultaneously identifying scope for upgrades and changing plans.

Whether or not you’re actually looking for a career in CS, there are some key qualities that a CSM possesses that will serve you well at any position in a SaaS company, from Sales to Product to Leadership.

So let’s get started…

Listen Up

Perhaps the biggest skill that a CSM has is their ability to listen. In fact, their job relies on it. They have to understand what their customers are trying to achieve, what does and doesn’t work for them, and then figure out how best to help them.

If they don’t listen properly, they’ll find it almost impossible to provide genuine advice. Not only that but they might miss crucial details and the more subtle problems that their customers are facing.

Listening is one of those skills that everyone thinks they have, but in reality they generally don’t. Listening properly means actually thinking about what the person is saying to you, rather than trying to figure out what you’ll say next, or look for some sort of agenda.

When you speak to a customer, you should pay attention to what they’re saying. Don’t just dismiss them as they might genuinely have something useful to tell you. No matter what your role involves, listening is an extremely important skill, and one you should think about developing if you haven’t already.

Be Proactive

Prevention is always better than the cure, as they say, and churn is no different. Preventing a customer from ever even considering churning is far more effective than combating it once the decision has been made.

If they want to prevent churn long before it’s an option, CSMs must be extremely proactive. They can’t simply sit and wait for an issue to arise because it might be far too late by then. Instead, they have to keep on top of their customers and be aware of any developments as and when they happen.

The reason a lot of people shy away from being proactive is because it means you have to put the work in. It’s far easier to sit back, do the bare minimum, and hope that nothing too important comes up.

To be proactive, you need to be alert and on the lookout for things that could potentially go wrong. Much like when you’re driving, and you constantly keep an eye out for hazards, you need to have your wits about you and make sure you can react quickly to anything that might cause a bigger issue in future.

Being proactive helps you with any role or task that you’re assigned to. Rather than waiting for something to go wrong and then having to work non-stop to fix it, you can make sure you nip any problem in the bud right away.

Communicate Clearly

I’ve already explained the importance of being a good listener when you’re a CSM. In much the same vein, it’s also crucial that you can communicate clearly. A conversation is a two-way thing, and you need to master both parts to ensure your customers are successful.

Speaking to customers is an art in itself. They may be angry and so you need to placate them. You need to be professional with them, but not so formal it’s off-putting. It’s a fine balance, and to be successful you need to be able to clearly explain what you mean, and speak in a language they understand.

In order to communicate well, you need to know exactly what you’re trying to say, and explain it in the simplest way you can (without being condescending, of course). Avoid using jargon or unnecessary acronyms unless they’re words and phrases you know your customers will understand.

This is a really useful skill for all roles, but especially people in customer-facing roles like Sales and Support, as well as those tasked with writing marketing materials.

Empathize

Any role that involves dealing with customers is going to require a degree of empathy. You have to be able to put yourself in their shoes if you want to communicate with them and make sure they’re successful and willing to carry on using your product.

Seeing things from their point of view is essential to understanding the issues they face and knowing what they’re trying to achieve with your product.

There’s no easy way to do this, but it can help people in all roles of your company. Marketing, for example, can better explain the benefits of your product if they can empathize with your customers. Product can design new features in a way that customers can use. Everyone benefits from empathy.

The Road to Success

Running a SaaS business successfully largely depends on your ability to retain your customers and prevent churn. While this is primarily the responsibility of the CS team, it should fall upon the whole organization.

With that in mind, adopting some of the traits and characteristics that make CSMs so good at their job will help those working in other roles as well.

I predict that these elements of Customer Success will bleed into all aspects of SaaS in due time, so taking them on board now will place you ahead of the curve.

Receptive helps leading SaaS businesses to manage their product feedback. Why not get started today with a free trial?

How to Think Like a Customer Success Manager was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s set the scene… It’s 2019, and your SaaS company has big dreams and aspirations for growth. You’re pretty switched on and clued up and so you realize that one of the key factors for growth is tapping into all that product feedback you’ve been collecting.

Now you’re probably faced with a pretty important question: Who, exactly, is going to manage this feedback?

Your first instinct is likely to put a Product Manager, Owner, or maybe even the Head of Product, in charge. After all, your Product team are the ones that need to use this feedback, so it makes sense to have them owning it.

However, there is an alternative that might be far better suited to the tasks involved with managing product feedback: A Customer Success Manager.

There are several reasons why a Customer Success Manager is the perfect person to manage product feedback…

They Know your Customers

Your CSMs know your customers better than anyone. Each customer has their own ideas of what they want from your product, and a CSM understands the context around those ideas.

This is really important because a lot of feedback often goes ignored when the Product team doesn’t really understand why a customer wants something. It doesn’t have the context.

A CSM, however, will already have a grasp on the context and so they can focus on the actual feedback and the bits that matter most. They’ll understand what your customer is trying to achieve, and so when they ask for something, they know how that request will help them achieve it.

This leads to a better idea of what your customers are asking for, and provides detail for your Product team to work with.

Your Customers Know Them

This already existing relationship also works the other way. In the same way your CSMs know your customers better, your customers know them.

When it comes to providing feedback, your customers will be far more forthcoming with information if they can speak to somebody they’re already familiar with.

Chances are, they haven’t ever spoken to a Product manager from your company, and so it can be a little awkward for them.

In the event you need to follow up on feedback requests, a CSM is far more likely to be given the information they need, and the customer will enjoy the interaction far more.

How to Pass Responsibility to your Success Team

So, now that we’ve established that CSMs make great feedback managers, I want to explain how you can ensure that managing feedback becomes their responsibility.

The first thing you need to do is make everyone aware, including your customers, that your Success team is going to own the feedback process.

You can send out an internal email to staff, and you can let your customers know by updating your Product Feedback Policy, or by creating one if you haven’t already got one.

Here’s a handy template that walks you through creating a Product Feedback Policy.

The other important thing you need to consider is that it’s ultimately your Product team who need access to the feedback so they can use it to inform what they build.

Sometimes the Product team doesn’t like the idea of taking feedback on-board, and this can lead to a strained relationship with Success.

However, if you take the time to get everyone on the same page, with a shared understanding of the benefits of feedback, and find out what will help your Product team the most, then you’ll find that Product and Success can work perfectly well together.

Final Thoughts

Essentially, the important part of feedback is that you actually take the time to listen to it and use it to guide your thinking. As long as somebody is taking charge, then you’ll be able to make the most of the feedback you collect.

That being said, it makes sense to put the right people in charge of managing feedback so that you get as much use out of it as possible.

Your CSMs already know your customers, and your customer know them, and so they’re the best choice for the job.

Then it’s just a case of making sure everyone knows that Success are owning that side of things.

Receptive helps leading SaaS businesses to manage their product feedback. Why not get started today with a free trial?

Why Customer Success Managers Make Great Product Feedback Managers was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ah, the product backlog. Two simple words that send shivers down every PM’s spine.

For those not yet privy to the horrors of the product backlog, it’s essentially a long to-do list of product requirements — a mixture of customer requests, team demands, and strategic ideas.

The reason it’s so maligned by Product teams is that every time you complete something on the list, it seems like three new things crop up. Any progress is countered by new items. The backlog grows and grows.

Eventually, it becomes unmanageable and left largely ignored. Occasionally, a brave PM may take a peek, if they dare, but ultimately the backlog becomes a compost heap of feedback.

There are countless articles about how to reduce the size of your product backlog, how to take an agile approach to your backlog, how to prioritize it. But all of these miss the glaring elephant in the room:

A product backlog is not a productive or effective way of building a product.

In fact, a product backlog isn’t very useful in any way, whatsoever. Instead it’s just something that PMs like to moan about.

But, with a simple tweak to how we think about backlogs, by reframing them in a slightly different way, we can turn the jumbled mess into something beautiful, something useful.

We can turn a product backlog into a feedback library.

A library has a few amazing qualities that make it really useful, and when you apply those qualities to your product backlog, it changes the whole dynamic.

1: It’s Packed

Firstly, a library is stuffed full of books. I mean, there’s a lot. Obviously this partly depends on the size of your library, but even the smallest ones have shelves the height of two people, packed full of books.

Generally, this means that if there’s something you need to know, you can probably find a book about it somewhere.

If you replace ‘books’ with ‘feedback’, then the library begins to look more like a product backlog, only now that overwhelming mass of data is actually useful.

You don’t go to the library and plan to read every single book. Therefore, you shouldn’t go to your backlog and plan to build every single request.

Instead, think about what information you need, use your product strategy to guide you, and then find the relevant data in your feedback library.

2: It’s Organized

Pretty much every library organizes their books in some way. Most use the Dewey Decimal System. This is a way of grouping books based on some main classes, and then sub-categories of those classes.

The beauty of this is that I can go into a library wanting to find a book about customer feedback for SaaS companies (something like this) and easily navigate to the right shelf.

If the library wasn’t organized in this way, then finding the right books would be a nightmare.

In the same way, if your product backlog is all jumbled, then how can you ever hope to find what you’re looking for? You can’t, and so you probably won’t bother.

By making sure your backlog is organized, perhaps by product area, features, or use cases, all you have to do is navigate to the most relevant data.

3: It’s Free

Far and away the best thing about libraries is that they’re free, or at least, mostly free.

Once you’re a member you can just rock up, pick up a book or two, and leave. You don’t have to pay a single thing. Sure, you might have to pay late fees if you don’t return them, but if you follow the rules then you’re fine.

If you read a lot, you can save a lot of money by borrowing from a library instead of buying books to leave sitting on your shelf at home.

Much like a library, your product backlog is also free. Your customers, team members, and prospects are giving you all of this information for free, simply because they want to help.

All of the data that you’re moaning about and ignoring didn’t cost anything. If that’s not a reason you should be grateful and start using it more, then I don’t know what is.

Building Your Feedback Library

So, now that you understand why a product backlog is an awful way of looking at things, it’s time for you to build your feedback library.

Chances are, you’re reading this because you have a massive product backlog already. That’s great news, because it’s really easy to turn it into a feedback library.

You just have to encourage your users to submit feedback, make sure you organize your feedback in a way that makes sense to your Product team, and then, well, that’s it. That’s all you need to do.

The main thing that transforms a miserable product backlog into a joyous feedback library is your mindset.

Don’t see it as a long list of things you need to work through, see it as a goldmine of information that you can dip in and out of whenever you need to.

Plus, if you’re in charge of the backlog, you can now change your job title to “Product Librarian”, and that sounds much cooler.

Receptive helps you to gather customer, team, and prospect demand, enabling you to make better product decisions. Get started today!

We Need to Rethink the Product Backlog was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your roadmap is one of the most important things you’ll produce as a SaaS company. It provides a glimpse into the future of your product and aligns everyone around the same goals.

But it can also prompt a lot of questions that need answering, and discussions that have to take place.

How much detail should you go into? Should you commit to specific dates and timeframes? Who will you share the roadmap with: Just employees, or customers too?

And then there’s perhaps the biggest question of all:

“How do we decide what makes it on to our roadmap?”

I wrote this guide to answer all of those questions, and tell you everything you need to know about roadmapping at a SaaS company.

This is based on research we’ve conducted, conversations we’ve had with other SaaS companies, and our own experiences.

I’m going to assume no knowledge on your part whatsoever, so if you feel like I’m stating the obvious at times, feel free to skip ahead to the bits most relevant to you.

The Basics

Put simply, a roadmap is a living document that shows how you plan to develop your product.

The most common form is a graphical roadmap (see below) that essentially forms a timeline of new features and improvements that you’ll roll out in the future.

I call it a living document because it should always be updated with the most recent information. It’s safe to say that in the SaaS world, plans change. They change a lot. And your roadmap should change with them.

The reason a roadmap is so useful is that it provides a clear picture of where you’re heading, much like an actual map.

Much like you wouldn’t attempt to trek through the Amazon without a map, you shouldn’t attempt to navigate through the rainforests of SaaS without consulting your roadmap.

Who Should See the Roadmap?

This is a common question we get asked at Receptive, and the answer isn’t always obvious, and it isn’t always the same for each company.

Our roadmapping feature lets you choose how visible your roadmap is. You can keep it so only your employees see it, make it visible to customers, or simply set it to public and allow anyone to see it.

Each of these options have their pros and cons, and the right one for you depends on your values and stance as a company.

For what it’s worth, we conducted some research into this topic and we found that 33% of SaaS companies we surveyed reported that the whole company used the roadmap.

Only 18% said that customers accessed their roadmap, and even fewer companies (8%) told us that prospects can access their roadmap.

So it seems the vast majority of SaaS companies only allow team members to view the roadmap, even if most employees don’t actually use it.

Having said that, it’s essential that you produce a roadmap for those team members that will use it.

The graph below shows the most common teams that are granted access to the roadmap:

Generally, your Product and Dev teams will use it the most, to keep everyone aligned and aware of what is coming next. However, Sales teams can use it to tell prospects what you have planned, and Leadership can use it to keep track of where their product is headed.

Enabling your internal teams to access and use the roadmap should be the minimum.

You might also want to share your roadmap with customers. This way they can see what you’re working on and get an idea of the great new features they’ll be able to enjoy. It also reassures them that you’re actually developing the product.

The downsides are that you may inadvertently lock yourself into deadlines (see “Should I include time frames?”) or confuse customers if your plans and priorities suddenly change.

If you want to take it even further, and open up your roadmap to anyone, then you can do so. A public roadmap means that your prospects can also see where the product is heading, which may help them to make a decision and potentially impress them.

It does, however, also mean competitors can see what you’re working on, and also carries the same downsides as opening it up to customers.

The approach you choose here really depends on how much you value transparency. If you do open up your roadmap to customers or the public, then it’s important to set expectations and ensure they know that a roadmap isn’t set in stone.

Here’s what one of our customers, Emeric from Agorapulse, has to say on the matter:

“Not having any idea of where a company is heading forces customers out the door, while transparency keeps the right customers in. If a customer is considering leaving, but you have some important features on your roadmap, that may change their mind.”

Another option is to create multiple roadmaps, and have one aimed internally, one for customers, etc. This is a great way to ensuring everyone is covered but that you don’t have to give away information you don’t want to.

Should I Include Time Frames?

This is a major debate among those involved with roadmapping.

A roadmap with no time frames at all is really just a list of features that doesn’t help anyone. A roadmap with excessively detailed time frames, however, can tie you into unwanted and unneeded deadlines.

So, let’s explore the options you have available to you…

You could have no time frames at all. Instead, you would have a list of new features and improvements with a general order in which you’ll aim to release them, but no concrete dates.

The benefit of this is that you aren’t tied in to time frames and can work at your own pace.

The downside is that having no time frames at all doesn’t really tell people much, and sometimes having deadlines (even vague ones) helps you to focus and get stuff done.

Okay, so the opposite end of the spectrum would be to set specific dates for each and every upcoming release. Not only is this practically impossible to plan for, due to constantly changing priorities and resources, but it’s also not that useful.

Knowing the exact date and time is a little superfluous to requirements. Your customer doesn’t care whether that shiny new feature is released on a Monday or Tuesday, they care about rough time frames. Which bring us nicely to what I think is the best approach…

Going somewhere down the middle is often a good rule of thumb, and it’s no different here. Providing rough time frames, such as quarters or even “now/next/later”, provides enough detail to let people know when to expect features but doesn’t mean you’re committing to precise dates.

The best of both worlds.

How Much Detail Should I Include on the Roadmap?

Again, this is always up for debate. There are those who cram their roadmaps full of all the information they have, and there are those who are as succinct and minimal as possible.

So let’s start with the bare minimum, the least amount of information and detail that your roadmap has to have.

The whole point of the roadmap is to show people what you have planned for the product, so it obviously stands to reason that you should at least include the names of any features or improvements.

This can be really simple. For example, if you are planning to release an improved version of commenting in your app, then you could simply put: “Improved Commenting”. Then if someone is wondering when you’re going to improve your commenting, they can see that and know instantly.

The good thing about simplicity is that it makes your roadmap clean and easy to decipher.

The bad thing is that sometimes people require more information.

At the other end of the spectrum, you could pack as much information about new features and improvements as possible. To continue with the above example, you might include detailed notes on what the improvement will entail, aim to sell the benefits of it, and write a small essay.

The good thing about this option is that people can see the items on the roadmap and know exactly what it means. There’s no scope for confusion and misunderstanding.

The bad thing is that people generally don’t want to read that much when they look at a roadmap, and besides, how would you even fit it all on?

At Receptive, we like to keep our roadmap simple. We don’t want to overwhelm people with too much information. We want them to be able to glance at our roadmap and understand what’s coming next.

If somebody hovers over an item on our roadmap, however, then a box pops up containing more information about that particular feature or improvement. This is a clean way of providing extra detail, and is perhaps something you could consider.

Deciding What Goes on the Roadmap

This is the big one. The questions I covered above are important to nail down before you start, but they’re nothing compared to this.

How do you decide what to put on your roadmap?

If I had a dollar for every time somebody asks us that, I wouldn’t be working at Receptive, and I definitely wouldn’t be writing this.

If there’s a definitive answer to this question, then nobody has found it yet. But I think here at Receptive we’ve given it a pretty good go, and I think our answer is more than good enough.

The fact is, plotting your roadmap is a balancing act. You have to balance your product strategy, demand from customers, demand from internal teams, demand from stakeholders, and somehow translate all of that into a roadmap that makes sense.

It’s not easy, but there is a process that will help.

Start by ascertaining your goal (yes, just one) for the next quarter. What is the one thing you want to achieve with your product?

Let’s say, for example, that you’ve decided to improve the UX of your product. Great, there’s your goal.

Now, you need to figure out how you’re going to do that. This is where product feedback comes in to play. Your customers, prospects, employees, and stakeholders will all want different things from a UX. But you can’t put everything on the roadmap. In fact, you really shouldn’t.

Instead, look at the priorities. Which aspects of your UX do people dislike the most? Which areas are easy, quick wins, and which are more complex projects?

Delve into the data and you’ll find the answers. The data will tell you which areas you need to improve, and then it’s just a case of sticking them on the roadmap and getting on with it.

But remember… Your roadmap is a living document, so don’t be scared of updating it and rearranging things if priorities change.

Conclusions

If you’ve read this from start to finish, then you’re probably thinking that it’s a lot to take in. I thought I’d finish with a little to-do list to help you get up and running with your roadmap.

1. Decide what your roadmap will look like:

• Which time frames will you use?
• How much detail will you put on?
• Who will be able to see it?

2. Collect your data:

• Collect feedback from customers, internal teams, and prospects.
• Settle on a product strategy and figure out your goal.
• Segment your data in line with your goal and find your priorities.

3. Build your roadmap:

• Figure out the best order in which to approach the improvements.
• Construct your roadmap.
• Share with the relevant people, making sure to set expectations.

I hope this guide has helped you when it comes to roadmapping your SaaS product.

Thanks for reading!

Receptive helps B2B SaaS businesses to manage their user feedback efficiently, and to make the right product decisions. Find out more…

Everything B2B SaaS Companies Need to Know About Roadmapping was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

If a Product Manager was given three wishes, I’m willing to bet one of them would be an infinite amount of resources to work with.

Unfortunately, genies are in short supply, and there’s no such thing as infinite resources.

This gives Product teams a bit of a problem. In fact, it gives the whole organization a bit of a problem.

And B2B SaaS companies are left with the ultimate question:

“It’s impossible to build everything we’d like to, so how can we improve our product?”

I’m not going to lie and tell you there’s an easy answer to this question. There isn’t.

But what I can do is point you in the right direction. There are three things you need to do in order to start improving your product with limited resources.

So let’s get cracking…

1. Segment

Chances are, the real reason you’re asking this question is because you’re inundated with feedback and feature requests, and have a product backlog the length of the Nile.

As much as you’d love to build them all, you can’t. You don’t have the resources.

So, how do you choose which feedback to focus on?

You have to segment your data.

To do this, you need to go back to your product strategy. If you don’t have one, you should probably get one sorted.

Your strategy should tell you what your goals and objectives are for the upcoming month, or quarter, or year.

For example, your goal might be to close more Enterprise deals in the Education sector. We’ll call them Double E’s.

That might seem a little too detailed, but that’s important when you have a large product backlog.

By defining a specific goal, you’re now able to segment your data and focus on feedback that your current Double E customers have given.

Logically, it stands to reason that if your current Double E customers want something, then your Double E prospects will want it too.

Segmenting your data means you can drill down into a specific group of users, instantly eliminating a lot of currently unnecessary feedback.

2. Prioritize

Of course, if you’re a large Enterprise company yourself, then you’ll have a load of feedback left to sort through, EVEN after segmenting.

How do you know what’s the most important? What do your Double E customers really want?

The solution to this is prioritization.

If you aren’t already, you should be collecting prioritization data from your customers.

I know that a lot of Product managers like to do this themselves, but the trouble is it doesn’t scale, and you don’t always know exactly what your customers want the most.

Related: Product Managers Shouldn’t Prioritize

By allowing your customers to provide their own priorities, you free yourself up to make the big, high-level decisions. Let’s face it, that’s the best part of the job.

So you take the data you’ve segmented, and then you use your customers’ priorities to determine which ideas you should be working on first.

It’s also wise, at this stage, to determine how much effort each of the requests will take to build, and plot an effort-value chart like the one below.

This way you can easily identify any quick wins, and also spot which ideas will take up far too much resources.

3. Saying No

A lot of companies find it hard to say ‘no’ to customers. They’re scared of backlash, of angry customers, of churn.

Maybe they have a point. But regardless, saying ‘no’ is something you simply have to get used to.

Technically, this isn’t part of the answer to the initial question. This won’t help you improve your product with limited resources.

But I’ve included it as a final step because it’s an important, no, crucial, thing to do.

If your customers have taken the time to provide feedback, the least you can do is inform them when you decide to say ‘no’.

It can be a tough conversation, but it doesn’t have to be.

The thing is, because of your prioritization data, you have a valid reason to say ‘no’. You can point them at the data you’ve assembled and tell them that it simply isn’t a priority, or that it would take too much effort for the value you’d gain.

That explanation is key. If you have a valid reason, they can’t be angry, at least not for long.

You owe it to your customers to explain why you’re not building their suggestion.

Summary

To conclude:

• If you have limited resources, it’s still possible to improve your product.
• Start by segmenting your feedback to a specific group of users, based on your product strategy.
• Next, see what their priorities are, and build up an effort-value chart to identify quick wins.
• Finally, make sure to communicate back to customers, even if it’s to say ‘no’.

Best of luck!

Leading B2B Saas companies are using Receptive to build winning products. Want to join them? — Get Started.

How to Improve your Product with Limited Resources was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can generally separate the tickets your Support team receives into three distinct categories.

First, there’s the actual legitimate questions, where a user doesn’t know how to use a particular feature, perhaps because there’s a gap in your help documentation. These are the tickets your Support team should be dealing with.

Next up, you have the bugs. This is where your product doesn’t work as it should do, either because it’s broken, or because the bug is actually a thinly disguised piece of product feedback (we’ll get to that). Actual bugs are useful and can help the Product team fix any problems. Great.

Finally, you have the product feedback & feature request tickets. Sometimes these are disguised as the aforementioned bugs, but most of the time it’s a user who isn’t happy with the current functionality of your product and has some ideas on how to improve it.

Now, it might turn out that their idea is brilliant, but here’s the thing: Your Support team should categorically NOT be dealing with this kind of ticket.

Here’s why…

1 — It’s About Time!

Your Support team are there to support the customer, the clue is in the name. Spending time thinking about feature requests, ideas, and product feedback, and then having to pass them on to the relevant people isn’t, or at least shouldn’t be, in their job description.

It wastes precious time they should be using to actually help customers. Not only that, but it wastes other teams’ time as well.

If your Product team have to rely on your Support team for the data they need then it creates a bottleneck, preventing them from making any product decisions until the Support team get the opportunity to pass on any information.

The solution to this is to provide your customers with a self-service product feedback portal. For smaller companies, a simple email address or survey will be more than enough. For larger companies, you might need a more dedicated product feedback solution. You know, something like Receptive.

2 — Lost in Translation

If you think about a game of ‘Telephone’ then you end up with a pretty good idea of what it’s like when feedback is passed from department to department.

Your customer sends in a support ticket with an idea for a feature. Your Support team member digests that information, then relays it to the Product team. The Product team then add it to their backlog where it stews for a while. Eventually, they look at it again, and they have no idea what it means, who it was from or if it even matters anymore.

This is a common state of affairs in companies that have their Support teams deal with product feedback & feature requests. The Product team will end up lacking the context surrounding the idea. Why do they need it? What are they trying to achieve? Do they have a workaround? Without context, any feedback is meaningless.

Instead, you need to enable your Product team to speak directly to your customers, so they know exactly what they want, and more importantly, why they want it.

The product team is eager to hear what customers need first-hand, and not to have it filtered. A direct communication channel between a customer and the product team removes the need to manage expectations.” — Lisa Starita, (previously) Head of Customer Success Operations at Beekeeper.

3 — Who Answers Back?

Following on from the previous point: The fewer teams involved in the feedback process, the clearer the process is.

In the earlier example, both the Support team and the Product team were part of the feedback chain. In cases like that, who exactly is supposed to respond to the customer and close the loop?

We’ve written about the dangers of the black hole of feedback over and over — it’s vital that you respond to the customer, either for clarification or to update them on the status of their idea. But who should respond?

Now both the Support team and Product team have to work out between them who should communicate with the customer, wasting even more time and generating a great deal of confusion.

If you have a good Product Feedback Policy in place, everyone knows what to expect.

The Support team knows how to handle feedback effectively and pass it on to the Product team.

If you open up a separate channel for your customers to submit feedback and feature requests ongoing, then you will see a dramatic increase in support tickets, your Product team will be getting the information they need, and it will be easier to keep customers in the loop. This creates a better experience for everyone.

Here are some typical results for B2B SaaS companies using Receptive to manage their feedback:

So, there are three very good reasons why your Support team shouldn’t deal with product feedback. But I suppose the bigger question here is…

How do I Prevent my Support Team from Managing Product Feedback?

Well, with a little bit of process, it’s actually fairly easy to do.

Step #1

Create a Product Feedback Policy (PFP).

A PFP is essentially a service-level agreement for your Product teams. It tells your customers how they can submit feedback, and what will happen to it. This helps get your customers on board and sets expectations both inside and outside your organization.

That’s a simple process that helps take your Support team out of the equation when it comes to product feedback, saving them time and energy.

Step #2

Set up your product feedback portal. As I mentioned before, this can be a dedicated email address or a survey. It needs to be something easily accessible that your customers can use as and when they please. If you are a scaling or Enterprise B2B SaaS company then Receptive was built especially for this purpose.

Step #3

Next, you need to choose an employee (often part of the Product team) whose job it will be to regularly check through the feedback and highlight any ideas that are particularly relevant.

If your company is scaling or has already outgrown the process above, then it’s time to consider a solution like Receptive, which saves time and energy across the whole organization, not just the Support team.

Realizing that your Support team should NOT be dealing with product feedback and then putting a process in to enable that will work wonders for your business — and your Support team will be extremely grateful too.

If you want to start using Receptive to manage your product feedback and save your Support team’s time, then get started here.

3 Simple Reasons your Support Team Should Never Manage Product Feedback was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve been paying any attention to our content, then you’ll already be well aware of just how important product feedback is to a B2B SaaS company.

Most of the content you read online suggests that product feedback is the responsibility of the product team. We disagree…

Product feedback is everyone’s responsibility.

It’s crucial that you get all hands on deck. In fact, if you don’t, your product feedback management might have failed before it’s even begun.

The fact is, the way you manage feedback is impacted by, and impacts on, everyone in your organization. Your Sales, Support, Success, Product, and even Leadership teams all need to play their part.

If you aren’t all aligned on a common way of managing product feedback, and if you don’t share the same attitudes towards it, then your process is going to break down and fall apart at the seams.

Imagine running a support team with no SLAs, working with no contract or not having a clear health and safety policy in place. That would be terrible.

So, how exactly do you go about ensuring that everyone is responsible for product feedback?

Well, you need a common definition.

You need to define your procedure, your approach, and how each team can contribute.

Without this definition, each of your teams will end up doing their own thing. Your Sales team might receive feedback from prospects and stick it in a document. Your Support team might receive feedback from customers and file it away in a spreadsheet. This results in your Product team being left in the dark, and with no way of making data-informed decisions.

We’ve talked a lot about creating a Product Feedback Policy (PFP). A PFP helps explain to your customers and internal teams your approach to product feedback, and provides an outline of the process.

While the PFP outlines the general process at an organizational level, it’ll help you to create a document that explains the process at a team level as well. It needs to go into more detail than the PFP, helping each team to understand the steps they need to take in order to effectively manage feedback.

Think of it as being like an SOP (Standard Operating Procedure) for your product feedback process.

This SOP will end up slightly different for each team involved in the process, though it will have overlapping steps in many instances.

For each team you need to provide an outline of what they need to do at each stage of the feedback process, and how their actions link to and affect the other teams.

For clarity, we’ll work through what such a process might look like for your Sales team:

• Step 1: A prospect provides you with a piece of feedback.
• Step 2: You should enter the feedback into our central database, making a note of the prospect who requested it. (This then allows our Product team to access and review it.)
• Step 3: The Product team have reviewed the feedback and made a decision. You should inform the prospect of our decision, explaining the reasoning behind it, and encourage them to submit feedback again in future.

As you can see, the steps are clear and simple yet provide a complete depiction of what happens at each stage. They provide actionable advice and they also explain how one team’s actions fit in with the wider process.

By providing each team with their own outline, personalized to them, you’re helping everyone understand the role that they play in your overall product feedback process.

Do this for each of your teams and it’ll mean everyone understands what they have to do at any particular time or in any situation.

All of these parts will then come together perfectly to form the whole.

Product feedback is everyone’s responsibility, and by creating a Product Feedback Policy and an SOP, you’re ensuring that you manage feedback efficiently and effectively.

Receptive helps leading B2B SaaS companies to build winning products. Why not see what the fuss is about and get started today?

How to Ensure Product Feedback is Everyone’s Responsibility was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.