Product Management: Why internal product feedback matters

Internal feedback on your product or feature is special, and can help you make better products that your customers love, rather than tolerate.

Here’s why:

Effort vs Reward

Much external (customer/user) feedback on your product gets to you because it’s so painful, that the cost of reporting it to you is worth the effort. That is, the time and effort involved in contacting your support team or customer success team, detailing the issue, why it matters, how it might be fixed, and the resulting follow ups, are worth the issue being fixed.

Many small frustrations, like User Experience issues, don’t meet that effort criteria. They’re small – tolerable – workaroundable. But they can quickly add up to a bad overall User Experience or worse, a poor opinion of your brand.

Think about this: If you’re setting up a new software product, and you have to a click a button twice to make the button do what you want, instead of once. What do you do? You probably just use the workaround. Because, you want to move onto the next thing. You’ve got a meeting in a minute. The time/effort involved in talking to your IT team, who then may need to contact the vendor, isn’t worth it to you.

But that software product, and its user experience, is suffering. The user now has a more-negative experience. The vendor of that product is missing out on opportunities to improve the experience.

Tapping into Internal feedback is one way to make sure you’re getting that valuable low-friction feedback that could take your product from “meh” to “yeahhh!”.

Take advantage of reduced friction

Internal feedback is different. There’s less friction involved. As a user, using my company’s products, there’s typically a forum or community where I can feedback, or raise a bug.

You can get feedback earlier. If you get the product or feature in Internal team’s hands earlier, you can fix issues before they’re even noticed by external customers.

Often, the feedback is more honest, too.

Also, internal feedback usually comes from love. Or at the very least, a desire to help the company build great products and be successful.

And because it’s internal, it should be easier to funnel/route it to the right places.

Some thoughts/considerations on Internal feedback

Some tips for dealing with Internal feedback:

  1. Build a community around feedback. Make sure that feedback is acknowledged and appreciated openly – if you want to make great products, people should feel like their opinions are wanted and they’re listened to.
    1. I personally love how open Slack channels can be. The feedback is right there – it’s trivial for people to “+1” a problem or thought.
  2. Make your internal feedback ingestion process as easy as possible for the people reporting their feedback. If you care about this feedback, it’s in your interests to make it really easy. The effort of raising/classifying the issue should be on you, the Product Owner/Manager. Get that friction close to zero.
  3. Where possible, have a place where you can “funnel” the feedback and keep it transparent. This can be hard in large companies with many products. But I favour asynchronous forums which are open for all to see (public Slack channels, for example)
  4. Don’t fall into the “We’ve never heard this from external people before” trap. That doesn’t mean the feedback is less worthy of consideration.
  5. Understand that in most cases, the feedback comes from wanting to make things better. It’s not personal. It might feel like criticism, and it might hurt because it’s from a colleague, but the intent is good.
  6. Don’t argue over whether the feedback is a “bug” or a “feature request” and don’t put that onus on the Reporter.
    1. Classification is irrelevant to the User Experience. Fix the experience.

What about Dogfooding?

A note on “Dogfooding”:

It’s not enough to use your own products internally. You have to solicit and act on feedback from those efforts – build a community if you can.

If you don’t take and act on that feedback, you’re missing out on a huge opportunity to make products and features people love, from the people most invested in your own success.

What did I miss?

I bet there’s a number of positive (and negative) points around Internal feedback that I’ve not considered. I’d love to read your thoughts in the comments below ?

How to get a Bearer Token from Citrix Cloud for API access, using PowerShell

Wanted to share a quick PowerShell code snippet.

I used this to get a Bearer Token from the Citrix Cloud API trust service using PowerShell.

It’s not beautiful, but it gets the job done.


You’ll need:

  • The clientID and clientSecret from your Citrix Cloud customer API client (how to do that is here)
  • Your customerID for your Citrix Cloud instance

Then put those in-between the relevant quotation marks in the code snippet ๐Ÿ™‚

PowerShell code snippet



Citrix Remote PowerShell SDK error: “Could not establish trust relationship for the SSL/TLS secure channel with authority ‘localhost’.”

If you see the following error when trying to run cmdlets from the Citrix Remote PowerShell SDK

Check and make sure you are running PowerShell in its 64-bit flavour, and not 32-bit (x86).


I had this issue recently when automating some tasks with Jenkins talking to Citrix Cloud, using the Citrix Remote PowerShell SDK:

On the same host as Jenkins, if I ran a PowerShell shell, and ran the exact same script, it’d work fine.

If I ran it in Jenkins, it would fail with an error like this:

Root Cause

The root cause is there’s something up with 32-bit PowerShell and the Citrix Remote PowerShell SDK.

Jenkins runs the 32-bit version of PowerShell because Jenkins itself is 32-bit. The reason the script worked in a PowerShell shell on the Jenkins host, was because the default on Windows is 64-bit PowerShell. As soon as I forced PowerShell 32-bit, I could reproduce the problem.

The Fix

The fix is to force Jenkins to use PowerShell 64-bit. There’s two options I found:

  1. You can workaround it with some good tips here:
  2. Or you can fix it fully by making Jenkins run on 64-bit Java:

Context is Queen

Want to improve your workplace communication skills, especially when working with other teams?

Give context.

Why give context?

Context helps your colleagues:

  1. Understand where you’re coming from / viewing things from.
  2. Understand who you are, and what you’re trying to achieve (your overall project, not this specific request)
  3. Helps remove assumptions. Teams often have their own dialects, and your request may mean something entirely different to them. Giving context helps them understand if there might be other dialects in play.
  4. Saves them time in “back and forth” clarifying questions, which, if the teams are remote, can take days.

Context helps you too:

  1. It saves you time in the long run – you’ll reduce the amount of “back and forth” while the receiving party tries to figure out exactly what you need.
  2. You might not actually need the thing, or need to do the thing. The team you’re asking may already have done something that can help you. But if you just ask for “$thing” you’ll never know, because they don’t know your project/goal!

A worked example

Here’s an example I used on Twitter recently:

Bad: “I need $thing”

Good: “I’m from $group. I’m trying to help $team with $companyGoal, to do $workItem, and need help with $thing”

This difference this makes can be stark, and it usually only takes a few minutes more:


I need a new SSL certificate


I’m from the web applications team. Our SSL certificate will run out soon (we’re trying to automate renewals but we’re not there yet), and I need the new cert to prevent our web app from going offline next week. Can you help please?

If I received the first request. I give them the cert.

If I receive the second request, I can tell them all about the solution our team developed to help developers with certificate management and auto renewals!


So please, do yourself, and your colleagues a favour – give context! ๐Ÿ™‚

A quick Citrix microapp hack to get notifications when there’s a Citrix Security Bulletin

Credit to Gabe Carrejo and the Patrick Quinlan for their work on this.

It’s possible to use the Citrix Support Security Bulletin RSS feed with Citrix microapps to notify you (or a group) when there’s a new Security Bulletin from Citrix

Rough Steps:

  1. Copy this RSS URL:
  2. If you want to narrow the feed down to a specific product or category, look for the category tags in the RSS feed and add them when you add the RSS integration in step 3
    • Some examples, in case they help:
  3. Follow the RSS microapp guide here and replace the blogs RSS URL with the Security Bulletin URL:

Of course, you don’t need to use microapps to get Security Bulletins (you could just use an RSS reader) but it’s a very neat use case – and combined with Push Notification with Workspace, means you get a notification to your phone when there’s a new Bulletin. Great idea, Gabe!

A full list of feeds available from Citrix Support are here: