post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Cliff was part of the team that launched Product as a true discipline within a fast-growing health and wellness company where he continues to lead special projects that result in new business verticals, partnership assessments and integrations and acquisitions. His current role includes managing Product, UX, QA and Tech Support disciplines providing a unique 360-degree view of the solutions in the market.  Cliff’s path to Product Management included detours in Sales, Business Development and Digital Marketing.  Cliff has an MBA from the Cox School of Business at SMU and a B.S. in Business Administration from Trinity University in San Antonio.

Cliff Newby

<p>Do you start with a “No”?  Defining your process for feedback will save time and improve feedback quality.</p>
<p>My seven-year-old son has the gift of positioning, a trait he comes by honestly as his mother is a sales professional.  He knows that, given the opportunity to present his case the likelihood of approval increases.  Lately, he has started off his requests with the phrase “Don’t say “No” yet…”.</p>
<h2>Consider Your Approach to Feedback</h2>
<p>Saying No is an important part of the product manager’s role.  At every level of our careers, we are faced with unsolicited, opinionated and sometimes outlandish product feedback from our internal teams.  It’s all-too easy to discard this feedback as we focus on the initiatives already in play, the resources available, supporting data and the all-important roadmap and strategy.</p>
<p>However, how you say “No” and your overall approach to feedback should be considered.  “No” outcomes can have a serious impact on the capital you have worked to build within your organization.</p>
<h3>Product “No” Outcomes</h3>
<ul>
<li>Dismissive of Feedback</li>
<li>Siloed</li>
<li>Lack of collaboration</li>
<li>Lack of interest</li>
<li>Missed opportunity</li>
</ul>
<p>The other side of the coin is that you can’t stop to talk to everyone about their input.  Time is money, and I have yet to meet a product manager who asks for another meeting.</p>
<p>So how do you say “No” while maintaining a sense of collaboration?  It’s critical that you establish the best method for receiving feedback in your organization and access feedback from those close to the consumer in a method that isn’t disruptive.  Establish the best method for receiving feedback within your organization.  Streamlining this process can achieve valuable results.</p>
<p>As an example, I currently manage a small product team, and our client service and sales teams outnumber us 15 to one.  How do we ensure the right internal feedback hits our desk?  I met with each department’s key leaders, and together we outlined a feedback funnel where their team could submit requests.  The key leaders installed a validation process to review and approve the items sent to our Product team. The value of the feedback funnel was significant:</p>
<ul>
<li>Duplicate feedback items were eliminated</li>
<li>Requests with little detail or that were outside our business were eliminated</li>
<li>Extraneous meetings were cancelled</li>
<li>Priority was established with the deliverable, and as the meeting cadence continued, priority was continually re-established.</li>
<li>Managers and senior leadership had greater visibility to the challenges faced by their team members in the field.</li>
</ul>
<p>The final value outcome to this process was the feedback loop – Product can now show items completed from the prioritized department list.  The key team members share this information with their teams as a win.</p>
<h2>What did we Install Internally to Achieve These Outcomes?</h2>
<p>It started with the head of our Client Support department &#8211; who happened to be a strong supporter of the Product team &#8211; mentioning that she felt her team had good feedback, but the perception was that their requests were ignored or denied.  Her team had given up.</p>
<p>Product’s experience was quite different.  Their requests weren’t being ignored.  In fact, her team’s requests were coming in greater volume every month.  Product was overwhelmed and the lack of process, prioritization, and feedback meant that the work that was completed wasn’t making it back to the team and subsequently, to our clients.  This information surprised our head of Client Support, and the open and honest discussion quickly turned to finding solutions.  The Request Funnel was designed during this conversation with the goal of ensuring management at each level within the department could review their team’s feedback and reducing any red tape to getting verified requests to product.</p>
<p><b>Step 1:  Identifying the Request Lead.</b>  Client support had a team member with a strong background in the technology and managing client programs.  This team member was a “go-to” person for the department, and met with all managers to discuss the Request Funnel and process for submitting requests.  This allowed for a standard request format or set of data that should always be included.  Comments like “All my clients..”. or “Every user..” had to be validated by the requestor.</p>
<p><b>Step 2: Rolling out the Process</b>.  At their next team meeting, the lead announced that “requests go to your managers first”.  Product aligned with the process and supported by reminding team members that requests should be sent to managers first each time a new email request was sent or meeting was attempted to be set up.  Enforcing the process was challenging for a couple of weeks, but quickly became the norm.</p>
<p><b>Step 3:  Review and Consolidation. </b> The managers collected the feedback from their team members and sent it on to the Request Lead.  This is where the process started to show signs of potential value.  Managers began rejecting requests and coaching team members to leverage solutions already in place or to steer clients away from paths that were outside our core business.  The Request Lead was also able to support this &#8211; leveraging their background in technology and client experience to further weed out the bad or inconsistent requests.  Priority also became more clear, as seperate managers were providing the same feedback on specific items to the Request Lead.</p>
<p><b>Step 4:  Prioritization</b>.  The department head and managers met, quickly reviews and agreed on the requests being made, and the priority with which they were ordered.  All said, in about 30 days the requests being sent directly to Product subsided, and the Client Support team walked in to share their top most critical requests.  Since the requests had thorough information and documentation, the Product team was able to quickly capture the enhancements.</p>
<p><b>Step 5:  Quick Wins vs Larger Projects.</b>  Product reviewed the feedback with the department head and Request Lead.  During the meeting, each request was identified in one of two buckets: Quick Win or Larger Project.  Quick Wins were defined as small enhancements that could be done iteratively in a sprint or two.  Larger Projects were requests that affected infrastructure, changed fundamental systems or were large, new features.  Once the projects were organized, Product developed requirements for the top priority items.</p>
<p><b>Step 6:  Feedback Loop. </b> The end result was that multiple Quick Wins were completed within a 30-day period, and two larger projects were defined and added to the roadmap.  Making sure the teams were aware of what we were doing was of the utmost importance.  Instead of following the usual channels of email updates and release notes, Product met with the Request Lead and several key team members to train them on our product planning, release and support software.  Read-only access was provided and designated team members could quickly check the project boards to see a status.  Of all the changes to process, this may have been the most dramatic from a transparency standpoint.  The teams quickly picked up the process and now better understand the software development lifecycle.  They stayed as up-to-the-minute as they needed to on tracking items to completion, and then updated their counterparts once complete.  This took the burden off communication and allowed for greater discussion on priority.</p>
<h2>Improved Quality of Requests</h2>
<p>Back to my seven-year-old.  Saying “No” too quickly might cause me to miss an opportunity to share an experience with my son, much like saying “No” too quickly to a product request could prevent an experience improvement, a valuable enhancement or a new and much-needed feature from reaching our customers.</p>
<p>Saying “No” too quickly is a symptom of an improper feedback process.  By establishing a firm method of receiving feedback, you can streamline and add value to your internal communication process, making sure the most important items bubble to the top and remain the priority.  In fact, through this method we found that with the improvement in quality of requested items, it is so much easier to say “No” when the request is the Product equivalent to “Can I ride my bike off the roof?”.</p>
<p>&nbsp;</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Startup Roadmaps and Prioritisation, by Ahmed El-Sharkasy

Evidence-Based Product Backlogs, by John Pagonis

Roadmaps & Prioritisation – Lessons Learnt the Hard way, by Ren Yi Hooi

Embracing the Art of Prioritisation by Emily Tate

How to Start a Bank from Scratch by Megan Caywood

How to Start From Scratch and Prioritise by Marcel Britsch

Courtney Wylie – Building Your Business Model When Your Customer is not Your User

Managing Feedback: Do you start with a No?

Cliff Newby

Comments

Read next