A product manager solves user problems. It’s our job to understand users and deliver solutions to their problems. During this process of discovering, conceptualizing, and delivering, we always stumble onto one key question – what do we ship first?

Let me try and build an analogy around that. Let’s say you have 5 favorite movies of all times. You can watch these movies one last time before they’re purged from existence. What order would you pick to watch them in? Easy. You have a preference, but it really doesn’t matter.

Now let me make it more challenging, what order will you watch them in if the ‘time to purge’ is between 1 hour to 24 hours. This means that you might be watching something and 3 hours in, all the 5 are purged. What now?

Product managers face similar challenges when it comes to prioritizing what to build & deliver first. There are several models that can be found on the internet, but I’d like to talk about one that I use the most – the BUC framework.

BUC tries to quantify the ‘net benefit’ of every solution, potentially making ranking easy. It does this by splitting the ‘net benefit’ calculation into 3 distinct components – business value generated (B), user value generated (U), and cost incurred (C).

Now, since I started this article by stating what I believe the core function of a product manager is, I’d like to focus on the U component i.e. user value generated. I’ll likely focus on the other two in some articles in the future.

User value is one of the trickiest components to quantify. It involves deeply understanding what the user wants and why. In the B2B SaaS space (one which I thrive in), this value is typically generated by solving a business problem that the user may have.

Say for example, the user wants to get faster at his or her work i.e. improve productivity. There are several problems that a user might face under this macro objective. But having an outcome driven approach makes the whole quantifying process more intuitive because we can start categorizing problems.

Let me dive in deeper. All user problems within this frame of reference – get things done faster, can be categorized. We can build a chart as follows based on research.

We’re now in a better position to decide what we should focus on first. It goes without saying that the most severe user problems that occur most frequently should be in our crosshairs. We could have more variables besides severity and frequency, but incremental variables may not necessarily improve our prioritization efficacy. After all, these classifications are also our best guess estimates.

In some cases, an additional variable or layer might add significant value. Geography for example may be of importance because the severity and frequency of the problem may vary depending on the geography of the user. Whatever be the case, problem categorization helps us rank user problems, becoming a guide that helps us assign a more robust ‘net benefit’ value to the U component of the BUC framework.

In conclusion, what if we could ‘front load’ a solution’s user value generated component closer to what users experience first – the problem? It just seems like a more intuitive and user centric way of building a roadmap.

Allocating resources to supercharge product growth is tricky. It’s even more tricky in today’s VUCA world. The idea behind this article is to pose a question to product leaders and executives. It’s a question I’ve encountered several times working on a wide range of software products.

But first, I’d like to clarify the two key terms I’ll be using. These definitions are out of a textbook, but I’ve noticed that they’re often used interchangeably. 

Lean: A methodology that focuses on minimizing waste while simultaneously maximizing productivity. Waste is seen as anything that customers do not believe adds value and are not willing to pay for.

Agile: An ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.

For further context, I’d like to talk about an example company – Zara. Why Zara? What does it have to do with software? 

Well, I’d like to use Zara’s supply chain as an example of delivering value. The supply chain here is akin to software development – it starts by understanding the customer and ends with delivering value. 

Zara has one of the most spectacular supply chains in the retail industry. I’m no expert, but I do believe that the company has found the right balance between lean and agile.

The company gathers market needs and truly understands what its consumers want by empowering store managers. It then caters to these needs through quick development & iteration cycles using its vertically integrated supply chain. This sweet spot between lean and agile is what I call the surge spot.

A product operating in this spot will experience a surge in sustainable revenue growth – the gap between its potential growth rate and actual growth rate diminishes.

If we apply this to the world of software, we’d end up having to choose a spot between two very different strategies. The mix will have to be just right for the product based on its life-cycle, the type of users it helps, and a whole other set of factors including resourcing costs and company culture.

Therein lies the dilemma. As product managers we pick these surge spots all the time. It depends on the area of a product we’re working on, the user segment, and other micro factors that we come across during an initiative. This is a lot easier than choosing a spot for the product organisation as a whole. To make matters worse, the spot isn’t fixed. It changes and evolves with the product. It’s a wildly moving target that is dependent on a host of factors. 

I’ve used just one variable – the type of customer a product services, and created potential surge spots.

In the enterprise B2B space, the default configuration for a product that is at the lag end of its growth phase, is a tilt towards lean. While the B2B space for SMBs is typically more agile given the nature of its customer base.

Finally, a B2C product has a significant agile tilt due to the extremely fickle user environment it operates in.

It’s simple when we look at it from a unidimensional perspective, but adding just one more variable can lead to significant complexity. 

On that note, I’d like to ask all the product leaders and executives reading this – Where’s your product’s surge spot?