Identifying Customer Problems

Maritza Perez is a results-oriented Senior Product Manager at Abnormal Security with over 10 years of experience managing product releases, roadmap priorities and strategic direction for enterprise security technology. Previous to her role here, she worked at Splunk, SourceClear, Sumo Logic, and ArcSight- all in various Senior Product Manager roles.

Maritza Perez: Hi everyone, and welcome to the Product Development class. This is lesson one: how do you identify a customer problem? My name is Maritza Perez. I'm the Director of Product Management here Abnormal Security, and I'll be teaching you this lesson number one.

So as part of the fundamentals for product development class, we’ll help you understand how Product Management, Design, and Engineering work together across a product development cycle to deliver customer driven research product features. 

Lessons we'll go through is lesson number one, I'll be covering, how do we identify a customer problem? Lesson number two is the product design and lesson number three is the engineering of a new product feature. So let's go ahead and get started. 

So as a product manager, we're responsible for defining the product, vision, and strategy and making sure that we're aligned across all of our stakeholders within the organization. So what this means is we really need to know and understand the customer, or the prospect, depending on which stage you're in and become experts within the market that we're working in. And that also means we have to have a good understanding of the technology you're developing and designing as well. I also like to think that we work really closely with our Design partners and Engineering so that we can really drive to completion how the vision is going to be delivered. So it's really critical for the product success and the customer adoption. So think about it this way. All three of us, all three teams are responsible for the delivery of the product and its success. And lastly, we partner with the internal, all internal groups, think about it like your Product Marketing, Customer Success, Sales, Engineering, to make sure that we keep them informed on how the product is evolving, but also enabling them for the delivery of the best experience for our customer base. So whether it's a net new feature or evolving a new product, it's really important that as the Product Managers and owners, we're working closely with the full organization.

And, the one thing I like to highlight when we talk about product management is the different phases in a product life cycle. So as a Product manager, your role changes depending on what stage your product's in. So normally at a startup, when you still don't have an existing customer base, you might be looking for product market fit. And you're normally working with like, innovative customers that are early adopters and can live with any mistakes that you might have in the product because you're really trying to rapidly solve a product or a problem that's in their environment. 

Once you've hit product market fit, it's really you're in that growth hacker stage. So as a Product Manager, your responsibility is really around getting product reach, scale, and staying competitive. So what does that really mean? That's really where you're trying to get new types of customers to adopt your product. You're working with the Design and the Product team so that you can really scale. So when we talk about scale, it’s feature usability, but also like in the SaaS world that your infrastructure is scaling for the customers and your environment. And then there's like when you're becoming a retention strategy, here's where you want to, maintain and retain that market share. So you're still evolving the value proposition that you're delivering to your customer base, but the problem has already been really defined. You have competitors in the market, you're really working with your Go To Market to make sure you're standing out. And that's when you have full maturity. 

And then of course, as that happens and you start seeing a decline and this is in great organizations when we're starting to launch new products and new innovations so that you have these life cycles and you're starting to introduce different products. But as a product owner today what we're gonna do is mostly gonna focus on the growth hack scenario, ‘cause that's really understanding the transition of the customer profile you're working with is critical to the success of your product.

One thing that I do like to highlight: that within each one of those stages of the product life cycle, as the Product Manager, you're responsible for the end to end of the product development cycle and that partnership that I was referencing earlier with Design and Engineering. I always say, the more work you do up front, the less work you have to do through this. And you enable everybody on that team to really deliver and have a successful launch of the product. So here's, depending on your organization, the PM role might be heavily impacting in the front. Like I mentioned and teeter off as Design starts taking the lead. When you're thinking about ideating with a solution and design iterating, and then Engineering really steps in when we're doing like the development and rollout and maintenance of the product or future development. And one thing I like to call out is this really changes based on your organization. As a Product Manager in the past, I've always focused a lot of the legwork that I do to enable my team in the first three cycles of the product development date.

Alright, so before we dive into understanding the problem, I really wanna go back and focus a little bit on the product growth stage. And so here, I like to call out that once you've designed, define the strategy of what you're trying to deliver at scale, what we like as a Product Manager, you need to think about is what this means. If you're doing it properly, you're increasing customer logos. You're bringing in new type of customers that might not have been innovators and early adopters. And you're getting that map closer to that mass adoption. And the thing, and when you are defining features that you're gonna be investing in at this point, is you want to make sure that you're outpacing your competitors. Because once you have product market fit, you'll start seeing customer competitors emulating a lot of the capabilities that you've highlighted when you're defining the problem and how you're addressing it within the market itself. In this growth phase, you're really trying to one, make sure you're outpacing your competitor. You're expanding your customer logos or net new customers. And you're making sure that your customers are adopting the existing feature. The next thing that you really wanna highlight is the target profile of your customer is going to change. So if you were there part of your product market fit, you were working with innovators, those who have a problem brought it to you, and you've been partnering with, and you have a solution in place that you've delivered as part of your first feature. But they're normally customers who are willing to live with gaps in the capabilities. When you're in this growth phase, you're targeting that early adopter, early majority, where gaps aren't as acceptable because they need to streamline this to make sure that their team can actually adopt it. So think about customers in this profile, when we're talking about early adopters or early majorities, they're not the ones who are influencing the market or their peers, but they're early on enough that they want to get ahead of it. And once they've heard it from one or two people, they're gonna say, look, I'm gonna look at your product and give it a try.

Alright, and so understanding the market problem you're trying to attempt to resolve. This is really critical as a Product Manager because in this stage you are always contending between, do I build a new feature or do I evolve and change an existing one? And the thing that I always like to fall back to is when you're looking at that list, there's a lot of things that feed into the prioritization, but you have to think about it for that net new logo for that early majority type of customer profile. What are the capabilities that you have to introduce or changes you have to make in order for them to give you that “yes”? And then the last component I always highlight is competitor positioning. You have to be able to talk about the benefits you're giving or delivering as part of this problem that you're solving and position it in a way where your competitors cannot emulate or copy you. In my mind, this is very critical so that we're not doing a feature bak-eoff, but really talking about it from the problem perspective and how can you position that against your competitors, where they can't just reuse it. 

Alright, so now we're getting towards understanding the problem. As I mentioned as a Product Manager, we have to have a good understanding of the problems and the challenges customers are experiencing. Because it is our job to articulate this to the Design and Engineering team so that we can start working together in ideating on a potential solution together. So the only way we can do this is by getting out there and talking to customers. And so before we actually make a phone call, there are a lot of signals that as a Product Manager we're gathering from our customer base. So it can be directly when you are talking to a customer, it can be the Sales team is engaging and they're providing you insights with regards to what is working well, what isn't working well. There are chances, or there are times where you're doing win loss analysis. Once you've acquired a new customer, you have to get an understanding of what's resonating and what is lacking. In certain organizations you might partner with Marketing on this, on the win loss analysis. But depending on the size of the organization, the Product Manager, the product owner, is responsible for delivering on that.

And then the last one is your Customer Service or your Customer Success organization. They are always capturing information, whether it's through cases that customers are reporting, future enhancements, or problems that are being identified. Key thing that I'm trying to drive here is you're receiving signals across different parts of the organization daily. It is our responsibility as product owners to make sure that we're reviewing them. We're labeling, classifying, trying to group similarities and identifying problems that are related to each other so that we can start looking at, as you're building out your roadmap and your strategy, which areas you wanna start diving deeper into. And my recommendation is always set a time aside on a daily. If you're doing this on a daily, you can share it with your team daily. You can really start prioritizing and identifying the problems you wanna start diving deeper so that it could influence and be added into your roadmap.

So now we're getting into defining the problem or distilling the problem and who is gonna be impacted. So in this scenario, you've gathered all this information. You can clearly start putting together a definition of what the problem is a customer's experiencing, what are the top concerns that they have with this problem, and the third question that I always like Product Managers to make sure that they understand: is there a solution in place today? And what this really means is has the customer solved this problem by building something themselves? By using a workaround in your product or stepping away and bringing in another product to solve the problem? So that's really important. And then identifying who is actually impacted. There are different personas that your products are designed for. And it's really critical for you to understand, is it the primary user - somebody who's interacting with a product multiple times during the day? Is this problem related to something that a Manager or somebody who comes in and explores the product on a weekly basis or on a monthly basis? It's really understanding who that persona is, what their interactions with your product will be, and the potential traits that identify them as early adopters or the majority adopter profile that we discussed earlier. And the last one is once you have all this information, you have a good understanding of what your problem is, and who's impacted it's time for you to define what your hypothesis is and who you're gonna go and talk to as part of your customer discovery. And this is really where I'll take a step back. I go and I speak to my Design and Engineering team to make sure that the way I've defined the problem makes sense. And then I also present to them what my potential hypotheses are that I want to go and validate with my customer base as part of this discovery. So the keeping I say here is: hold your ideas loosely. I think the key thing is when we're going through and gathering feedback from customer, the point here is not to validate your assumption of what the problem is. Having them surprise you in ways that you might not have understood or interpreted the problem correctly based on the signals you're receiving.

So once you have that in place, it really goes in defining that customer discovery program and pulling in the customer profile that you're gonna go after. So the key things that I like to call out here is make sure you don't bring in biases that support your hypothesis - make sure you include customers or users, right? You wanna talk to those who are your buyers. Who are actually gonna purchase the product, but also your technical champions, those who are using it. You wanna make sure that they have experience with your product. I ideally say six months and above if you're going after something that's an existing feature base, but also make sure that you're looking at your customer base across multiple segments and industries. The worst thing is for you to go and develop something that's meant for the financial industry when in reality, that's only 10% of your customer base. You wanna make sure that you get a sample of customers that cover all the verticals in which that you have a presence in. And lastly is geography making sure if you're an international company that you don't do all of your research within the US. That you're getting feedback from customers across all international countries that you sell into to make sure that you're taking all of their insight into consideration and you're building the best solution possible. So from the interview perspective, I always say, write interview questions that are non-biased and a way for you to gather this is by working with your Design and Engineering team to provide you feedback. I think there are a lot of questions that as Product Managers we have with regards to the problem and how we believe in it manifests itself within a customer's organization. Engineering and Design could give really good feedback with regards to additional questions that they might want to make sure we get answers from that will influence how they're gonna approach their part of the solution design or even implementation. And the two things that I call out here, it's part of the interview, is active listening and observing. And what do I mean by that? Once you defined your interview questionnaire and you're there, if you can bring in your Design partner, ‘cause it's always great to have two people taking notes at the same time. If you don't have those resources, then as a PM, my recommendation: ask the customer, if you can record the session so that you can then go back and listen to things that you might have missed. But in order for this to be successful, you really have to practice active listening and observing because there are opportunities where customers will open up and show you exactly what they're doing. Whether it's something they design on their own or their workarounds that they've implemented in your product. And so if you aren't going in with preconceived notions it allows you to really listen to what they're saying and be empathetic to the problem that they are experiencing in their environment. And then as part of this, make sure you're asking the right questions in your interview process. I would say practice the “five whys” to really get an understanding of the root cause of the problem that they're experiencing that might not have been communicated earlier on. And I always say, if customers are willing to spend 30 minutes with you to talk about their problems, they're willing to spend an extra 15, 20 minutes later on to see how you're actually going to solve it for them. So what I try to do is make sure that once I'm exiting my interview with them, I already have an idea of when I'm gonna schedule a follow up with them for us to prototype the UX. So that way as we ideate on the solution with the design scheme, we have a timeframe which we plan to come back very quickly and show them what are potential options that they will come up with. And then the last step is really synthesizing the feedback. And this is something that as a Product Manager, if it's a very small organization, it's something that we do on our own. We'll start going through all the responses and you're gonna start seeing things. Clusterings of type of feedback, similarities. If you have a UX and Design team work with them the more collaboration you have, you'll start identifying some of these themes that they might see that you don't. Synthesize it and share it with a team. And this is not just, your Engineering and Design team. This is really something I love to share with the Sales Engineering, the Customer Success, the full team that works with you on this feature. Everybody loves to hear customer feedback because it gives them anecdotes with regards to when we launch a feature, the problem that we're solving, it brings it there. And then the last thing with regards to synthesizing your feedback is prove or nullify your hypothesis. And it's okay if you nullify, it just means you have to go back a little bit to the drawing board. Based on the feedback, come up with a new hypothesis and then go and test it with two or three more customers and make sure, and we go through and gather learnings.

Alright. So now that we have a good understanding of the problem we've validated our hypothesis and we've proven it. Now it's time to define the problem. And here is where product management is still taking the lead and working with Design and Engineering to make sure that as part of our definition, we're including all of the information that was gathered during the customer discovery stage. 

And as part of defining the problem, you create something I like to refer to as a concept brief that you can ideate with your stakeholders. And this is not only your direct team, but also other parts of your Product and Engineering team to make sure you're getting full alignment across the organization. And in this area, what we're really focusing on is defining the problem and opportunity. And then really providing the guardrails and the definitions around the solution you're trying to build. And this is really like your north star, your guiding principles, that you're going to use for defining the solution. The personas, the potential risks, potential strategies around breaking this into a phase one, two and three before a full feature is delivered and then the product delivery. And this is really, as the Product Manager, what's your proposed Go To Market strategy? And the solution rollout to your existing customers or even prospects, right as they're evaluating. In my mind, as the Product Manager and the product owner, when we're talking about delivery, there's the delivery of the product itself, whether it's the SaaS service or something that you build for an on-prem solution, but then there's also the enablement of the whole going to market strategy. How are you going to enable your marketing, your customer success organization? So it's really good to have this, like pre-design across the concept and you can get alignment across your stakeholders so that you can get that green flag; you get your resources allocated, and then you can begin executing with your team. And the one thing that is really critical in the defining the problem is that alignment and that's really around the viability of the project. Is it something that you guys can actually execute across the different stages and clarifying the known/unknown. At this stage, there are gonna be things that you are going to learn as you go further down the product life cycle. And so clarifying any of those unknowns for the rest of your team will help you align. And then when you agree on the success metrics, you move on to creating your product requirement documents. That's gonna capture all these different stages in what you're trying to achieve

Alright. So next steps in the product development cycle, it's the ideate solution. And as the Product Manager, you work through the requirements with the full team, and this is an iterative process. I always like to say PRDs are not written in silos. It definitely involves your engineering and your design counterparts to make sure that requirement documents, it's like a contract that you guys are creating with each other and having a good understanding on how the problem, definition and the solutions are aligning so that we can work our way through it. Here the next stage is design and iterate. This is where your UX and Design team really get creative and they leave this effort. And our role as PMs is really to provide feedback and guidance. So we get to take a step back and see their art come to life at the development and testing. We're gonna partner with Engineering in providing guidance, but as I mentioned earlier, we have to be tech savvy. We're also gonna be involved as part of this testing. So we're gonna be supporting them, in testing our own products and then the roll out and maintaining. We are enabling the team by gathering feedback during the early access phase before we go generally available, we're getting that information to our engineering and design team to make sure incorporating the right changes for us to make a product or feature generally available. And we're aligning with our Go To Market team and making sure that we can get that rollout in place. And it aligns with the Engineering step of making this available within a service. And then of course we're responsible for the tracking of the success metrics. And we can go into all of these stages in a later lesson. But for now I think about this: It's a wash, rinse and repeat, you can use this process for any new feature or augmentation to an existing feature that you're doing. It's all about gathering customer feedback. It's all about gathering the customer feedback, understanding your role within the product life cycle phases and the problems that you're trying to solve for within the different stages. The second thing is really verify your understanding of the problem is correct through your customer discovery and customer feedback. And then the third thing is make sure you're synthesizing your learning and defining the problem with Design and Engineering team so that you can better execute on the vision you're trying to deliver.

Alright and with that, this concludes our session. So thank you for attending this lesson on how to identify the customer problem here at Abnormal Business School. Hopefully you're able to learn something today and I hope you have a good rest of your day.