Customer-Driven Development — An Interview with Patrick Haig, Product Director at TUNE

As part of our Customer-Driven Development series, we had the opportunity to chat with Patrick, Product Director at TUNE. Patrick’s relentless focus on understanding customers’ problems and measuring progress is not only inspiring, but also in line with a new generation of product teams embracing better ways to put the customer at the center of the product development process.

In this interview, we talked about how he engages his team with a new way of working and the mindset needed to make change happen. Enjoy!

Sofia: Why don’t we start by talking a bit about TUNE and your role there?

Patrick: Sure. TUNE, in its DNA, is a mobile measurement company. We aim to make all marketing, performance marketing easier. It started with HasOffers, a platform that helps ad networks manage and measure offers. From there, TUNE developed and released an attribution product to help marketers measure mobile app install campaigns in order to really know the value of users they acquire through specific channels. Both products were the first of their kind.

Today, the business comprises two major offerings: HasOffers, mentioned above, and the TUNE Marketing Console. I sit on the TUNE Marketing Console, which is a marketing suite that has grown to focus on three product areas: attribution, organic acquisition, and engagement.

I’m one of TUNE’s directors of product and have been with the company since 2014. It’s been a crazy path. After having dropped out of law school, I went from client-facing roles at the startup I previously worked for (which TUNE acquired in 2014), to a product manager role, and now to a director role.

Sofia: We talked to a lot of product teams and each of them has a very particular view on what customer-driven development means. What does it mean to you?

Patrick: I think it’s putting the customer at the center of nearly everything. For me, it’s about making sure that what you’re building measurably solves customer problems. You need to continuously make customers’ lives better. That, to me, is customer-driven development. When you are not paying attention to customers, it hits you in the face. You have to continuously try to put them at the center of your decisions.

It all starts with humanising the customers by helping other teams develop empathy for the customer’s problems. It’s a virtuous cycle. Once you start involving other teams, whether that’s by sharing behavioural data or customer feedback, you can’t help but notice the excitement and their willingness to know more and contribute. That alone drives more conversations about customer problems and helps develop customer centricity even further.

People building products love to see customers using the product, and they love to see that it’s actually helping.

Sofia: What do you think most product teams get wrong when it comes to customer feedback?

Patrick: I think there’s a danger in relying too much on customer feedback. In my experience, it comes down to having a proactive product strategy and vision versus a reactive attitude.

Once you understand the problem you’re trying to solve and have enough clarity, you can take the feedback and map it against that plan. I think that kind of forces you to think, “Oh, okay, that feedback does touch on something, but we weren’t planning on doing that for X number of months, so we’re not going to do it until then,” or, “Actually, that doesn’t fall under anything that we want to do.” Then, “Let’s briefly explore whether that’s something we want to do, but not spend too much time on it and say ‘No, sorry, customer — I hear you with that problem but that’s not something we are prepared to do.’”

It’s important to have a product strategy in place instead of letting customer feedback create your product strategy, but you absolutely have to listen to it as well. Customer feedback should be the starting point for conversations, and it should enable you to identify areas you want to understand better.

Sofia: How did you get started with this process? How do you go about helping your product team and the rest of the business become more customer centric?

Patrick: It’s definitely been a learning experience. Everything started with a very specific problem within TUNE. We had variety of channels through which we would get customer feedback. It was coming from salespeople and account managers. It came from support, it came from conference trips, and it came from UX studies. All this feedback was coming from everywhere and going nowhere. Well, it was going into Google Docs, or Confluence pages, or it would be sprinkled in a conversation and scribbled in a notepad, but it was never centralized. It was never discussed in a large, meaningful way. Thus, it was never quite internalized and acted upon.

We used NomNom to centralise our data, but once we had everything in one place, the biggest challenge was building a process around it.

Getting cross-functional executive buy-in was essential. We worked to get buy-in from product to UX, and — to a degree — engineering. We also involved support, sales, and client success. We had all these teams brought in at the executive level so they could start driving these efforts with their teams.

For example, it was actually a goal for every client success manager to send in at least two pieces of feedback per week, globally. That was great. Sales started doing it too.

Once the data started flowing from different channels in a more intentional way, we decided to create a weekly meeting where we discussed the latest findings. It started with just the product team, but now includes product, UX, engineering, sales, and client success.

One big thing to come out of these conversations is a huge thirst for those teams to share the feedback they hear from customers and to know what the product team is doing with it. Internal teams want to know that they’re heard and that their customers’ needs are also being heard. They know the product team may not necessarily act on all feedback shared, but now it’s front and center.

Previously, it felt like a black hole. The product team would have its roadmap, feedback would come in, and then nothing would happen. Not even discussion. So that’s where we are today. We are making a lot of progress towards transparency.

Not only do we discuss feedback weekly, we also send an internal company-wide product email every two weeks where we detail what’s been shipped, what’s about to ship, and any success metrics around anything that was recently shipped. Then, at the bottom, there’s this massive section of trends within our customer feedback and quotes.

That email has been a great conversation starter. The replies I get to that email are fantastic. They might be like, “Oh, you know, I’d like to add three more customers who have said that exact same thing,” and then I’ll send that in. We also hear engineers saying, “I love seeing this. Thanks for sending this out,” which helps them engage that much more with the product they are building. Establishing this type of feedback loop with customers and internal teams has had a lot of direct and indirect impact.

Sofia: It takes a lot of leadership skill to drive this process. You had to not only introduce a new way of working, but also build a very cohesive culture around it. I’d love to dig deeper and understand how you went about it.

Patrick: I think it was about having an open-minded, positive attitude — a bit like, “Hey, let’s just try this.” There was zero risk. We had already come from a place of risk because we didn’t have any of this data centralized or aggregated. We weren’t doing anything about this problem, so we needed to act.

But not everything I proposed worked. We had to redefine the goal of our meetings, the way we organised our data, and how people interacted with it, but I was clear that it was going to take time and several iterations. We’re still working on it as we speak.

Sofia: Patrick, what is your advice for any PM out there who wants to improve her process and help build a more customer-centric culture?

Patrick: First, I’d say get executive buy-in, whatever that means for your company. You will change how people work to a certain degree. Even if it’s a small degree, it’s still going to be change, and some people are going to be resistant to it, even if it is well-meaning change.

In terms of building a more customer-centric culture across your team — oh, man. It will sound so simple, but just talk to customers. I have this little story that brought it home for me.

A colleague and I were in a fairly large meeting, and he messages me, “I haven’t heard the word ‘customer’ more than once this whole meeting.” I paused and responded, “Yeah, that’s actually true.” Isn’t that weird? That’s not how we want to be. So, the next time you’re sitting in a meeting — whatever meeting it might be — see how many times you hear the word customer.

If you don’t like what you hear, then change it. Be the one who brings it up. Be the one who says, “Actually, how do we think about this from the customer’s perspective?” Or, “How can we orient this to be more about the customer?” That, in and of itself, I think, is an attitude shift that can spread and that people can pick up on.

Then, of course, there’s the more tactical stuff, like actually getting on sales calls and having those high-level, exploratory discussions with customers about nothing in particular, but about everything. Even if it’s just asking them things like: What are your biggest problems? What are your priorities? That may mean working very closely with UX in a lot of in-depth studies. Make talking to customers part of your routine.

This was originally published on Medium.








7 Blog Posts That Will Change the Way You Think About Product Roadmaps

Product roadmaps are common fixtures in most industries and every bit as common as business plans. Every business has its unique take on the process and many try to establish their roadmap as a virtual competitive advantage.

Unfortunately, most fall into the same category as your average business plan — a pile of hopes with subheadings.

Here, we look at seven of our favorite blog posts on product roadmaps. Each post will challenge the way you think about planning and will offer a different view when it comes to executing your product vision. Here are the key takeaways:

1. Hope is a Four-Letter Word

“Remember, if you don’t have data, you only have hope. And none of us are doing what we’re doing because we hope it will work.” — Cody Simms, Executive Director at Techstars

Cody Simms, in his piece Why Most Product Roadmaps are a Train-wreck (and how to fix this), talks about how so many companies tend to fill in product roadmaps with arbitrary estimates and rough guesses.

Cody explains that, specially when it comes to board meetings, “Whether you are a CEO, board member, investor, or employee…EVERYONE knows that the roadmaps that are published in these documents are a joke. And yet, there they are. Every time. A random list of features with monthly or quarterly delivery dates assigned to them.”

The alternative? Focus on learning goals. Timebox experiments and feed the next sprint with more and better learning opportunities. We all like to design solutions, it feels good to have new ideas, the hard thing to do is to focus on customer problems and structure ways to learn more about them.

It requires some intellectual honesty to accept that we are all victims of inertia, that we tend to do things because they have always been done that way. The challenge is to purposely take the time to do the right thing.

2. Roadmaps Kill Creativity

“Your ability to pursue new great ideas as they arise will be seriously dampened when you’ve already committed to a tall stack of requests eagerly awaiting implementation.” — David Heinemeier Hansson, creator of Ruby on Rails

DHH wrote a piece on product roadmaps worth reading. It is called, You Don’t Need a Product Road Map, and it makes a solid case for how laying out a product roadmap can stifle your creativity as you try to balance the promises you’ve made to your customers and stakeholders with the learning you are developing as you evolve your product.

DHH explains, “When you sell the software that you actually have, there’s a limited amount of wiggle room to cajole prospects. Customers have to make real decisions about whether the current state of your software is a good fit for them. Sometimes it’s not. That’s okay. It’s better to turn customers away than to placate their instincts and lure them in with vague promises.”

It takes a lot of self-discipline to not make empty promises. The pressure from stakeholders and high paying customers is always high, but it is that self-discipline that separates good from great product teams.

3. Business Is War (Not Really, But You Can Borrow Military Hierarchy)

“Roadmaps derive from the old centralized command-and-control model. A bunch of stakeholders meet, usually quarterly, in a room to come up with the priorities and the projects for the teams for the next quarter.” — Marty Cagan

In The Alternative to Roadmaps, author Marty Cagan talks about why product roadmaps are so popular. He blames it on the need of companies to preserve business value and put deadlines in place. He advises using a product team model instead, envisioning the company as an army and the teams as individual platoons.

Marty explains, “I often encourage teams to look back over the past year and grade themselves on the success rate of their roadmap in terms of how many of the items actually met the business objectives. If you do this, and if you’re not proud of what you find, then I’m hoping you’ll consider this alternative. Ensure your product organization has a compelling product vision. Ensure that each product team has a clearly defined, prioritized set of business objectives. Make sure any commitments that must be made are high-integrity commitments”

Similar to Cody Simms points, the focus should be on building better team structures where autonomous learning happens, where the focus is about outcome rather than output.

4. Perspective Changes Everything

“Roadmaps solve for the company not the customer.” — David Cancel, CEO of Drift

In David’s post, When it Comes to Building Products, Agile and Waterfall Just Don’t Cut It Anymore, he discusses the value of shifting perspectives.

Cancel explains, “I’ve never believed in setting a public product roadmap. The problem with product roadmaps is that they often satiate company curiosity more than they solve customer problems… What solves for the customer is non-stop testing and a continuous improvement. Instead of having 2–3 releases a month, we’re shipping daily. This way, the customer could help us correct and iterate on our direction — not approval from an executive.”

We often hear that to succeed in today’s business environment we need to embrace uncertainty. However, it seems that nobody gets excited about it. Instead we spend more time moving boxes around in our Gantt tables.

Product roadmaps and all the logistics around them make us feel busy and safe. Learning how to learn surrounded by uncertainty is a better approach but far more uncomfortable that most people are prepared to handle.

“Every company in the world will tell you they are customer-driven. They’ll believe in the principle. They’ll have framed posters on the wall about it. “Solve for The Customer.” But none of that means anything unless you actually make the structural decisions to ensure it.” – David Cancel, CEO of Drift

5. Expired Before it Started

“In my experience as a product manager, roadmaps are bullshit. They are created to make the company at large feel comfortable with where the product is going.” — Daniel Schmidt, product manager for Maze

In his post, Let’s Rethink Product Roadmaps, Daniel argues that roadmaps are already expired before they begin.

“Roadmaps make the product evolution legible. But inevitably, the experience of each project completely changes the trajectory. Things you thought were important aren’t…So if we don’t do roadmaps, what do we do instead? I’m not entirely sure yet. In my current company, I just say what we’re doing next and keep a list of all the things we could be doing but aren’t. The collective imagination of a company should be captured, just not with flawed forecasts for dreams becoming real.”

It seems that many of the authors mentioned in this post have found better ways to work by letting go the need to plan and control the future. Instead, they have found speed, impact and flexibility by focusing on the learning process.

6. A Common Language

“A common language goes a long way.” — Noah Weiss, Head of Search, Learning, & Intelligence at @SlackHQ. Previously at Foursquare.

Noah Weiss took a different approach in his post #now, #next, #later: Roadmaps without the Drudgery. At Foursquare, he had his teams divide everything into three timeframes, #now (2–4 weeks), #next (1–3 months), and #later (over 3 months). The simplicity makes it easy to adopt and the common language makes it easy for teams to communicate.

Noah explains, “between 20 people and 1,000 people is the sweet spot for a lightweight approach to product roadmaps. We had tried many at Foursquare, but none had stuck — including a few attempts at OKRs. The alignment from OKRs is great, but the measurement overhead is overkill for companies changing quickly and the quarterly cycle is too inflexible”

How many organisations with over 500 employees do you know that are comfortable with not having at least a 6 month roadmap already planned?

7. Solve Problems Instead of Building Features

“When a team has a clear definition of a problem, solutions are often easy. Usually, the biggest source of trouble with defining solutions comes from unclear problem definitions.”- Jared M. Spool, Founder of UIE

In Themes: A Small Change to Product Roadmaps with Large Effects, Jared Spool discusses the use of themes to frame a project. Themes based on customer problems.

He explains, “you can’t fill a roadmap with customer problems if you don’t know anything about your customers. By moving away from the invention of features (which can be done independent of whether customers need what you’re building), the roadmap technique requires deep and thorough customer insights.”

Switching from features lists to customer problems is a challenge for most organizations that crave certainty. Teams who want to move away from the feature factory will struggle, but those who succeed will enjoyed the benefits of having a shared understanding and the speed that comes with it.

The Wrap Up

Whether you think roadmaps are useful or not, we can no longer pretend that a long list of features with timeframes attached to them is the right way to build product. The job is to understand how we can transition to a problem-focused organization where teams can immerse themselves in continuous learning and fully embrace uncertainty.

 

This was originally published on Medium








What I’ve Learned About Not Managing People

The Art of Letting Go and Fighting the Urge to Control

I stopped dieting for weight loss purposes 15 years ago. My brain finally understood what I knew all along; diets deplete willpower, make you fat, unhealthy and unhappy.

Instead of dieting, I’ve been doing the obvious — eat what I want, when I want it, in a balanced way. The results are as expected; better health and consistent weight for over a decade. No restrictions, no stress.

There are a lot of things in life that work the same way. Intellectually we understand a wide range of facts and theories; however, it can take decades before we can truly put that knowledge into practice.

Why is that? I think there are many reasons, but one powerful reason is our ability to rationalize everything. We convince ourselves that it can’t be that easy.

But, it is.

Business practices are the same. There is so much common sense and wisdom around us but we choose to make things complicated, potentially out of fear. After all, it can’t be that easy, right?

Here’s an example of a business practice that makes total sense but is hard to find in most working environments. For a bit of context, our team is small and distributed. We have team members in six different countries and time zones.

You know what’s complicated? Trying to control people and their work.

You know what’s easy? Providing total freedom.

One of the wonderful things about building a remote company is that you have to learn to reject the urge to control people. Instead, you have to build real trust — trust that can be tested everyday and not break.

Every team member at our company has the freedom to work from any place in the world, they can work when they feel most productive and take time off when they need it. We don’t count hours, we focus on results.

That all sounds sweet and cuddly but it works. There is no fluff here. People do better work faster, feel productive and happier. Period.

You don’t need to hear that from Jason Fried to know it is true. You can intellectually understand it and know that it makes sense. In practice, it looks a bit like this: a team members called Juan types in your internal chat:

“guys I’m going to take a nap and come back later, I didn’t sleep well and have a headache..”

In a typical business setting there would be some sort of freak out, some peers would get offended by Juan somehow being lazy and not pushing through the day, others will keep tabs for the next 1:1 session with Juan, and in other companies Juan would get fired immediately.

It takes a lot of discipline to build a company where Juan can feel confident about the fact that he is doing the right thing for him and the company. It takes discipline but it is not complicated.

Why do we want Juan to be tired at work? Make a bunch of mistakes and have a bad day? Wouldn’t it be easier for Juan to go, take that nap and come back when he is ready? This is not new, you know this is the right thing to do, however, managers keep overworking people, making them feel insecure and trying to get the best out of them while using fear tactics. This is bananas.

It is not only about the managers. It also takes a lot of discipline from other team members to make trust their default thinking. They have to be convinced that Juan is doing the best for everybody and not playing Grand Theft Auto Five while drinking bloody marys at home.

Most importantly, the team needs to feel confident that Juan will come back at some point, do a superb job and continue doing his thing.

Exercising Freedom at Work is Exercising Empathy

Some people work well in the evenings, others early morning. Some people need quiet environments, others need noisy places, some people have to go to the doctor or pick up their parents at the airport in the middle of the week, some suffer from insomnia, some people get their periods and feel crappy.

Those things are part of life – making talented people restrict themselves to justify outdated practices is the best way to lose them.

People are responsible adults at home. Why do we suddenly transform them into adolescents with no freedom when they reach the workplace?” — Ricardo Semler

You may be thinking: But Sofia, what are you talking about? Where is the hustle? Have you watched the latest Gary V?

My answer is that hustle comes in different shapes and forms. Productivity is not about sweating your ass off. Hustle and speed come from an unbreakable commitment to do our best work and help the people who help us make that work happen.

Productivity for me is to be part of a team I don’t have to control, a team that does more in less time because they are not exhausted, a team that gets involved beyond their job description because they feel good about helping others.

No drama, no waste of time, just people learning, contributing and being happy at the end of their working day, whatever that looks like for them.

My guess is that a lot of outdated practices come from people in positions of power who are not self aware enough to understand how their own insecurities and psychological baggage affect their teams.

It is easier to rationalize the need for control than to do the simple thing. Let people do what they want to do and be who they want to be.

If your team is driven by learning, by freedom and by achieving a common goal, all you need to do is to provide the best environment for those things to happen. The rest is noise.

You may say, well… that all sounds great and fun, but you are a small team, you can’t do that in a larger organization and you probably drank too much oolong tea.

Maybe, but here is what I know.

If trust didn’t scale, we all would be dead by now. We need to trust each other to function as a society. In business, you build trust by doing small things well, for example:

When Aurora says she is leaving early because she is getting her driving license, you as a leader, don’t freak out.

When Rudolf proposes an idea, you make sure he knows his idea will be implemented or why it will not be implemented. We all need to know WHY.

When a bunch of people are in a meeting, but Carlos has not had a chance to speak, you ask Carlos what he thinks about the discussion. Some people need to know that their ideas matter. Because they do.

When Jakobo messes something up or delivers something late, you don’t assume that he did that intentionally, you assume he was doing his best based on what he knew at the time. You try to understand what happened. No blame. Accountability is an agreement not an imposition.

If Bedelia is looking upset, you overcome your social awkwardness and ask if she is OK. If she is not OK, you let her know she can take the day off.

When you say you are going to do something, you do it. If you tried hard but couldn’t deliver, then say why. But make sure you did your very best.

Then you sayBut Sofia, who are these people? You don’t know what you are talking about, not everybody is like that, I know some people that are nasty and they don’t care at all.

That’s a different problem, that’s a hiring or firing problem. You build trust with people who earn your trust. You can’t build trust with people who don’t want to build it with you. Most importantly, you set clear boundaries and when people fail to see them, you kindly remind them why they exist.

Good organizations know how to set boundaries without making people feel caged. Trust is built everyday, with small but frequent reactions and interaction.

I’m not saying that all of those small interactions have to feel like marshmallows. Heated conversations are needed. Healthy disagreements are necessary. The trust you want to build is the kind that let’s you communicate that you are annoyed and disappointed with something or somebody without feeling the fear of destroying your relationship with that person.

“Compassionate people ask for what they need. They say no when they need to, and when they say yes, they mean it. They’re compassionate because their boundaries keep them out of resentment.” ― Brené Brown

The same way it took me years of frustration and weight fluctuation to finally decide to stop dieting. It took me many burnouts and failures as a leader to finally understand that the best way to manage people is to not manage them at all.

This post was originally published on Medium








13 Insightful Posts That Will Change the Way You Think About Customer Feedback

“We’ve had three big ideas at Amazon that we’ve stuck with for 18 years, and they’re the reason we’re successful: Put the customer first. Invent. And be patient” Jeff Bezos, CEO of Amazon.com, Inc.

One of the difficult things about dealing with customer feedback, and the idea of putting the customers first, is that there is not a clear process that can help all types of businesses become more customer focused. Every business has to find their specific way to go about it.

It is a creative process that involves people, and people are messy. A good place to start is to expose ourselves to different thinking and practices from those who have succeeded in building a culture where both the vision of business and the customer needs are aligned.

In this post, we’ve summarized some of the best and most shared content on dealing with customer feedback and managing customer experience. Here are 13 different perspectives we hope will inspire the way you think about your own strategy.

1. All feedback should be considered, no matter how small

Tiny data helps customer success teams give better support. – Emily Chapman, @trello

In the article “Forget Big Data: How Tiny Data Drives Customer Happiness,” Customer Success Specialist Emily Chapman describes how her support team at Trello uses HelpScout to manage incoming and outgoing tickets. “We analyze the results of this data, but instead of resting our laurels on the 91 percent rated Great,” she writes, “we dig into the 5 percent rated Not Good.”

By focusing on these individual pieces of feedback rather than overarching qualitative metrics, Chapman’s team can better get to the core of who they are as a brand. At Trello, the individual matters. They want to listen and learn from each one of their users just as much as they want to solve problems. “Trello is focused on a delightful user experience,” concludes Chapman. “Delight doesn’t happen to groups of users — it happens to individuals.”

2. Consider every customer touchpoint as an opportunity to gather constructive feedback

Most feedback gathering can be automated and integrated at nearly every point of your customer’s lifecycle. – Ott Niggulis, @ottniggulis

In his piece “How to Create Customer Feedback Loops at Scale” on ConversionXL, Ott Niggulis says that you should be looking to gather feedback at every opportunity possible. “By building feedback experiments, measuring results and extrapolating insights,” he continues, “the goal is to learn something specific about your different visitor, lead and customer segments to improve some other area of your business.” Building feedback loops into your products shows that the company actually cares about its products, services and the people using it.

According to Niggulis, there are five different types of potential leads: non-customers, leads, first time customers, repeat buyers and non-converting customers. With five different types of potential leads come five different ideal points in the lead flow to gather feedback. From popups to follow up emails, each type of feedback loop has its own place, and automating each of them will give you more time to focus on other things.

3. Build hypotheses to drive your requests for feedback

There will be times you encounter user feedback that doesn’t need to be tested or explored with a survey. It just makes immediate sense. – Kenneth Berger, @kberger

In an interview with First Round Review titled “Slack’s First Product Manager on How to Make a Firehose of Feedback Useful,” Kenneth Berger shares what he’s learned about prioritizing feedback at Slack, and as a startup co-founder, product manager and designer before that. He had a lot of great stuff to say, but we’ve whittled it down to four key insights:

  • Pursue Goals, Not Numbers: Your data points are actually individual humans, and it’s important to keep in mind that humans don’t always think or act logically.
  • Smarter Hypotheses Yield Smarter Insights: Spend some time deciding what you think — and hope — the outcome of your feedback request will be in order to use it wisely.
  • Know Your Biases to Keep Them in Check: Identifying what human perspectives come to play when reviewing research is critical to your understanding of how you’re reading the data.
  • Combine Qualitative and Quantitative Data to Make Them Both Stronger: Quantitative data tells you if something is wrong, and qualitative can tell you why.

4. Make it a priority to talk with your customers

If you want valuable, actionable product input, there’s no substitute for sitting down with your customers and prospects to truly understand their problems. – Michael Sippey, @sippey

When Michael Sippey, Twitter’s former VP of product, spoke during First Round’s CEO Summit, he shared the one most important rule and three steps for gathering powerful customer feedback that can make all the difference for your product roadmap. “Get in the Van and Other Tips for Meaningful Customer Feedback” digests his musings from over a decade of learning from great leaders.

The number one most important rule that Sippey has learned is that you must speak to your customers every day. This rule is supported by three lessons: set at least 30 meetings, “get in the van” (also known as: get everyone in the same meeting because “you can’t build an innovative solution on your own”) and focus on their problem rather than selling your solution. By giving your customer the face time they want, you will gain the perspective you need to create a product that sells itself.

5. Keep your biases and emotions in check

Your brain is twice as likely to notice confirming information than it is to notice disconfirming information.- Teresa Torres, @ttorres

Teresa Torres is a product discovery coach and founder of Product Talk, where she’s creating content about product that is easy to digest and immediately actionable. In a series of four swift essays, Torres writes about confirmation bias, status quo bias, the 10/10/10 rule and asking about past behavior:

Through this series and all of her essays, she reminds us of steps to take to mitigate biases and emotion to take your product to the next level. Too often, we only hear what we want to hear. We fall in love with our ideas, and even when we think to get feedback, we don’t do it in a way that allows us to really evaluate the idea.

Keeping your ego out of the equation will help you focus on what your customers truly need rather than what you want to build. By focusing on what customers need, you create a product with market fit.

6. You can’t analyze feedback in a vacuum

[Repetitive feedback is] an indicator you haven’t got the basics right, and that’s something you have to address as a priority rather than ignore. – Sian Townsend, @intercom_uxr

In her piece “Making sense of customer feedback” on Intercom, Director of Research Sian Townsend asks, “what feedback should you listen to? How do you go about making sense of it?” She reminds us of six things that matter when taking feedback into consideration.

Who’s giving the feedback as well as whether it’s prompted or unprompted feedback is critical to consider when reading qualitative suggestions. “Unprompted feedback deserves special attention,” she writes, “because issues that aren’t on your radar, that you’re completely unaware of, can be the most important things you need to hear.”

She also reminds us that motivations, volume, repetition and the stakes are key indicators for why the feedback is valuable. Our opinion of priority issues can be slanted by those who are most motivated to give feedback and those who shout the loudest, as well as by multiple pieces of feedback about a single issue.

Keeping these factors in mind and teasing feedback out of the middle-of-the-road customers is critical to completing a full understanding of what customers need.

7. Both types of feedback will give you the answers you’re looking for

Quantitative and qualitative data are equally important for amplifying the voice of your customer and reaching data-informed conclusions.- @qualarooinc

How do we decide which type of data to prioritize? In the article “Qualitative or Quantitative Customer Feedback? How to Get the Best of Both Worlds,” Qualaroo tells us how we can have it all. This piece also gives us an invaluable suggestion for the steps to take in collecting and visualizing customer feedback. According to Qualaroo, collecting customer feedback takes just three steps: create an open-ended survey, flag keywords in each comment and quantify those keywords. That way, you can turn qualitative comments into numeric data sets for analysis while still keeping the insights intact.

8. Your customers are your product’s best friends

Data can tell you what opinions to hear; and conversely, opinions can tell you what data to read. – J.T. Trollman, @jtroll

J.T. Trollman, product designer at Facebook, reminds us that in the end, you do listen to the people using your product for the simple reason that at least some opinions will guide your path toward improvement in his piece “Two Lessons For Using Feedback.”

Lesson 1: Know Your Core Value. “The real lesson is not to ignore the problems people say they have with your product. What’s important is how you listen to those problems. What’s your product’s reason for existing? What larger user problem are you trying to solve? If it’s not already apparent, relentlessly pursue the question until you find an answer.”

Lesson 2: When In Doubt, Count. “Hundreds of loud voices can proclaim people want one thing, but the way people actually use that product can tell an entirely different story. So count people. Count early, and count often.”

9. Customer feedback is critical to your bottom line

The strongest feedback loops do more than just connect customers, the front line and a few decision makers in management; they keep the customer front and center across the entire organization. – Rob Markey, Fred Reichheld & Andreas Dullweber, @harvardbiz

The Harvard Business Review piece “Closing the Customer Feedback Loop” by Rob Markey, Fred Reichheld and Andreas Dullweber gives us a glimpse into how companies are using Net Promoter Score (NPS) for customer service research that is directly connected to revenue, reminding us that increasing positive customer feedback and meeting conventional financial objectives are becoming one and the same goal.

“At companies where strong customer feedback systems take hold,” writes the trio, “business-unit leaders and frontline employees start to own customer loyalty the same way they own their targets for revenue, profits and market share.” The piece follows Grohe, Charles Schwab and Allianz employees to remind us that unless our customers are recommending our product to friends (the key identifier of NPS), we can’t grow a business.

10. Use existing feedback to decide what questions to ask

If you ask certain questions and avoid others, you’re guiding the answers, which means you’re still building the product you want to build, not the one your users want to use. – Violeta Nedkova, @violetanedkova

Violeta Nedkova is a serial entrepreneur and co-founder of Amazemeet. She, like many of our other #CX-perts, uses a guide for collecting feedback and reminds us that most of the time people don’t respond to general requests. If you want really good feedback, you have to work at ‘getting it’, meaning you need to direct your users and ask the right questions.

In her piece “How to Apply ‘Diagram Thinking’ to User Feedback at Your Startup,” Nedkova helps in guiding customers toward giving feedback that matters.

A simple open paragraph box at the end of a survey won’t work, says Nedkova, so she gives us six steps to remember when prompting for feedback:

  • Ask for exactly the information you need.
  • Guide your users directly to the prompt or request.
  • Receive the feedback without confusion about accessing it.
  • Apply the feedback by implementing changes or fixing bugs.
  • Reply to your users by thanking them for their feedback.
  • Prompt additional testers for thorough feedback.

She ends the piece by reminding us that no one wants to be challenged, but that feedback is critical to giving yourself a 360-degree-view of your product.

11. Your customers are humans, not robots

Getting better feedback out of users is a conscious process. It doesn’t require huge amounts of effort to elicit better feedback.- Nick Kellingsley, @interactiondesignorg

Oh, so you want some honesty in your feedback? In his article “How to Get More Honest Feedback in User Testing,” Nick Kellingsley from The International Design Foundation tells us what to remember — and how to make the most of it — when expecting your customers to get real with you.

There are four key human aspects, Kellingsley says, that we need to keep in mind when asking for honest feedback: we don’t want to hurt other people’s feelings, we assume we’re the ones being tested, we focus on completing a task, and we can show more than tell if we know it’s expected.

There is a certain finesse involved in getting your users to be honest in their feedback, but it’s not rocket science. Just chat with them the same way you would with a friend.

12. Decide who will take responsibility for using customer feedback before you collect it.

Feedback loops often suffer from a lack of commitment.-Sarah Chambers, @kayako

At Kayako, Sarah Chambers is asking questions like “Who’s Accountable for Customer Feedback?” What does accountability mean? Why do you need accountability?

She tells it like it is — in short, it doesn’t necessarily matter who owns the feedback, as long as someone specific has been defined because, as she puts it, “Without accountability, you tend to run into the bystander effect: a perceived diffusion of responsibility.”

There’s two reasons for this effect, continues Chambers.

  • People tend to follow the crowd. If they don’t see anyone else stepping forward, they don’t think it’s necessary.
  • There’s a diffusion of responsibility. Instead of one person feeling the full weight of responsibility to save a life, the responsibility is split between one hundred witnesses, and no one is compelled enough to act.

So, how do you make a team accountable? Simple: choose the right metrics, and set frequent checkins. “By tracking progress consistently,” she concludes, it’s easier to iterate quickly and make noticeable improvements.”

13. Every product has a different method-of-best-fit for gathering feedback

Your data will help you determine the ‘what’ and your feedback will help you determine the ‘why.’- Sean Cramer, @cosmocramer

Atlassian is one of the many companies that strayed away from using NPS in favor of developing their own system for creating quantitative feedback out of qualitative data. In his talk “RUFing it out with Customer Feedback: Knowing the ‘Why’” Sean Cramer gives us insights into how to categorize and measure comments of Reliability, Usability and Functionality: RUF.

Cramer defines the complete timeline from collecting feedback to using it constructively with a few simple steps:

  • Categorize and measure by finding the sources, measuring the feedback, and categorizing the content.
  • Understand the impact of insights by determining the red lines, getting commitment to action, and establishing baseline expectations.
  • Build the system by creating insight opportunities, monitoring improvements on those insights, and communicating internally.
  • Close the loop by sharing your insights, thanking your users, and being proud of the changes that have been made.

The RUF system is used primarily by Atlassian, but can be applied equally to plenty of other companies who collect both qualitative and quantitative feedback. Cramer encourages product managers to build the system that works best for their specific product.

In Summary

We believe that while there are plenty of ways to collect and analyze feedback from customers, the most critical things to remember are:

  • Determine a system of best fit for collecting your customers’ feedback during every point of contact.
  • Data can come in either qualitative or quantitative forms, but the best customer success and product teams use both to unlock the power of customer feedback.
  • Customer feedback — ultimately, customer happiness — is directly correlated to your bottom line.
  • Bias and emotions are always a part of the puzzle, so avoid them as much as possible while still retaining your humanity.
  • Don’t just listen to the loudest voices in the room or the most repetitive feedback. The entire scope — down to the tiniest data point — is critical to truly understanding the customer experience.

We’re all humans — our product teams, our management and our customers — and each of us have a story to tell. Giving your customers the opportunity and platform to tell their story will better inform your product’s and your own. In the end, isn’t that all we truly want?

This was originally published on Medium.








When Your Processes Fail: The Hard Truth Behind the Fluff

A few weeks ago, I did a quick demo for a product designer in a large tech company in L.A. After we finished chatting about the product, we spent some time talking about his company and a couple of things he had observed in product teams with which he had worked with in the past.

The whole conversation started when he said something like this, “I am not sure how product managers become product managers.” With a cheeky smile, he continued, “More often than not they lack training in psychology and research and yet they are making all these decisions based on human behavior.” He said it with a bit of bitterness in his voice. Since he had been formally trained as a researcher and designer, he probably felt that he was more qualified to be a product manager than his peers, he just didn’t like that job.

The conversation left me thinking about the actual skills and type of thinking we need in order to understand customers. Skills and experience that go beyond learning how to write customer development questions or build empathy maps.

When jobs have a significant amount of human interaction, we tend to heavily rely on methodologies to help us cope with the uncertainty attached to dealing with these tasks. Humans are messy, complex and unpredictable, and the business world often clashes with that reality, especially when we are pursuing scalability, repeatability, and predictability.

I’ve always found it fascinating that businesses of all sizes tend to invest enormous efforts in building processes but often overlook the fact that processes and methodologies are only as effective as the people who execute them. It is what people know, their experience, and how they feel what makes a difference.

Businesses prefer to send people to agile courses or growth hacking conferences, rather than sending them to creativity workshops or soft-skills training. The latter feels like fluff — but is it? We want people to be creative and empathic, to come up with amazing growth strategies and visionary product roadmaps, but instead we build incentives around structure, processes, and tactics.

Processes and methodologies are fundamental parts of scaling any business, but the experience, skills, and commitment of those who make them happen are equally important.

When Good Processes Fail

Good process + bad people = crappy outcome.

You can go to any Chipotle in town and enjoy the exact same beef burrito you would expect in any other Chipotle location. However, your overall experience can be completely different in each place based on who takes your order. Maybe the person taking your order woke up that morning feeling rested and optimistic, or she woke up realizing the rent was due and she didn’t have the money, she is stressed, but she needs to take orders all day from people who can eat baby-sized beef burritos. She may not be happy about it. Either way, you will get a slightly different experience.

Chipotle wants to offer a great burritos with a “personal touch.” But perhaps that “personal touch” had a long night or is having a bad day. You can’t always control the “personal touch.”

While the product designer in L.A felt that product managers needed to be knowledgeable about research techniques and deeply understand human behaviour, some people believe product managers need to be more technical. Regardless of what you think the requirements are, if your job is understanding humans, you need to invest in those skills. You can’t rely on processes and methodologies to guarantee a great outcome. That reminds me of this old school quote from Richard Buetow, an executive with Motorola, about ISO 9000:

“With ISO 9000 you can still have terrible processes and products. You can certify a manufacturer that makes life jackets from concrete, as long as those jackets are made according to the documented procedures and the company provides the next of kin with instructions on how to complain about defects.”

When Bad Processes Win

Bad process + good people = better outcome.

A great example of this principle is a LinkedIn update I found floating on my feed a few months ago. It was from Thomas Case, an HR manager proudly sharing his way of welcoming new employees to the organization.

The post had 10,322 comments and 55,686 likes. I was definitely late to the party. I personally don’t know Thomas Case but the numbers made me curious so I started reading the comments. Suddenly I realized that most of the comments were either praising him for his dedication or criticizing him for not making sure that the office had a window, the carpets were nicer or that he forgot a detail here or there.

It didn’t matter. Maybe his process and check lists were not perfect. Maybe he didn’t account for all the potential needs a new employee could have, but the outcome of his on-boarding process is most likely to be great, a new team member feeling welcomed, a more productive first week, all thanks to the ‘personal touch’ of a good person running a slightly crappy process.

When Good Processes Win

Good process + good people = great outcome.

When a great process is run by great people, it sometimes feels as if there is no process. People have the freedom to change the rules because they feel empowered and accepted. They know their team trusts them, they believe in the business, and they are happy. Creativity flows naturally. Although there is a tacit understanding that some level of structure is necessary to ensure the growth of the business, the structure is never allowed to stop the growth itself.

There are many companies running great processes with great people. I personally admire those that can keep doing this consistently.

An example that comes to mind is MailChimp. Over the years I’ve seen multiple teams at MailChimp ship a number of initiatives that show the power of customer centric processes run by great people.

For example, What’s in Store initiative, is about Meg, a team member in their marketing department, launching an e-commerce store from scratch and documenting every step behind starting a business so they can understand what is like to be one of its own users.

Another great example is UX connected, an initiative led by Aarron Walter, Director of User Experience, in which he coordinated efforts across the entire organisation to make data, especially qualitative data, available to everybody, accelerating their understanding of customers and enabling better collaboration across departments.

These are just a few examples, but it all comes back to the investment they make in people. Check out their about page.

The processes behind these initiatives are likely to be great, but even if they weren’t, the people running them are able to destroy them and rebuild them in order to fulfill their mission in the organization.

Even great processes run by great people fail. They do because they try new stuff, they dare to be creative, they know the goal is not to create a better processes but get a better outcome. Living in a space of constant experimentation requires a lot of soft skills. It requires all the fluff you can get.

Don’t Wait for the Next Round of Funding

You can start very small. If you can’t design your own employee university, you surely can spend $20 a month gifting great books to your team members, or paying for the random meet-up, or creating a channel in your internal chat tool that is dedicated to sharing learning resources or articles.

For these things to work, people need to feel comfortable with the idea of continuous learning, and this means, leaving their egos outside the room.

You need to be able to have conversations that include words like I’m scared, stressed, insecure, unsure, uncomfortable, nervous. Your team many not mention those words in the middle of the sprint planning but they still feel them and when they can’t express them, they focus on the process, regardless if it is a good one or not.

If you have to start with something, don’t start with the process, start with the people.

This was originally published on Medium

Over the last decade, Techstars has grown a worldwide network with 100 exits, 1000 companies in the portfolio and 10,000 jobs created by those companies. Want to be a part of it? Learn how.