All right. Am I ready to get started? Go ahead whenever you're ready. Ok, great. Well, we're gonna get going because we have a lot to cover today. Um So my name is Ali, I'm a product manager at postscript and today we're gonna kick off with a question.So for those of you leading teams, which would you rather a team that brings important questions, important problems to your attention or a team that delivers on exactly what they're told without question. If you're overseeing teams, I'm going to convince you why the first one is better.

And for those of you operating on one of those teams, I will show you how to be the problem raisers to be clear. We're not talking about complaining a complaint stops with finding the problem. We're talking about problems that call for ingenuity to keep your customers happy.

Maybe that wasn't even a hard question because there's so much out there on hiring smart people that ask why and on the importance of focusing on your customers greatest problems. So instead, let's see if it's actually happening and how ready our company cultures are to embrace it.

Here's some signs that it isn't happening. The team that is responsible for delivering the solution. So the ones that are actually doing the building and the designing start with the solution, not the problem. And this is quite common. The team considers a project done and moves on when the feature ships and is released to the customer. And as a leader who oversees these teams, the teams that build stuff, your teams don't challenge you on what's on the road map or ask you for proof that the problem exists. And if they do, their questions are often waved off with business decision, rationale, no questions. That isn't always a bad thing. So why don't we want teams that deliver on what they're told? No questions asked. Don't get me wrong execution is very important. You don't want to be on the other side of things where everyone is consulted, everything is questioned and no decisions are made. I've been on a team like that before and it's not fun. You want teams to deliver so solutions and feel a sense of urgency to get solutions in front of their customers.

But the difference is that the team should not be satisfied until the problem is solved and they should be learning new things about that problem as they design the solution. We're gonna talk about that more in a moment. But first, why does it hurt teams to hear what the business wants? Rationale you and your team will be celebrated. For delivering on exactly what the business asked. But keep in mind that often what the business asks for and what the business wants are two different things. What do I mean by this? Well, what happens, you know, after the release and metrics don't move, you did exactly what you were told. But so what customers aren't using the thing and the business isn't profiting in those moments, it won't help your case to say, well, this is what you asked for. And then where do you go from there? The team sense of purpose comes from doing what they're told. And now there's no affirmation from the business. So as a team member, you're thinking, well, where did we go wrong? How could this have been avoided? The right answer is, well, we didn't validate that the thing we were building was desired by our customers. But the more common thing to do is to blame, blame the business for demanding the thing. And the funny thing about the business is who even is the business in this context when we say it, we don't really know who they are.

The business is just anyone who isn't in the room right now and is more senior than the people asking this what the business wants. Rationale is also really harmful to retaining top talent. If your team is full of smart cleaners, then they probably do ask themselves. So what, why are we doing this? But if they aren't asking you because those types of questions aren't invited or even worse, they're being told the business wants it. They may actually start to lack motivation and then you're not going to get what you pay them to do. And finally, for your really tenacious team members who will persist in pursuit of the why you're giving them more busy work. You're asking them to work backwards from the solution to identify the problem. Confirm that it is a problem and when we're solving over others so that it's experienced by enough people and warrants a solution that will make the business money. And then they have to spend more time convincing you why you need to pivot. It's not fun for you, for them and it's going to delay getting better solutions to your customers. OK. So by this point, I'm hoping that I have somewhat convinced you that questions are good and blanket statements about business decisions are bad. But what does it take to change?

You have to celebrate questions about why decisions are made. And that also means embracing criticism. Basically, you need to encourage your teams to tear the application apart and you have to be ok with it. Teams need freedom to generate proof and pitch problems. Now, I think most of us would say that we give our teams freedom to do discovery work. But when I say freedom, I need paid, I mean paid time to investigate problems at the expense of jumping straight into tactics where I work at full script. The road map consists of missions to solve specific problems that then drive outcomes. We don't lead with the solutions that may get us there. You need to have patience, you need to encourage your teams when they take a few wrong turns on the way to their final destination. And this is where experimentation comes in which we'll talk about later as well. And finally, you need to provide some foundational understanding of the business. Help your um help your teams understand the basics of what value you're really providing to customers, the type of engagement game you're playing.

What makes your company uniquely positioned to win that game and how the company profits. Neil Patel, author and entrepreneur has a really good article on explaining what companies are really selling people choose to use your product for the benefit that comes from it, not the product itself.

So if we take the concept of purchasing supplements from full script, do people really care about the supplements or do they care about managing stress as a result of taking those supplements? One step further, they actually care about benefit. They'll personally receive a certain return from managing stress.

It's about mitigating the effects of stress so that you have more energy, less pain and can engage more in activities. People are interested in the payoff that comes from using the product or service. And for us, that means healthier outcomes that last. So help your team understand what pay off your customers get next. Help your teams understand their specific role to drive that outcome. Amplitude calls out three engagement games to win either attention, transactions or productivity. The attention game is where you try to maximize the time users spend on your product. You'd play this game. If you were in media or gaming industries. For example, the transaction game products playing this game help customers make purchase decisions with confidence. This game is played by Ecommerce platforms most commonly. And then there's the productivity game. This is where you want to help create easy and reliable ways for users to complete tasks. So this is the one I play personally by making it easier for practitioners to get the right supplements to their patients. You need to help your teams understand which game you're playing and then tie that to business goals. So for example, we as a company exist to help people get better.

I have a role in that by making it easier for practitioners to get the right supplements to patients and by helping practitioners through that process, I can then get more products in the hands of patients, thus contributing to revenue for the business. With this understanding, it's now my responsibility and the responsibility of my team to learn the customer pain points along that productivity game, build things that pay off for customers and then tie those gains back to revenue goals. If you encourage questions, carve out the time for discovery, embrace lessons learned and equip teams with the business foundations, you will be rewarded with a team that raises problems and makes you care about them and then solves them for you. You will have a team that operates as the business because at the end of the day, what does the business want? It wants the same thing that the team wants. So now what do the teams have to do? Teams have to be able to find meaningful problems by definition problems call for solutions. And since solutions are what we're, what we're after, the problem is the right place to start. But there's more than one type we're not talking about the simple problem. This is what Dave Snowden calls simple and obvious it's been solved before and can be solved again with best practices, simple problems are great to tackle first or alongside. Some of the more complicated and complex ones that are gonna take you longer to solve.

Since they're easier to understand. I'm gonna move on to the complicated ones that are solvable but have known unknowns. Basically, you know that you don't know the answer, but you know that you can find out this is when you call in the experts like your engineering team who can work out the cause and effect to make almost anything happen. That is if you work with my engineers at full script, um shout out to Justin and then there's complex problems where you can only figure out what happens after watching them unfold. I like to call these mysteries because they cannot be fully understood by reason, they require some degree of trial and error and you'll find that you'll find that these problems reveal themselves to you as you try it from different angles. So asking questions as you peel back layers and testing different solutions. This is where an experimentation mindset and designers who are adept to critical thinking will take you far. I'm gonna share a real example of this in just a bit. The reason I like complex problems is because we face them a lot on product teams and they're rewarding to solve. Is there a greater mystery than why people behave the way that they do?

Even if you haven't studied human behavior, you can still start to crack the code because even the greatest mysteries have patterns take a part of your consumer application where customers experience value. This could be a point where a transaction takes place or an important task is completed.

For example, at full script, when practitioners send their first supplement plan using our platform, they experience a workflow improvement, an easier way to get supplements to their patients. Now, you also have to make sure that the thing that you choose can be tied back to a company goal.

This this is this is how you're going to be able to measure the opportunity, ask yourself which top down business goal moves. When more customers do that thing. In my case, when more practitioners send plans more patients order, once you have your vo value moment, now map out all the steps that the customer must complete. In order for that value to be realized, you can now take a generalized view of what your customers are doing by looking at the proportion of your customers completing and falling off. Along each step from here, you can measure the opportunity work with your data team. And if you don't have those resources available, then do your own back of the napkin math, you're gonna need a couple of basic things. So the number and percent of customers who experience value an example from us. So like uh the number of accounts who send at least one supplement plan represented as a percent of total accounts within their 1st 30 days. And then you're also going to need to know the dollar value of these customers over a specified period. So for example, uh the dollar value of accounts over 12 months from creation based on whether or not they send at least one supplement plan within their 1st 30 days.

So now you'll know at baseline, the percent of your customers reaching the moment of value and the value of those customers compared to those who drop off. And now you can start to play around with different scenarios to determine a meaningful lift, use Google Sheets or Excel and see how the company's revenue goal would be impacted. If let's say 5% 10% 20 50% more customers were to send that plan within the 1st 30 days. Here in the 5% lift scenario, I took the new conversion rate of accounts that do the thing multiplied by the total accounts created from that. You get the projected number of accounts that do that thing multiply that by the dollar value per account and you have the projected revenue from the 5% left. The revenue difference in that scenario is only $8. So that may not be a meaningful target for you. Um And this is completely made up, but let's say you pursue a 20% lift. Now you have to identify where customers, where in the customer's workflow, you can make the greatest impact towards achieving that 20% lift. So go back to the steps that you mapped out previously that lead to that value moment and identify your biggest point of friction. Ideally, you can see in numbers where you're losing the most people.

But even without tracking in place, you can still gather customer feedback, talk to sales, talk to CS, watch real users go through the platform. There's tools like user interviews and user testing.com go through the flow as a team and find the points of friction yourself. Where are you getting tripped up and note that if you, if you don't have reporting, set up to track the completion of key steps within your application, that's a really good first step. You can make history today, which is my way of saying that if you get a view of what people are doing now, then you can see what they're doing tomorrow. There's great tools that can help you with this. Like mixed panel for us, we use mixed panel. We noticed a decent number of our practitioners dropping off at multiple steps. And upon some digging, we determined that some steps like a personal address field weren't necessary and were causing confusion for our practitioners. And this may be starting to sound like a simple problem, obvious can be solved with some best practices because we know where we're losing people and we know where they're confused, just remove the unnecessary stuff and make things clearer. We did that, but it only took us so far because what you can't see from the numbers or the even the feedback from customers is the mystery of why people behave the way that they do in the real situation and not the hypothetical one.

This brings me to the next thing that teams have to do. Teams have to be able to build problems alongside evolving problems. Marty Kagan, a thought leader in product management says that the best designers evolve the problem space and the solution space together. This is because as they start to design out the solution, they bump into implications for their users. So decisions that the customer has to make consequences to those actions that they take and complexity and how to do those things. So as the designer is looking at the solutions, they're learning more about what's causing customers to behave in unexpected and unwanted ways. And as they gain a deeper understanding of the problem, new solutions become possible and a lot of these discoveries happen only after you put out a solution in front of your customers and they do the unexpected and unfortunately not the thing that you wanted them to do. So, don't move on to the next problem because you don't understand it yet. Instead you need to ask, what did I misunderstand about my customer? My problem, the practitioner drop off issue was a mystery and I'm sure you're facing mysteries too. We can't explain why the problem exists yet because why do people do the things that they do? So call, call up your best designer and you can't have mine.

Her name is Bertie and go on somewhat of a murder mystery or like the game of clue for anyone who's played. So you do a little digging, you find a weapon in our case, a trait or behavior that leads us closer to the solution or the murderer in the case of the analogy. But that clue doesn't lead us right to the end. It brings us to a hidden passageway or a dead end. This is the trial and error that I was talking about earlier and why leaders need to keep on encouraging their teams when they take a few wrong steps, wrong turns on the way to their final destination. Our mission to make onboarding easier, tackled three points of friction. And for just one of those points, we ran two failed experiments before the third succeeded. But in the end, it paid off because we increased the percent of practitioners who reached for value moment by 30%.

And I don't think we would have been as successful. Had we abandoned the problem or tried it, tried to do too many attempt, too many problems at once. It looks like this. We thought we knew the problem. We tried a solution. We watched customers go through the new flow that led us to a new understanding of the problem. We tried another solution. We repeated this once more time until we succeeded and reached the objective that we identified earlier. This by the way is how I define experimentation visually.

In my mind, it's a step and repeat, which is what I've tried to draw on the left. It's not throwing a bunch of shots in the dark to see where they land on the right. You can do that and there are points in time where you need to do that. But when you're tackling a specific problem, expect to find layers and know that those layers will help you plan your next move, be prepared to spend more time on the problem and make sure that your problem is worth spending time on. This is again why it's so important for teams to raise the right problems to leaders or you may find yourself halfway through a project and discovering that the problem isn't worth the while teams also have to make people care about their problems. It's hard to make people appreciate why the night you're trying to crack is so difficult, especially when they're not living the problem, day in and day out. So you need to make people care, you need them to experience the problem themselves. You need to connect that problem to the business goals and you need to show proof that there's demand from your customers for a solution. In practice.

This means making those pain points felt, selling on the lost opportunity and showing the iterations, show the new problems you find, show the results of the test, explain what they've taught you and the new directions that they're sending you on when you arrive at the final solution.

This backstory of how you got there will help get people on board and inspire more problem for solutions in the future. And finally, teams have to hold themselves accountable. What does this mean back to the leaders in the room? You are going to get better results. If you give someone a problem and you make them own it And by that, I mean, the freedom to solve it within working hours and the recognition when it's solved. But also holding those teams accountable when the problem is abandoned without reason or dragged out without cause and note the phrasing of abandoned without reason. If your team discovers that the problem is invalid, that's a win. They've spared you time from solving the wrong thing.

And as we've said, it should be expected that there will be a few iterations that fail before getting to a solution. So if you take the team off the solution before it's solved, then that's on you, not the team, but as a team, you need to own problems, that means not calling things done until you've made the meaningful difference. And if you don't think there's a meaningful difference to make, then it's up to you to speak up. So then when do you become the business? When you stop deferring to what the business wants and leaders start coming to you because you have the answer, you know where the biggest opportunities are and you have a game plan to understand the problem better and you know how to tie those outcomes to business results. You can hire the right people, the critical thinkers and problem solvers. But until you get people to be the business, it's easy for people to just do what they're told, which is why it's critical to celebrate the wise, make time to investigate the problems and equip your teams with the basics of the business.

If you want to learn more about what it's like to be on a team of problem raisers, check out our full script booth. Otherwise, thank you so much for your time.