Focus on the unhappiest, most dissatisfied customers first

I’ve been meaning to share some learnings I’ve had over the last year for a while. In fact, I had my entire list written up in January…

I’ve been meaning to share some learnings I’ve had over the last year for a while. In fact, I had my entire list written up in January, but somehow we are already in May!

As a PM, I very aggressively PM myself (not just the products I work on). Whenever I make a relatively large decision, I think about if I think it was the right or wrong call, and try to define the underlying reason / principle that led me to make that decision. That way, the next time a similar question comes along, I can use that same framework of thinking if I think it’s valuable.

The problem with at lot of PM mantras out there is that they either focus on execution (like how to work with the people around you) or they work better at larger companies (where you are making more incremental progress and have more resources). I’ve found that in most cases, decisions that I’ve wanted to improve usually happen when I apply a way of thinking that is either not appropriate for the stage the company is at or is informed by a backwards looking way of thinking.

At a startup, it’s inevitable that we make mistakes, but it’s important to rebound quickly. Startups are incredibly resource constrained. We don’t have enough people to build the features we want, we don’t have the capital to dabble around forever, and we have investors (and employees) to satisfy. It’s almost like we have just one egg to put in one basket, but at least we can swap baskets quickly.

The above was a long-winded way of saying that I’d love to share the “reasoning” I’ve developed for common start-up product decisions and would love to solicit opinions and thoughts as well! I anticipate writing more of these over the next couple weeks, but for this first article, I wanted to focus on figuring out who your target user is.

Focus on the unhappiest, most dissatisfied users first.

At both companies I’ve worked at, the first thing I worked on was identifying what use case to go after. Any PM would naturally approach this by 1) looking at the data and 2) analyzing and breaking down the different user personas.

The problem is that data is scarce in the early days, on top of being incredibly noisy. Spoken from experience — you really can twist data to say whatever you want it to. To make things worse, correlation != causation… What if the sector with the most users also has the lowest ASPs? What if the sector with the least users have the highest ASPs? Now what?

Ok, so the data is hard to interpret, so you have to dig in a little lower and really focus on the users. You might break up users by sector or persona and use that to figure out what value props you offer to each different user group. Having done this multiple times, I’ve noticed that the biggest weakness of doing things this way is that it is an incredibly biased way to figure out what the value prop is to users. It’s really easy to break users up into sectors and then map your marketing content to the different users group. Not effective.

What if we dug in deeper to map out the flows? So, in sector 1, users tend to do these things while in sector 2, users care more about this other set of things. The problem is that this is a completely observational way of thinking about things. So sector 1 does this and sector 2 does this. So what? Which one is better or more important? Further, what if you defined your sectors in ways that don’t actually segregate things appropriately?

At this point, I’d like to point out that I’ve done all of the above and more, and the problem is that you end up at a point where you’ve analyzed things and cut things differently, but still can’t decide. Now that I’ve had some time to see some of the decisions we made pan out, here’s what I think is a more effective way of breaking this problem down.

Segment users first by problem statements

By doing this, you’re able to really focus on what problem you are solving for users. If users don’t face different problems, don’t arbitrarily group them into different user groups. At the end of the day, users might consume a product differently in terms of GTM based on the sectors they are in, but if they face the same problem, you can build for that problem statement.

Focus on a problem statement that is causing pain TODAY

This doesn’t mean that you don’t innovate — instead, it means that you need to choose a problem statement that exists today, not something that might become a problem in the future. The user persona that needs a solution today for a flow that they are currently trying to do right now makes for a much better user than someone who hasn’t decided if they have a problem yet.

Now, bring the data back in

Data is still really useful, and it’s after you’ve fully understood the problem statements that users have that you can go back and try to understand the data. For the sector that had a lot of users, is their problem statement more or less painful than the sector with fewer users? If their problem statement is less painful, you’ll have a harder time selling your product, convert fewer customers, and ultimately have less satisfied customers. As long as the sector with fewer users isn’t significantly smaller, in most cases it makes sense to tackle that sector first.

To close out — a quick note on execution (since analysis without execution is kind of pointless)… Knowing that you are building for a user that has a very real problem helps guide your roadmap. Now you can think about what features are compelling to this user group and how to best deliver those features. You might still get users in other groups, but since you only have one egg to put in one basket, the issues that crop up from other user groups should largely be ignored until you decide that you have more than one egg that you can now diversify across a portfolio of products.