Recommended
More Related Content
Similar to Feedback: The Secret to Innovating Your Product Development Process
Similar to Feedback: The Secret to Innovating Your Product Development Process (20)
More from Aggregage
More from Aggregage (20)
Recently uploaded
Recently uploaded (19)
Feedback: The Secret to Innovating Your Product Development Process
- 1. & With November 3, 2021 9:30 am PST 12:30 pm EST 4:30 pm BST Product Managem ent Today The Product Journey: Feedback - The Secret to Innovating Your Product Development Process
- 2. Today’s consumers expect software to be as easy to use as the apps on their phone. Pendo helps companies meet these rising user expectations. As the only platform to combine in-app messaging with robust product analytics and user feedback, Pendo ensures people adopt software quickly and successfully. Using Pendo, product teams can combine qualitative and quantitative insights to make more informed decisions on how to support customers throughout their journey. IT and HR teams can onboard, train, and support employees inside the tools they use at work, helping to improve employee proficiency and accelerate ROI on software investments. Learn more about what’s possible with Pendo at Pendo.io.
- 3. TO USE YOUR TELEPHON E: Yo u m u st select "Use Telep h o n e" af t er join in g an d call in u sin g t h e n u m b er s b elow . Un it ed St at es: +1 (562) 247-8422 Access Cod e: 860-153-717 Au d io PIN: Sh o w n af t er join in g t h e w eb in ar TO USE YOUR COM PUTER'S AUDIO: When t he webinar begins, you will be connect ed t o audio using your com put er 's m icr ophone and speaker s (VoIP). A headset is r ecom m ended. Click on the Questions panel to interact with the presenters 0 3 Product Managem ent Today The Product Journey: Feedback - The Secret to Innovating Your Product Developm ent Process
- 13. Step 1 - Assign responsibilities ● It takes time & effort! ● Who owns the process? ● Who will review and organize the feedback? Can it be delegated?
- 14. Step 2 - Go to your users (remote) ● Online communities ● Social media ● Company website ● In-app ● Customer resource center ● Product analytics ● In their day-to-day tools
- 15. Step 2 - Go to your users (in person) ● Events & conferences ● Shadow them at their workplace ● Local coffee shop ● Sales calls ● Support desk ● Training & implementation Courtesy of the GDS Blog
- 16. Step 3 - Create the right channels… ● Survey ● Conversation (zoom, phone, in person) ● Email ● In-app widget or form ● Browser extension ● Integration touchpoint ● Product analytics
- 17. Step 3 - …..using the right formats ● Verbal/audio ● Written ● Video ● Picture
- 18. Step 4 - Collect
- 19. Step 5 - Analyse & segment ● Group similar feedback together ● Use metadata ○ Personas ○ Tags/labels ○ Categories ○ Market segments ● Make it actionable! Identify potential solutions
- 20. Step 6 - Share it & use it ● Share it with others ● Story telling ● Use as context in your discussions ● Reason to say no!
- 21. Step 7 - Keep communication going ● Share your roadmap! ● Usability testing/beta testing ● Launch announcements ● 1:1 notifications when feedback is used ● Community discussions ● Sneak previews
- 22. Step 8 - Feedback at every stage
- 24. Defines “What”
- 25. Explains “Why”
- 29. linkedin.com/in/ michelle-carter1212 productmanagem enttoday.com Q&A To view more from The Product J ourney series visit: https://www.productmanagementtoday.com/ webinar-series/13723/the-product-journey
Editor's Notes
- Before we start talking about feedback, I’d like to share with you the journey that I went on when writing this talk. After being invited to today’s event, I sat down to write a presentation on “feedback loops”, knowing roughly what I wanted to say. I wanted to tell you why it’s important to collect feedback from your users, and your potential users so that you could make good choices about what to build. I wanted to tell you about the need to iterate on the changes you make and to follow the principle of “build-measure-learn”. And I wanted to explain why asking for feedback can lead to increased engagement with your internal stakeholders and from your users, with all the benefits that engagement brings with it. I like to create visual presentations - lots of imagery to illustrate my points. As I started to look, all I could find was memes. Hundreds of them. Most of them were really funny (and I’ll provide some great links later for you to share with your network!), and I started to think “why are there so many?”. I know our marketing team regularly post memes and jokes on our twitter feed and that these posts get great engagement. But why? My conclusion - Product Managers are experiencing the same problems everywhere, and so it’s easy to tickle their funny bones with observational comedy! So, I thought the best way to illustrate the value of a good feedback mechanism was to use memes, and dig into why they’re funny, and how we can rise above the problems they illustrate.
- This is funny because PMs need to be able to say no, and that’s not always done with tact. But how does the PM know that no-one wants their stakeholder’s idea? How do they push back with such confidence? One school of thought on this meme is that the PM is an arse who doesn’t care about feelings (I’m sure we’ve known people like that!). However, maybe they can be confident because they collected feedback! If you’re in a situation where you have to have a conversation with a stakeholder about why their idea isn’t progressing through to development, it’s much easier, and less confrontational, if the PM can say “the feedback indicates that this isn’t something our market would benefit from”. It’s not the stakeholder that’s wrong, it’s that the market isn’t receptive to their idea. It’s the feedback’s fault, not the stakeholder’s fault. Much nicer, less confrontational, and everyone stays friendly! Basically, feedback is helping us to manage conflict here, and introduce psychological safety into the discussion, meaning we’re more likely to stay engaged with our stakeholders and have a productive working relationship.
- We all get feature requests all the time from people who are user facing - sales, operations, support, success. And of course, it’s always the most important thing that could possibly be done right now. You have to have sympathy for user-facing folks, as they’re under pressure from people, often on a personal level. Now, in spongebob’s case, he’s burning the request coz he’s fed up of having to deal with this stuff. Why is he fed up? He knows he can’t possibly act on every request he gets, and it’s easier to just burn the request than actually deal with it. Not only that, he knows that, right now, this is a no, and just can’t work out how to say so (he’s not as tactless as our Doberman dog meme!). What if he had a mechanism whereby the request could be used to help validate decisions, and was actually useful! Just like the last meme, this whole situation would be easier to handle if Spongebob had a mechanism for managing the feedback that landed on his desk. He wouldn’t have to secretly burn the request, and he’d be able to use it to make his job less confrontational and stressful and he’d also be able to share details of his other feedback with the sales team so they could see what else their customers were looking for, and maybe understand why this latest request isn’t highest priority.
- Up to now, we’ve been thinking about the interactions with our peers - sales people, support, success etc. But what about the execs in our world? The ones who are looking to us to make decisions about what to build. They need our products to be successful, so that the organization achieves its goals. Nobody likes a failed launch. How do we avoid failure, or at least minimize the chances of it happening? And if it has happened, and we need to change course and pivot, how do we reduce the likelihood of it happening again? I’m not sure if you’re seeing a theme here, but……..Feedback! A launch is much more likely to be successful if it’s based on an understanding of user needs. This is twofold - it’s partially about understanding the user in the first place so we start off on the right foot. It’s also about how we launch the product. How do we ensure that we’re telling our user base the information they need in order to begin using the product? How do we communicate in a way that resonates? Understanding our users means that we can build the right thing, but also that we can relate to them and help them be aware that a solution exists and not just build it without telling them.
- So, first of all, I know many (most?) of us will have seen this meme, or variations of it. It’s meant to signify the difference between UI and UX, how design can make something pretty, but how our users will bend what you give them around their actual way of working. How many of us have launched a product only to discover it’s being used in a way we didn’t expect? I get a little grumpy about this one, because I know that our designers don’t really work like this these days - a great designer considers the usability/user experience AS WELL as the aesthetics (I know this, coz I’ve seen how the guys work in my own organisation, and how they do a fabulous job of making great design work in the real world). The big question here is, how do our designers make sure that they’ve considered user experience when they create an interface? Of course, the answer is Feedback! And unlike some of our earlier examples, I’d like to think about different types of feedback here. We often think of feedback as coming in the form of feature requests by email, or in a support ticket. But what about usability testing? Beta testing? There are a number of different ways of collecting feedback, and it doesn’t necessarily have to be asynchronous. When a designer puts a prototype in front of a user, or even observes them using a real product, they’re collecting feedback which can be used to iterate on the design and make it more usable, more delightful. Hopefully, that rut in the grass doesn’t appear.
- I suspect many of us have seen this one. Similar to our last example, this is about design, but it illustrates the point that feedback isn’t a license to just do whatever the user asks for. Just because we get a lot of feedback telling us to jump, it doesn’t mean we should say “how high?” and throw ourselves in the air! Understanding feedback is just as important as collecting it. Asking why. Asking why again, and again and again, until we really understand the user’s pain point. I often quote the example of my 75 year old Dad, who rang me one day to say he needed to write a macro in excel. Rather than teaching him how to do it (which, by the way, would have needed some learning on my part!), I asked why. He told me he needed to make sure a specific field in his spreadsheet needed to be filled in a certain way. I continued asking why until I thoroughly understood the context (what spreadsheet was it, who was it for, why did they need it, what problem was it solving for them). We settled on a different solution (we just formatted the field to pick from a list of values in the end). The solution was much simpler to implement, solved the real problem, and didn’t involve the two of us learning how to write code. He was blown away with the simplicity of the solution, and I gained valuable daughter points, too. In this example, think of feedback as an expression of frustration often expressed as a solution, giving us an indication that there is a problem to be solved. It’s letting us know there is an opportunity to help our users, and in a commercial environment, to make money. In a less commercial environment, it may be an opportunity to introduce efficiency, to do more with less! Without that feedback loop in place, without access to real users where we can dig into the real reason for the request, we would be creating complex solutions that add to frustration rather than solving problems.
- Does feedback always come in the form of customer requests or individual user comments? I’d argue that no, it doesn’t. The definition of feedback is “advice, criticism or information about how good or useful something or somebody’s work is”. I’d argue that the value of feedback is not just the content of the feedback, but also the volume, prevalence or frequency associated with it. For example, I may have 100 pieces of feedback relating to a problem experienced by my users, but if that feedback was received over 5 years, from 15000 users, you could argue that it’s actually not that big a problem. This is where data and analytics are important, and, most importantly, an understanding of how to interpret them. If we aren’t able to collect information from our users on usage in the real world, how will we know what’s working and what isn’t? I’d argue that feedback comes in the form of real usage data - if our users like our product and find it useful, that will feed back to us in the form of high adoption rates. If it’s not working for some reason, we’ll see that in the data.
- Ha - this one makes me laugh a lot. It’s a little bit like the phrase “If we build it, they will come” - but of course, nobody will react to a new feature if they don’t know it exists - it’s why we have marketing! It’s the same with feedback - if we don’t provide an easy way for our users to tell us what they think, they probably won’t bother. So how can we do it? Firstly, consider the likely sources of feedback that you have. Where might you engage your users? In-app, via the website, support desk, sales team, social media, operations teams, user community, there are likely to be multiple places where there is the potential to get feedback from your users. Maybe you have more formal mechanisms like monthly catchup calls, usability sessions or maybe a user group meeting. Whatever avenues you have, think about how you can make it easy for users to give you that feedback. Can they fill in a form, send an email or complete a survey? Can you open up an “office hours” type session where users can drop in to tell you what they think?
- OK, we’ve established that it’s important to collect feedback, as it helps us to make decisions about what to build, helps us to manage internal discussions about our plans, and helps us to validate our work as we move forward. So how do we manage the process around collecting and managing the feedback we have access to?
- Like any process improvement project, it’s useful to assign an owner for the development of the process itself, as well as who will be responsible for reviewing and triaging the feedback that comes in. One of the problems I often see with feedback is that efforts are put in place to collect it, but nobody is looking at it. It needs to be reviewed, organised and turned into something actionable. Side note - this is a great job for an aspiring PM, or an engaged customer success person, as it’s a really good way of seeing exactly what people are saying about your product and learning about the kinds of problems experienced by users. It can be a timeconsuming thing to work on, unless there are ways you can automate or streamline it. Hint hint - a good PM tool can help here.
- Back to memes again - but it makes sense. Keeping all your feedback in a single place makes it easier to analyse it and identify themes. It helps to identify connections, and the things which crop up time and time again. Note: this is for feedback - bugs belong in a bug tracker, so consider having a break point in the process where bugs go one way, feedback goes to product
- Ideally, your feedback should give you the insight to understand where to focus your attention and help you build a strategy. I’m not going into the roadmapping process in this talk, but there is a direct link between the insights you get from your feedback and your roadmap, provided you also consider the “top down” of objectives, product vision etc.
- Feedback is useful in every part of the process! Don’t just think about it being the start, incorporate feedback loops into the way you build (test along the way) and as a way of measuring success
- So, in PM, feedback is everything. If we don’t have feedback, and don’t know how to use it, we’re basically shooting blind.
- It helps us to understand what pain points and problems our users are experiencing, so we know where the high value opportunities lie
- It gives us the context to create the best possible solution, so that we can delight our users and make it easy for them to get what they need
- Rather than delivering a solution and moving on, feedback encourages us to look again and be positive we’ve solved the problem. If we’re still seeing feedback, we know we still have work to do and an opportunity to get more from our product still exists
- The more we learn, the more we iterate, the more we are likely to reap as a reward from our hard work. Not only that, but we’re more likely to delight our users and see referrals, and recommendations leading to yet better interactions with our customers and users.
- This is an interesting one. Before I joined ProdPad, I was a customer, and although I liked the product, there was so much opportunity for it to be better. The team were so engaging, and so eager to hear my voice that I felt safe and encouraged to offer even more feedback. It was a mini-feedback loop in itself….. The more I told them, the more they improved the product, and the happier I got. Not only did I keep using their product (which was great for adoption!) I even introduced it in other companies when I moved roles. It was a win:win situation - ProdPad saw better adoption, more business and I got solutions to my problems. There are no losers when it comes to using feedback!