Operationalizing Empathy

Adam Sigel
Aug 28, 2017 · 12 min read

In Boston Product’s PM Spotlight series, we chat with inspiring product managers in our community to learn about how the role varies across teams, industries, and business models.

Earlier this week, we sat down with Matt Gray, Director of Product at TetraScience and talked about his principles and his processes for product management. Matt is a big believer in the power of empathy, and works to instill that into the team’s day-to-day. We also talked a bit about what aspects of the role Matt takes home with him at the end of the day. Below are Matt’s answers (edited for readability) to my questions.

Background

  • TetraScience is an Internet of Things platform for science. The company provides hardware- and software-as-a-service that allows researchers to aggregate and analyze data on lab equipment to inform cap-ex and op-ex decisions. It also automates the collection of raw data normally performed by hand, so researchers can be more efficient.
  • As the Director of Product, Matt is responsible for product management, regulatory affairs, data science and BI, design, and user experience and research. He manages 1 FTE and 1 part-time team member across all these functions, and the team is actively growing.
  • Matt reports to the CTO, and works with 12 engineers, 10 of whom write code, and 2 designers.
  • Matt has been a full-time product manager for 4 years, and joined TetraScience in the summer of 2016. He has a degree in quantitative sociology and applied statistics. He moved into product after working on analytics and professional services projects for another software company.

Matt’s Stack

  • Ticketing: JIRA
  • Analytics: Mixpanel
  • Customer Support/Engagement: Intercom
  • Design: InVision / Sketch
  • Roadmap: Roadmunk
  • Wiki: Confluence
  • PRDs and Notes: Google Drive
  • Internal Communication: Slack
  • CRM: Salesforce.com

Product Owns the Problem

My most important function is to develop a deep understanding of the problems our customers and our target customers face. I obsess over those problems and learn as much as possible about them so I can prioritize the solving of those problems and help other people—mainly engineers—understand them so they can help me develop a solution.

I spend most of my time on getting greater insight into our customers’ problems. Personally, I think all PMs should be doing some form of user research or empathy-based research to remain close to their customer or their target users. That’s something I take very seriously, and I’ve involved everyone from summer interns to full-time designers and PMs to do that kind of research and share the insights with the rest of the team. Right now, I’m averaging about 4 or 5 customers meetings per week.

Gathering Customer Feedback with CPSF

We use a framework we call CPSF: Customer. Problem. Solution. Followup. It borrows heavily from something that Jason Evanish pioneered as part of lean customer development.

We try to group things into knowns and unknowns, and we divide the unknowns into little pieces. Those collections of unknowns become the focal point for our conversations with customers.

The operationalization of our research program is something that has proven to be more difficult than I’d anticipated. In general, I find scheduling meetings really annoying. I use Assistant.to now to book meetings. The meeting options are embedded in the email so the recipient just clicks a link and it’s done.

Sourcing customer interviews is like being a BDR — it’s constant rejection and it’s really frustrating.

Sourcing is another challenge. You have customers you can talk to, but you want to go broader than that, because your existing customers are going to carry a bias toward your product. So you’re on LinkedIn, ZoomInfo, or company websites getting people’s email addresses, cold emailing, dealing with low success rates. It’s like being a BDR — it’s constant rejection and it’s really frustrating.

To make this a little easier on ourselves, we’ve gotten smarter about how we use our networks. We’ll ask, “Does anyone know someone matching these criteria?” The response rate on a warm intro is so much better than what you get from cold outreach. When we wrap up customer interviews, we also ask them if they know anyone — friends, colleagues, roommates, whatever — that would be a good match.

I prefer to meet with customers in-person because you can observe their body language and their surroundings, but that puts further limitations on your universe of contacts. We’re lucky to be here in Boston where there’s lots of laboratories and research groups who deal with the kinds of problems we want to solve.

TetraScience operates out of the Harvard Launch Lab co-working space.

Once the meeting is scheduled, we follow an interview format that’s not dissimilar to how talk shows do it. Most of the questions that we’re going to be discussing are decided in advance but then within that framework, there’s room for improvisation and ad-lib. We front-load with questions about who the person is, where they are in the organizational structure, how their success and their group’s success is measured, as well as major company initiatives.

After the initial conversation where we just learn about the customer, we move into working to understand the problems they face in their job, how they spend their time, and the major bottlenecks they face in trying to achieve their goals.

We intentionally front-load our customer interviews with questions that are designed to reduce the bias that we might introduce as interviewers.

After that, we move into solution testing. We walk them through high-fidelity mocks to see how well our proposed solution addresses the problems they’ve identified. It’s a combination of problem prioritization and design feedback. Depending on the size of the project, we’ll sometimes spend months iterating on designs before committing any code, and this process prevents us from spending engineering’s time on something that is unlikely to be successful.

We take diligent notes during these interviews, and they all end up in a central location. We try and do a debrief every day in which a person tries to summarize the takeaways of a particular customer meeting and what they learned. That way, when you come back to those notes later, you can quickly anchor yourself with, “Here’s what we learned from this meeting.” We always try to write customer feedback verbatim, because when you go back to the notes later, you want to be able to say, “Billy Jenkins at Company X literally said this.” It removes a lot of ambiguity and bias.

We always try to write customer feedback verbatim. It removes a lot of ambiguity and bias.

If you do enough interviews, you start to see themes and patterns about design preferences, willingness to pay, and priorities of problems. That’s when you can really start to leverage this process. In summaries and presentations, we try and avoid referencing specific percentages though. We won’t say “80% of the 5 people we spoke with said this.” We’ll say, “This is a fairly pronounced trend,” so people understand that it’s meant to be directional.

There’s no substitute for empathy. It’s hard to learn, and it takes years to develop. It starts in kindergarten when you learn to share toys with others and be a social being, you end up developing skills and emotional intelligence that play into your professional life. If you’re just trying to prove yourself right, it’s not going to result in the highest quality idea. If anything, you should be relentlessly trying to disprove your hypothesis since you have such a strong bias towards confirming it. You might get lucky and accidentally stumble upon a good idea, but you won’t be able to do it in a repeatable way if you’re not exercising empathy for the customer.

If you’re just trying to prove yourself right, it’s not going to result in the highest quality idea.

At the end of the day, you want to be able to explain things about your users or personas to the broader team to justify doing one thing versus another. Our customer interview process helps a lot with that. I also get pulled into sales or customer calls occasionally. The feedback there is less formal, but it’s still very helpful. We also have Slack channels where people can share and discuss their verbatim feedback from customers or their own product ideas.

Tradeoffs in B2B

We’re able to close deals for software that isn’t yet built based on a customer’s commitment to a concept and a solution. I’m comfortable with selling slideware. If we’ve systematically reduced the risk of wasting time to develop something as software that the customer doesn’t want, I feel we’ve done our jobs. We haven’t run into any issues where customers are disappointed by the final product because it doesn’t look or behave exactly like the mockup. As we iterate on designs for a problem, we get into in-depth conversations about how certain features help solve certain problems. Part of our process involves following up with the customer to do a force-ranking feature exercise. (Following up is another Jason Evanish pro-tip.) At the end of the day, even if it doesn’t have every feature they wanted, we know it has the ones that they thought were most important over the status quo to get started and find value.

We try and validate all ideas with something we call the Earliest Sellable Concept. It’s the simplest way of articulating a solution to a problem that someone would be willing to pay money for. Sometimes it’s just a PowerPoint or InVision mockups. From there, we move on to Earliest Usable Product. That might be a very simple standalone server-and-webapp type of architecture that’s outside of our production deployment process.

When we work with our early access customers, we tell them about new features as they launch. There’s a nice covenant there, where the early access customer tolerates potentially limited functionality that’s maybe less than ideal in exchange for the chance to govern the product direction in an outsized way. The customer sees that we heard them, cared to consider their problem, and actually took action to help them solve it. That loop builds strong relationships with customers and product teams.

One challenge we face as a company that serves enterprise customers is the constant influx of feature requests from very large customers. Leadership and CSMs will push very hard to give those ideas outsized importance — as they should. But there shouldn’t be a direct relationship between enterprise customer requests and backlog items. They should still go through the same evaluation and process for understanding the underlying problem. I get pushback sometimes when I suggest this, because people want to show that we’re customer-focused and that we can move quickly to make progress.

If someone’s dangling a check, they don’t get to jump the gate, but they might get to skip the line.

If someone’s dangling a check, they don’t get to jump the gate, but they might get to skip the line. We may accelerate the development of something, but we’re still going to give it the same treatment from an empathy perspective. I have lengthy conversations with our leadership team about this. Research also gives you the power to push back. Customers come to you and say, “We think we need a feature that does this,” but if you’ve done your research, you can challenge them back and say, “Here’s what more mature organizations are doing to address that issue, and here’s how we’ve architected our product to handle it.”

Trust the Process

When you’re an early stage company, you’re forced to make a lot of decisions before you think you have enough information to do so. Even though we may not have all the information we’d like, we can take a leap of faith knowing that we’ve done our work. We’re making decisions with more information than I think your average startup of our size will make because we’re going through the motions. Good process helps us make good decisions, and that’s been a real a-ha moment. I’ve learned to trust the process because, at worst, it allows us to stop working on something as soon as we find out that it’s not the right move.

We try and optimize a few big-picture metrics: developer velocity, stable and low defect rate, revenue, product engagement, and customer satisfaction. When it comes to process, the question I’m asking is, “Are we producing the results we should be producing, easily, all the time?” I’m happy with whatever process helps us to ensure that those metrics are reliably good. We might over-index on a few results, but that’s because they have positive side effects. For example, we recently had a meeting to review the status of different projects, but we ended up talking about process that would help everyone work more effectively. That was great. When you get everyone in the same room, there’s an amount of serendipity that comes from those conversations.

Whatever process can produce the artifacts I expect in return for the constraints I introduce is a good process.

Currently, I’m in the driver’s seat for our our delivery process which draws inspiration from Agile and Lean principles. I’m obviously involved with these teams, but I’m happy to let them organize and structure themselves however they see fit so long as they meet the constraints and requirements I have for the process. Whatever process can produce the artifacts I expect in return for the constraints I introduce is a good process.

Matt Gray, Director of Product for TetraScience

Taking Product Management Home

I have a lot of meetings, which makes me tired at the end of the day. I don’t have the chance to text with friends, check my phone, or catch up on lower urgency issues. So having some laid back time at the end of the day is helpful. Through ruthless prioritization, I want to spend my time at the office only on the things that are most important to critical path initiatives I have on my plate right now. That way, I have the time to take a breather during the day, and I’m less stressed or tired at the end of the day. It’s my way of finding balance. I don’t want to go home and have to spend the rest of the night on the couch decompressing from a day at work. I want to feel like I can live an active life outside of the office. I don’t want to feel like I need to get so much rest.

I don’t want to go home and have to spend the rest of the night on the couch decompressing.

One of my friends jokes that I product manage every part of my life. For example, I think of cleaning my house as a whole interconnected system of practices, each of which has fairly low cognitive overhead, but in conjunction result in a clean house. I force-rank errands to be done. I’m pragmatic enough to say, “If the chores are done before the end of the weekend, that’s good enough. I don’t have to do the chores before I do the fun stuff.” I also recognize that I don’t like doing all my errands at once, so if I happen to be near the grocery store I’ll take that opportunity. I suppose I’m optimizing for throughput.

Getting back to empathy, developing my active listening skills has been a real advantage with personal relationships. It’s made me a more helpful and considerate friend and a better romantic partner. When you listen to people and try and understand the root problem, you’re more likely to embrace them and be kind to them, rather than push that person away as an other.

Part Traffic Cop, Part Superhero

What keeps me excited about product management is that there’s always new problems to solve. It’s a very high-leverage role in most organizations, and I like being at the intersection of new business process, new go-to-market strategies, and new software functionality as it all relates to someone that I’ve worked with to solve some problem. I like that it brings together empathy and real solutions. There is a bit of a superhero complex to it where I want to be a hero to someone, but really I just like helping people and solving problems.


If you enjoyed reading this, please give us some 👏 and check out Boston Product.

Boston Product

The collective insights of over 500 product professionals working to elevate our careers and show that Boston is where great people build great products.

)

Thanks to Lindsey Christensen

Adam Sigel

Written by

Head of Product @Hometap 🏡 | Founder of @bosproduct 🥐 | Partner of @sarasigel 👩‍🎤 | Human of @rupertmurdog 🐶 | Fan of 🥁🍕⛰📱

Boston Product

The collective insights of over 500 product professionals working to elevate our careers and show that Boston is where great people build great products.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade