How to Avoid Opinion-Based Decision-Making… Do this Tomorrow

I’m sitting in a room (virtual) and facilitating a strategy session for a product leadership team. This is a very dedicated and hard working team who are also overwhelmed by a very log list of initiatives and shiny objects that have been handed down from the broader company leadership team. The discussion is centered around “I think” and “I believe” and we go round and round on what other leaders and company SME’s have conveyed to them…some completely divergent from one another. No one feels comfortable that they can propose a path forward.  Sound familiar?

I see a lot of companies struggle with this. We’d all love to say that we look at reports daily, we save time for strategic thinking each week, we stay close to our customers through ongoing, regularly scheduled interactions (be it interviews or observational sessions, etc.) But let’s face it. Most teams have a hard time just keeping up with the day to day operations.

Now, if you can shift the mindset and operations of the team to do more insight and feedback gathering as a regular practice, more power to you. We recommend it! And we have all sorts of advice and tools to help you make that transition. But let’s talk about what you can do tomorrow to be more effective at decision making and getting commitment as a bridge to this transition.

Let’s go through 3 tips you can do tomorrow in avoiding the data free zone of decision making. 


Tip 1:  Identify who the decision maker is vs. people that have an input

Decisions are constantly derailed by folks that feel they have a say in a decision. We’ve all been there. Someone that once was in your organization or knows the code or is a leader of a big functional organization or is influential with the leadership team…Organizations are full of folks with great intent but create massive churn in the product creation process. There is a great decision making framework called RACI. Many of you have probably heard of it.

  • R = Responsible – The person responsible for facilitating closure to the decision. That’s usually you, the product person.
  • A = Approver – There should only be 1, sometimes 2, but never more. Get clarity with your leaders and force the decision on who is the approver. And make it known to everyone involved.
  • C= Consulted – This is an important group. These are the SMEs or people that are significantly impacted by the decision. Sometimes these folks think they are decision makers. Make it clear, they are an important source of input into the final decision, but not approvers.
  • I = Informed – this could be a long list. These are all the folks the might need to know.

Action Item 1: Does your decision have a clear approver? And are your C’s clear on who that person(s) is? If not, establish this now. Put the RACI roles at the top of every decision-related communication going forward. Every deck should have the RACI in the appendix for reference. Start now. Better late than never.


Tip 2:  Agree & document the problem you are solving AND the criteria by which you are going to make a decision

Be clear on what you are solving for and how you will evaluate your options. Are you solving for Time to market? Cost to develop? Revenue impact? NPS impact? And please don’t say “all of the above.” No way! Prioritize. Without clear prioritization of your criteria and getting agreement on that prioritization, you’ll end up where you started; Everyone with different opinions and no one wanting to commit to a decision. Or even worse…giving you the “nod” only to overturn the decision later.

It’s always good to articulate what you are solving in terms of a business or customer problem or as an opportunity with a clear definition of success. In addition to this, I always list the criteria by which the options will be evaluated. Define what they mean and show which are most important and why. Help bring your audience along so you start the discussion at a level playing field, so to speak. If you don’t have agreement on this, then there’s no sense in continuing the conversation.

Action Item 2: Does your approver AND your C’s have a consistent definition of the problem you are solving and the most important criteria by which you will be evaluating your options? If not, establish this now. Document it and bring it to your next decision meeting…start the meeting with this. First page of the deck should always be a reminder of what you are solving and how you are deciding.


Tip 3: Gather the data you do have…Put stakes in the ground where data is missing.

I can’t tell you how many times I see teams paralyzed by “lack of data.” Let’s be clear…YOU WILL NEVER HAVE ENOUGH DATA. The idea is to use what you have and clearly call out hypotheses where data is lacking. Then build (and communicate) a plan for validating/disproving your hypotheses. We use “proxy” data a lot to triangulate on a solid hypothesis. For example: If you don’t know what the usage is in terms of user sessions by day, look for indicators like backend transactions or records created by day and develop a hypothesis for usage based on what you do have. Or how about this one? You don’t know the top drivers of churn in your business, then find out the task drop out rates using the system logs and understand the top support team contact drivers and make some hypotheses about what part of the experience is creating the most pain. It’s not fool proof, but it’s better than thrashing around in the data-free zone of opinions. You have to start somewhere. And data is the best place to start.

Another way to use data is to try understanding the worst or best something could be based on what you have. “The best our penetration could be in this market it 40% because 60% of this market is comprised of vertical a, b, and c which we’ve learned can’t use our product or have higher on-boarding costs, or….” Provide the starting points for deductive reasoning.

Instead of being paralyzed or attempt an opinion-based discussion, find what you can to put a solid stake in the ground or put some guardrails around the decision, so your team can confidently move forward. Be clear on where you are hypothesizing and what data you are using to make those hypotheses.

NOTE: Don’t forget to provide the team with a plan for how you will prove/disprove each hypothesis. This gives your most vocal naysayers comfort in committing to a decision (that they may not agree with, but understand how you got there) while knowing you are going to prove/disprove the hypotheses with actual data. In their minds, it means that if you are wrong, you’ll let them know and they won’t be left expending a ton of effort against a direction that is fruitless.

Action Item 3: Are you in the middle of an opinion-based decision process where you feel you don’t have enough data? Identify alternative data points and hypotheses that can help with putting some stakes in the ground that provide guardrails on the debate and guide your team to a more efficient, confident decision. I always have a page in my deck or a set of bullets in my email that talk about key hypotheses or helpful data points that minimize unnecessary debate.


Opinion-based decisions are painful and costly to the organization.  These are a few really quick changes you can make in your process that make a world of difference in terms of efficiency and durability of decisions.  Happy decision-making!


Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies small and enterprise level in the skills and frameworks that help product management leaders and product managers deliver kickass customer experiences.    We have a passion finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

Following Tail Lights into a Ditch

Okay, dumb metaphor but I gotta say, a lot of the training for product managers out there is pretty misleading and doesn’t get at the heart of what product management is all about. And having more and more aspiring product managers following the suggested training that I’m seeing, feels very much like following tail lights into a ditch.

I just got done reviewing another training program and found it totally disheartening. Why? Well because it seems to be touting skills that, yes are important, but that completely overshadow what’s required to be successful in your job as a PM. For all you aspiring and new product managers (and even for some experienced PMs that have gone through some of these less-meaningful training programs) listen up! Here are 3 foundations that if you aren’t well versed or don’t have a natural inclination to set before any project you embark upon, then your projects will experience constant decision delay, unnecessary rework, and customer dissatisfaction.


Most decision overturns & delays, excessive re-work, or just plain unhappy customers are driven by a lack of shared vision around the problem. Each person on the team has a slightly different take on what the customer problem is and therefore a different take on what it means to solve it. Most training programs don’t tell you this nor do they help you build muscle to avoid this situation.

Without actually documenting the problem you’re solving in a way that clarifies what you are and are NOT solving for, slight variations in understanding will creep in and cause major havoc on the team. Vidya and I have often asked product teams to individually write down the problem for which the team is solving given a feature, a new product, or change in an existing product. Most of the time, we find that there are at least 2 people on the team that have different definitions of the problem and therefore have been advocating specific features, design elements, tradeoffs, etc. as a result.

For instance: What if you worked for a hand tool manufacturer trying to redesign your hand drill. You’ve been solving for a quarter inch drill. But guess what…The problem is not a quarter inch drill, it’s solving for a quarter inch hole. And what if it was for a quarter inch hole for hanging a 20 pound canvas? Or a 20 pound canvas on a concrete wall. Imagine if each of your team members believed you were solving for a different problem in this list. Getting agreement on functional and design prioritization would be troublesome to say the least.

Our point? As a product manager, your goal in every project is to start with a clearly defined problem that your entire team (including your leaders) has shared vision around. If not, you’re going to experience challenges every step of the way. So make sure any training you choose makes a point of helping you get to the root of the customer problem, effectively communicating that problem, and getting to shared vision with your key stakeholders around said problem. This encompasses research techniques, effective problem definition, hypotheses testing, and communication and influencing skills that many programs don’t spend a lot of time on.

#2 Defining the Target Customer

NO DUH! But I have to be honest. A lot of product management training curriculums breeze through defining the target customer or building a persona. Too often we see the target customer (persona) defined with demographics, with job descriptions, and with a couple likes or dislikes. They go into a lot of depth on market sizing, and analytics, but not in building an actionable persona.

Defining your target customer takes extreme empathy and should be enlightening and ongoing. Bringing that target customer to life, with day to day activities, but also with the relevant beliefs, attitudes, and the relevant traits that make product decisions possible.

For instance: Here are some ‘trait spectrums’ that I purposefully listen for and consider when I’m defining a target customer for software applications.

  • Organized <–> disorganized
  • Analytical <–> creative thinker
  • Tech savvy <–> tech phobia
  • Quick learner <–> slow learner
  • Confident in his/her ability to complete the task <–> no confidence
  • Patient <–> impatient
  • Extravert <–> Introvert

Depending on where your target customer sits in these spectrums will you would choose different design approaches and make different tradeoffs and even choose different vernacular in the experience.

There are many other traits that can and should be considered across different experience types (retail experiences, consumer packaged goods, etc.) The point is, it has nothing to do with demographics.

So make sure you find a training program that spends time on defining your target users in ways that are actionable in product and design decisions. This includes research techniques, actionable persona development practices, testing practices, and UX partnership skills.

#3 Contextual Customer Needs

This one is a little more elusive than the other two, I realize. So I’m going to jump right in with an example.

You are a wagon manufacturer. And there are a ton of design elements that need to be considered. Wagon size, turning radius, wheel size, wagon material, etc. The list goes on. In order to make the right design/feature tradeoffs, you’d need to know a little bit more than the problem and who you’re solving the problem for. So…

Customer Problem: I often have to make many trips carrying loads of stuff from my apartment to my car in the parking structure, which is a total hassle, can be painful, and often makes me late; especially when it comes to groceries and weekend recreational activity stuff.

Target User: People that live in urban environments that are weekend warriors (This is the short version, you’d define the intimate details now that you’ve learned a little more about how to define your target ;-))

You say, great! I know what I’m building. Hold on a minute. What if your research surrounding the problem yielded the following needs in this order of priority:

  • My parking spot isn’t close to the elevator so I have to carry my load a ways
  • Parking spots in my garage are tight; I need to be able to maneuver around my car and between cars
  • I have to store this in my closet because I use it so often and don’t have storage living in an apartment building
  • I’m usually carrying at least 20lbs+ of odd sized stuff including groceries, ice chest (that is sometimes wet,) big water containers, camping equipment
  • I’m often carrying my stuff on the sand and dirt and gravel to get to my destination “spot” (campsite, park site, beach site, etc.)
  • I have to maneuver in and out of my elevator with lots of people

Okay, now tell me if those needs don’t help you better define the solution! Clear tradeoffs emerge…right?

Without the relevant needs surrounding the problem, how do you prioritize features or make design decisions? Most product management training programs struggle to address the importance and art of these 3 foundational elements to product management..

There are some great UX programs that get at this but I’m a bit old school and believe that the product manager is just as much responsible for intimately understanding the customer and problem space as is the UX person…if not more… because the product manager must evangelize and get commitment from the organization on the resulting product roadmap and requirements. Without having that intimate understanding, getting shared vision by cross-functional organizations is almost impossible.

Bottom line here: Make sure the program you choose comes from successful product management leaders that have demonstrated their ability to define a kick-ass customer experiences that drives business growth. Make sure they enable you to set the most important foundations to any great experience. Without that, I’m sorry to say, you’re following tail lights into a ditch.

Check out our product management bootcamp if you’re interested in learning how to build the muscle around these foundational elements of product management.

So you want to move into management?

As I write this, I’m thinking about leading two upcoming discussions on how to move into product management leadership. I’ve promoted dozens of people into senior management roles, and I’ve been thinking about what made them standout as potential managers, and what made them successful. The good news is that being a great product manager trains you already with so many of the skills to move into a management role –  being the face of the team, working with many groups, influencing to get the job done etc. So, what does it take to standout from a bunch of standouts? I want to share some interesting patterns of behavior that we implicitly look for when we have those closed room discussions with HR about who’s going to get that precious manager role. I’m going to assume all the basics are already in place: right tenure, consistent high performer, track record of delivery. If you’ve got all that, then there are some intangible ingredients that I want to shed some light on:

  1. Communicating like you’re already a manager. Often, being a great product manager means that you can communicate really clearly to your teams, and to your customers. This is table stakes. You have to be able to break down a vision into a clear roadmap, and then into workable chunks, and then into specific user stories. Product managers have this down – they know how to communicate what they want their teams to build. They’re also great at talking to customers – listening well, asking great questions, translating what they hear into needs. But being a people manager, and working with other senior leaders, entails taking all those skills and creating a different picture. Often PMs go into a ton of detail, they want to explain the work they’ve done, after all it was a ton of effort. But leaders don’t want to hear those – they want someone who can connect the business goals to the work being done in a way that makes sense. To be promotable, you have to be able to do this – it’s not a skill that execs are patient to see you grow into. If you can’t succinctly explain what you do and why it’s important for the business, you can’t get the right resources for your teams, and you can’t succeed. So spend less time explaining all the details, and more about telling a story, and connecting the dots.
  2. Working the strategy Say/Do. This shows up as how you make decisions, and how much time you spend talking strategy and actually backing up what you do with the bigger picture in mind. Product managers are expected to understand the big picture – it should reflect in their roadmaps and customer documents. But how much do you actually follow this? Someone who has “leader” written all over them is the person who asks great questions about prioritization based on strategy. Who constantly starts backlog meetings (yes, backlog!) with the bigger picture in mind. It’s not just a question of knowing the company strategy & goals, it’s how you bring them to life in the way that you work every-day. Knowing that the person you’re about to promote already “gets it” goes a long way in setting them up for a manager role.
  3. Feedback loops.  People who are going to be good managers ask for feedback. A lot. They ask after meetings, they follow-up with senior leaders, they make a point of understanding how they show up. And then they take that feedback, try something new, and then ask for more feedback. You’d be surprised how little people do this. They wait passively for 1-1’s or monthly meetings – or even, worse, their annual performance reviews. When you can see someone is actively understanding how they show up, and are genuinely interested in improving themselves – you know that they will help others do the same – which is what you want in a people manager.

Do you still want to be a manager? Are you doing these things? We want to hear – write to us and share your stories of promotion, or trying to get promoted.

It’s Product Roadmapping Season! Get some quick tips…And a helpful framework for the process


For many of us, roadmapping season is starting or about to start

We’re coming up to the end of the year and embarking on our new year.  And every year we walk into roadmapping with just a little dread. “Ugh, another 2+ months of research, debate, and planning gymnastics!”  “No one looks at it!” “By mid year, it’s blown up anyway!”

I’m here to tell you that if you approach it with the right principles and effort, the roadmap can be a great ongoing galvanizing operating mechanism in your company.  It can actually help you avoid shiny object syndrome too!

We should start with a couple basics…

Definition of Success of a Product Roadmap: 

  • Enables the business to achieve it’s goals; on time, within expectations
  • Provides a way for the entire organization to understand the prioritization, timing and relative sizing of solving major customer problems
  • Drives long term platform development scope & timing

We presume you have a documented business strategy and objectives that are used as a rudder throughout this process.  If not, we tell all our product managers…propose them and get agreement, so that you can build a supportive product roadmap.  I say that loosely, because it’s not that easy.  But without business strategy and clearly defined objectives/measures, what are you aiming for?  We have an online course for facilitating the definition of both if you find yourself in this position.

Okay, now for the main act…Here are some tips in achieving roadmap success:

Start with the Customer

No duh. Right?  Well, lets step back a second.  For many, this means “let’s do the features that our customers requested.”  That is not what we mean here.  Instead, it’s making sure that you have clear persona(s); personas that your team/company has agreed to.  This is not easy.  But if done right, you can actually ward off shiny objects that address problems of customers outside your persona sweet spot.  Having a clear persona helps people understand who you’re NOT going to solve in your roadmap as well.  We’ve got a couple posts on our blog about personas…try this oneContact one of our rebel leaders if you need a simple template that works!

Clearly Define Problems You’re Solving – Your Roadmap Themes

Most roadmaps are organized by 2 dimensions…time being the obvious one…and themes which are basically problems, strategies, or objectives for the business.  Each theme should be solving a very clear customer problem.  Having a clearly defined problem statement will help galvanize your team around what you are and are NOT solving for.  Having clear problem statements will help ward off shiny objects as well…”Hi Mr. shiny object thrower!  How does this shiny object serve the problems we agreed to solve in our roadmap?”  Most of the time you get “Well…uh…hmmmm….You’re probably right.  Let’s table it for now.”  The persona and problem statements help you justify tabling a shiny object.  If you don’t have those, it’s easy to get into an opinion-driven debate that usually ends up with that shiny object being added to the pipeline and other important initiatives are delayed or worse, never completed.

Facilitate Innovation/Design Thinking

You may already have clarity on target persona and a clearly defined problem AND a previously discussed set of initiatives that serve both.  Hopefully they are fully agreed to by the extended team.  But if you are questioning any one of those inputs or if you don’t have a shared vision on those inputs, then I would step back and ensure you are flexing your design thinking muscle.  Problem-driven brainstorming (with choice-ful attendees…creative minds, market experts (internal or external,) customers, partners, etc.) and other design thinking techniques will ensure the most impactful ideas are considered vs. just the squeaky wheels.  A quick set of customer interviews (5-10 targeted interviews can do wonders,) a brainstorming session, and a vote will drive far more committment than status quo thinking or focusing on the “sacred cows” in the organization.

Build Shared Vision…and Commitment

As a product manager, you’ve probably felt the pain at one point in your career of a lack of committment to the product roadmap…either someone from your leadership team, your development team, or your design team doesn’t agree with the prioritization or existence of some initiative and it makes it a painful process every time you have to justify it and ensure it’s given the attention it requires to be successful.  We’ve all been there.  Your job in this process is bringing team members in at the right time…Providing them the customer context (having them hear from customers directly is even better,) getting their feedback and hearing what their dependencies or concerns are, getting their ideas, agreeing on the criteria for prioritization of themes/efforts, etc. …And ensuring they are onboard before the final presentation of the roadmap.  Ideally, your development and operational leaders are standing beside you when presenting to the leadership team and show as much ownership over the roadmap as you do!  Yes, I have experienced this myself!

Understand ALL Your Critical Path Dependencies

Most product managers guess at their dependencies or don’t cover them all.  This is just a word to the wise.  Go through your draft roadmap with your major partners to get their input and understand what they’d have to do (development or otherwise) to ensure the initiatives can be successful in the timeframes you are expecting them to be.  As what their biggest concerns are or believe to be the biggest risks.  You’d be surprise at what you learn by going through your draft roadmap with your teams beyond just the dev team… support, operations, marketing, IT, etc.  We always think about it in terms of inputs, process, and outputs.  What are the input decisions, development, or partnerships required to begin the dev on any given initiative?  What is needed to actually develop the functionality; 3rd party software, partnerships, critical-path platform tech, etc?  And what needs to be released or ready by the time that functionality needs to be in market; partnership support teams, partnership technology or marketing, marketing technology, packaging, etc?  Think beyond mainline platform dependencies!

Ongoing Management

Once complete, we usually have a couple versions…one that’s all polished and summarized for the leadership team and one that is used for ongoing discussion as we learn more and have ongoing discussions with our core team.  We recommend reviewing the roadmap every month or two to ensure you’re managing the backlog accordingly and you’re communicating any major learning and associated pivots in the roadmap to the leadership team.  You can also use the roadmap as a tool in shiny object discussions.  “You want that shiny object added?  Are you willing to push this theme out X months for it?”  When you can have a discussion about the implications of a shiny object as it relates to a roadmap that the entire team helped build, you avoid opinion-based discussion and ensure you are doing what’s best for the customer and business.  It’s a much easier discussion.

Don’t have a clean process to take into account all these best practices?  We have a process framework that has worked for us. It’s a ratty ol’ powerpoint, but its a proven process that enables the most targeted, impactful, and committed roadmap.

Happy Roadmapping Season!!



Defining the PM job

We see this picture of PM  in the middle of UX, Tech and Business a lot:

From Mind The Product (

We use this graphic as well – it’s been a nice, introductory way to speak at a high-level about the product management function, and it highlights the importance of partnering with these three important peer functions. Product management works with business leaders/marketing teams, engineering teams and UX teams. They sit in the middle often translating from one to the other. But we’ve found this picture hasn’t been sufficient to talk about what the actual day-day job of a product manager should be. When you introduce a graphic that describes the function as this small overlap of a venn diagram – it discounts the sheer amount of work and knowledge that’s required to actually do the job.

So, we came up with a new graphic:


This may not be the best drawn diagram, but we want to introduce it as a better way to talk about how a product manager should approach their job. We think this is far more representative of the actual  work that we all do on a year-round basis.

The outer circle goes to business. The product manager has to start with a broad and deep understanding and translating company vision, strategy and business objectives. These are the guardrails of our thinking – and we always need to go back to making sure that the decisions and tradeoffs we make are the right call for the business, industry and environment that we work in. We’ve seen lots of features go into products that customers ignore because they don’t make sense with what the business and the customer is trying to achieve.

The next inner circle is technology. This goes beyond partnering with the engineering or development team. The product manager doesn’t (often) code, but they (should) understand what the technology can/cannot do, understand the technical architecture and be able to ask the right questions, and have an engaged and knowledgeable discussion about alternatives. Without getting deep into the technology, the product manager is at the mercy of whatever technical recommendation is made. We’ve seen far too many product leaders and teams fail because they didn’t ask the right technical questions, because they weren’t prepared and didn’t dig deep enough. Technology is a core part of the job – better get used to getting into the details.

The core of the job is customer. Every part of the job is customer-driven. Whether that’s considering the product roadmap (what’s important to the customer), writing user stories (customer needs), doing customer research (talking to customers) – we could go on and on. Every single piece of work that’s produced is with the customer at heart. The product manager represents the customer at the table – they advocate for the customer, deeply understand their needs and ultimately make product decisions with the customer first, with the optimal technology and meeting business objectives.

When you look at product management this way – we believe you get a sense of how the pieces fit together and a better understanding of the expectations of the job. This isn’t a job for sissies!

Let us know what you think! We’d love to get your comments here, or send an email to and tell us how you see the PM job.

Persona Pitfalls


Okay, everyone says they know who their target customer is…Many even say they have personas.  Where does your team fit here?

Here are common pitfalls we see in most companies as they relate to effective personas (can you say “That’s us!” to any of these?):

  • Focused on demographics – age, location, occupation, etc.
  • It’s made up by an external vendor
  • Your team has a couple documented, your UX team has some, there’s one the research department created….point being there are a few and not all consistent.
  • Aren’t considered in day to day product decisions
  • Cost a lot of money for beautifully designed artifacts (designed to be displayed)
  • Lengthy (boring) descriptions or multi-page persona’s
  • Haven’t been updated since being created years ago.

Does any of this sound familiar?  It’s okay!  It’s normal.  We often don’t know how to build practical personas and understand how to use them on a day to day basis.

Here are some tips to apply tomorrow:

  • Try using a template that works.  Here’s one we’ve created (and have a whole workshop around.)  Contact us if you’d like to take our course.  Other templates work too, but make sure they aren’t exacerbating the problems mentioned above.
  • Focus on behaviors and attitudes that are relevant to the task/problem you are solving… leave demographics for last if at all.
  • Work with your broader team to finalize (don’t do this in a vacuum…include dev leaders, UX team, and research team members, if applicable.)
  • Find a picture that best represents that persona.  This will be the most memorable thing about the persona and what gets used most.  Make it a good one.  With a relevant background environment, facial expression, clothing, tools in hand, etc.  Check out a really great example of visually oriented personas
  • Post them up where everyone can see/utilize.  See examples of how some companies have done this.
  • Treat them like participants in a conversation when making product decisions…”Would [your persona’s name] actually find this valuable?  What’s the problem she/he is facing and what’s the context impacting the solution we build?”  Here is one example we use in our workshop that highlights a real world example of utilizing a persona in choosing a feature/design direction for an area of a small business software application.

You’d be surprised how many companies believe they have clear target customer definitions but when we poll the entire team (product managers, UX team, engineers, etc.) we get different definitions across the teams and different opinions about how/if those definitions are adhered to in decision making.  That makes getting product decisions made quickly and in a way that “stick” almost impossible.

Start by polling the team… are you all on the same page?




Turn the Negative into Focused Action

Did you know…

  • Americans tell an average of 9 people about good experiences, and tell 16 (nearly two times more) people about poor experiences. [Source: American Express Survey, 2011.]
  • It costs 7x more to obtain a new customer than to keep an existing one.
    [Source: White House Office of Consumer Affairs]

What is the number one reason your users speak negatively about your brand?  You probably have heard many reasons, but are you acting on the issues that will impact your growth most significantly?

Effective product managers always know what their top drivers of negative comments / pain.  As such they are making sure that those top drivers are known and are reflected in your roadmap and backlog appropriately.

Our experience shows that most product teams come across negative comments all the time but rarely understand how to act in a way that will impact the company in a positive way in the long term.  Instead, the team is reacting to as many negative comments as possible in the shortest amount of time possible.  The CEO says, “I just saw this comment on my twitter feed, we need to fix it.”  The division Leader comes to you and says, “My friend told me he hated this part of the experience, how do we fix it?”  Don’t even get us started on what your poor technical support team hear or online listening posts tell you.

Product managers are usually left with a plethora of negative comments and pain points coming in from colleagues, social media, customer support, and leadership team. It’s overwhelming!  You brainstorm around potential fixes,  juggle to get them into the backlog, and generally don’t have the justification necessary for why one fix goes in before the other…leaving the CEO, division leaders, and other “messengers of pain” left wondering why you’re not fixing their issue.  I, personally, used to feel deflated because I never thought I was doing enough.

Well, let’s re-inflate!  Let’s talk about a quick approach to building your confidence in making the most impactful prioritization decisions and keeping your “messengers of pain” abreast of the smart decisions you’re making!

Remember, this isn’t about being 100% accurate, it’s about having a practical approach to sorting and moving forward with a rationale your leadership can get behind.  You will never be 100% right…

  1.  Get Feedback:  Make sure you asking a summary feedback question through survey, interviews, and/or service calls, that helps you understand who’s happy and who isn’t.  We are huge advocates of the “likelihood to recommend” question (often referred to Net Promoter,) but if you ask “how delighted are you…” or “how satisfied are you…” or some version of those, you’re halfway there.  All we recommend is that you ask this question the same way across your key user listening posts (those with the highest volume and most representative of your primary user segments.)  No duh, you say?  Well, you’d be surprised…and hang on…There’s more.
  2. Ask Why:  Make sure you are asking “why” if they’ve responded negatively to that question…Do this through an open ended follow up survey question…a question at the end of an interview or service call.  Just get the qualitative reasoning behind the negative answer.  For those of you that don’t get this kind of feedback, you’re not alone and you’re still okay.   (Pssst… It’s never too late to get started.  We’ll cover that in future blog posts.) Instead, talk to people in your company that have firsthand conversations with your users.  Your customer service/support team, your marketing/social media team, your product management team, and your sales team are all listening to your customers at different phases of their experience.  Bring them together and listen to them discuss what they believe to be the big drivers of pain and negative comments.  Give them a chance to tell you what they believe are THE top 1-2 issues and why.  Then use the data you do have to validate and further prioritize…If your social media team is seeing a few comments a day out of 1000 followers vs. your service team seeing 200 support calls a day (many with clear negative feedback,) you can use your judgement in deciding which one to prioritize.  You’ll also find that you’ll get consistent feedback across listening posts.  Those are the gems!
  3. Categorize:  Take the open ended answers across all your listening posts and LOOK AT THEM!  We can’t tell you how many companies that have a boat load (technical term) of rich open-ended responses, but don’t know what to do them.  Take the data across different listening posts and dump it into Excel.  Categorize it. (Yes, this is very subjective, we realize, but unless you have deep pockets and years of runway before you have to make a tradeoff decision, this is all you got!)  Remember to remain unbiased through the process.  Your categories will change as you get through more data. So remain open and evolve your categories accordingly until they are most representative of the sample(s) obtained.  Make them as mutually exclusive as possible until you get to the end.  You can then review each mutually exclusive category and parse those into subcategories if necessary.   This is time consuming depending on how much data you have, but anyone can do it over coffee each morning for one week and have a very solid outcome.
  4. Turn it into Actionable Information:  Once you’ve summarized this data, get it ready for a discussion that drives shared vision with your teams.  Rank order the categories based on volume within each customer segment.  Provide a clear list of prioritized issues.  For those top issues, use the sub categorization (or create hypotheses) to clarify what the issue means in terms of root cause. Bring the data to life by bringing in actual quotes for each that represent that root cause.  Define the next steps for each major issue.  It might be further research into understanding an cloudy issue or taking action on those issue(s) that are clear cut.  Circle back to the pet projects from those messengers of pain and where they fit into this new found education on top pain points.  Will any of them neutralize or turn the most important negatives into a positive?
  5. Present and Discuss.  Bring your teams together, leadership included, and show what you’ve learned.  Help them understand the top drivers of pain and negative comments and why you have prioritized the product initiatives the way you have.
  6. Act.  Create the user stories, get them into the backlog, do the follow up research on those issues that aren’t as clear but are high in volume.
  7. Rinse and Repeat

This is scrappy and it’s also subjective.  But in most cases, we product managers don’t have millions of records of data, automated AI tools, or analysts laying round waiting on our every command.  And we have to make decisions quickly and effectively.  This is a practical way of developing an educated gut for tradeoffs we have to make every day.  It’s a way of enabling you to focus on the most important negative comments/pain points, neutralizing the negative or possibly turning it into the positive.  It provides air cover for the pet projects of the week.

You want a resolution that guarantees results?

Now that it’s a few weeks past New Year, and we’re back heads-down hard at work – let’s sneak in a new year’s resolution that will make a real difference. Commit to talking to your customers at least once a month. That might not seem like a lot to those of you who are planning customer interviews weekly, building them into your sprints and calendars. However, for many of you, we know months can go by without reaching out. We’ve worked with a lot of company’s last year – some large and some in very early stages, and we’ve been shocked at how many don’t talk with customers regularly. It doesn’t matter how established the company, the attitude towards interacting with customers, getting their feedback and acting on what you learn is a habit that’s formed and established by the product leader. If the discipline isn’t introduced, then customer interaction doesn’t regularly happen and acting on customer feedback becomes an ad-hoc activity, usually something to consider when things go very wrong. The start of the new year is a great time to hit refresh and think about how you’d like to establish new important habits. For your product and team, there’s nothing that will make more of a difference than creating a new practice around regular customer interaction. Whether you’re testing a new idea, building a prototype, or launching a new feature – make sure that a customer test gets built in. Put it into your planning, write it into your calendar, make this a resolution that you can commit to.

Influence & Talking to Customers

Recently, we gave a talk at a big product conference. We talked about influence – how product managers need to exercise influence more than most. After all, we are usually individual contributors, accountable for a product -needing everyone to align and work together, but not directly managing anyone. This conference was in Eastern Europe so we were particularly interested in hearing the questions – was it the same situation for product managers across the seas, as we’d experienced in the US? Who were they most trying to influence? Our biggest surprise was where the majority of the questions centered – the frustration for product mangers to be “allowed” to talk with customers. The area where product managers most wanted to exercise influence was with their managers trying to getting access to customers!!

This wasn’t a one-off question, the majority of people who asked us questions during the talk, and then after at our booth – was all centered around this critical need. One that we take for granted – the ability and access to connect directly with customers. We wanted to share some of the tips & ideas that came out of these conversations because perhaps more people than we realize are in the same situation. Wanting to follow best practices in iterating and getting customer feedback, but finding themselves unable to do so. Here are a few of the ideas we discussed.

  1. Use a proxy. When your customer is 5,000 miles away, watching what they do is not a readily available option. For one PM, they were building a system for a library and really wanted to understand behavior and interaction with their app. Our suggestion? Find a local library and talk to the people who were working and using library services. After accounting for cultural changes – what are the main questions? What were the surprises? How could you use your findings to show the importance of understanding local behavior.
  2. Start with a Hypotheses: When you can’t get to customers, it’s really helpful to form a strong hypothesis – one that is very specific, measurable, has an outcome that can be tested. Rather than continuing to write user stories in a vacuum, figure out what you believe to be true – force yourself to confront the biggest unknowns you have, and then look for ways that you can quickly and cheaply test your assumptions.
  3. Use remote tools: While we don’t like surveys very much – it’s better than nothing. Can you put together a more comprehensive survey that gets to people’s attitudes and beliefs? Recently, we conducted a large survey that was based on earlier market segmentation. In that, we looked for people who were lapsed members. Adding a question at the end to see if they were open to a quick conversation, is an easy and cheap way to find customers who will talk with you. Then use skype to connect with them – fast, cheap!
  4. Get scrappy. When you can’t find your exact type of customer, in the same industry – getting any feedback is preferable to none. This is where you rely on friends & family to give you their perspective. Still go through the process of writing a learning plan & have your objectives…see what surprises come up. Don’t dismiss their feedback too fast if they don’t “get it” – this could be an indication that there’s an issue or gap in your thinking about your product.
  5. Seek forgiveness not permission. This isn’t an option we readily recommend, and our least favorite…but in some cases, when you are just not given time to do customer research – you may have to resort to some stealth interactions. Go outside your regular working hours to talk to customers – slowly start feeding ideas from customers into your meetings. In particular, share insights that came directly from a customer interaction to show value. Sometimes you need the proof before you get the permission.

Tell us what you’ve done when you’ve struggled with getting customer feedback. We want to hear more tips & methods – what’s worked and what’s not? Leave us a comment now.

Sitting in Your Customer’s Shoes at least 30 Minutes a Day

Sit in your customers’ shoes for at least 30 minutes a day.

Looking at customer satisfaction metrics is great, but isn’t enough. We also really need to hear their voice and/or see them in their own environments; using your product.  And this needs to be on a regular basis, not just saved for the periodic qualitative research effort.

Set time aside each day or a few days a week to sit in your customer’s shoes.

Here are some ways to think about it:

  1. Pick the customers that are most important (that could mean a lot of things depending on where you are in your lifecycle… newest customers, highest paying customers, angry customers, etc.)  Don’t make this a massive thought or analytical exercise.  Just be conscious in your choice.
  2. Pick a channel of communication where you’re most likely to find that customer.  Again, don’t make this tough.  If you only have one way to contact or find a customer, then you have your answer.
  3. Choose 2-3 questions you want to get answered.  Be thoughtful about what you want to learn.  This should take no more than 5 minutes.   Examples:  “What’s the one thing my customer would change to make their experience worthy of recommending to others?”  “What is the one thing we could do to get you to use our product?”  etc.
  4. Get started TODAY.  Here are scrappy ways to get connected:
    • Take a support call or listen into support calls over your lunch hour
    • Read a customer email or feedback note… read a bunch over lunch or coffee
    • Set up a “Follow Me Home” (more on this method later) that essentially has you watching a customer use your product…live.  You can do this remotely if you don’t have a choice, but actually traveling to their home or place of business to watch them use your product is invaluable.  Doing that at least 1X per month will make you a significantly more effective product leader!
    • Sort and read through your open ended responses from your satisfaction or Net Promoter surveys (a bit more time consuming but so enlightening.)
    • There are many other ways to do this…pick one and go with it.  Test a few different ones until you feel good about the feedback your getting.
  5. The goal is to get qualitative insights around the key questions you are dealing with around the product.  Adding the necessary context around your quantitative data.

Set an example for your team.  The better you know your customer, the more effective at problem solving, and therefore, delighting, you’ll be.

Keep delighting!