Under Pressure: How Economic Pressure Makes Us Better Product Builders

In the past two years, the macroeconomic situation has had a significant impact on the context of most companies and set new boundary conditions for our ways of working as product people. In short: We are under pressure in ways most of us weren’t before.

Let me be clear up-front: This post is not meant to glorify the fact that many great people lost their jobs as a consequence of this economic pressure. I hated letting great people go and I know many more great people who were affected— some who still struggle with the consequences. In most cases I’m aware of, it was not a reflection of people’s skill and qualities when they lost their jobs, but rather the larger economic forces at play. As I’ll discuss in the rest of this article, unfortunately, many of us in the product world were not accustomed to seeing our work in this broader economic context, which is why these layoffs were especially painful and unexpected.

At the same time, I feel that some of the changes that we were initially forced to apply by economic pressure also have positive aspects we can appreciate from a professional or craft perspective. And since I doubt that we’ll find a big “undo history” button any time soon (as much as I love this feature when recording music in the Logic Pro audio software), I feel it’s worth familiarizing ourselves with the new realities and trying to appreciate their positive aspects.

I had the pleasure of discussing this topic with Gopika M., Megan Caywood Cooper, and Matt LeMay on a panel during Turing Fest in Edinburgh. What follows is not a summary of that panel, but my personal perspective on this topic.

I’ll start with what I consider the most important and most intuitively positive change:

Profitability is our job!

After many years of focusing on growth and scaling as the primary goals, it took many people I know a while to accept profitability as the new primary goal. 

Looking back, it feels strange to me how long a significant share of product practitioners could comfortably ignore the mundane fact that it DOES matter whether or not the business we work for is profitable. And it’s remarkable to see how little many of us knew—or even cared—about how the product we were building contributed to the company’s profitability. And it’s even more remarkable that in many organizations this was totally accepted as long as we could demonstrate how we contributed to user growth or activation. 

By the way, I’m consciously writing “we” here, because I, too, was part of camp growth and activation and I still remember how the few people in my company who challenged this perspective were regarded as outliers.

I’m glad that these naive times are over because I feel that even if our area of responsibility is officially connected to growth or activation, it’s totally OK to also expect us to care about the company being profitable. And to understand how what we do contributes to this. And to be able to articulate this and be competent enough to explain it to “non-product people” such as our CFO—in their own language, not by “productsplaining” (a term I first heard from Fabrice des Mazery) and boring them with our favorite product lingo.

If teams (or their product people) are not able to do so, the root cause for this is often a consequence of how their organization sets goals: In his Turing Fest talk, “The Business is Your Business,” Matt LeMay shared some perspectives from his upcoming book Impact-First Product Teams. Matt observes that too often teams lack clarity on how their day-to-day work creates impact for the business and points out that this puts them in a very vulnerable position. 

If you don’t know how you create impact for the business, you’ll have a hard time justifying the investment your company is making in your team if times get tough (or stay tough). Matt recommends to first of all understand what success means to the business, set team-level goals that contribute meaningfully to the business’s success, and keep the day-to-day work connected with these impact-level goals.

Matt connected this recommendation to Christina Wodtke’s point that in larger organizations the use of OKRs as a long cascade of goals can often be the source of “disconnected” team goals. And that instead of cascading goals, it helps if team goals are directly connected to company goals.

Depending on our influence, an individual product person may not be able to change their organization’s goal setting, but what we can and should do is to actively aim to connect what we do with our teams to the company’s primary goals and to the profitability of the business. If we do this, we can also explain much more clearly to other departments what we bring to the table.

To summarize this first point: I feel it was high time we started taking our contribution to our company’s profitability seriously. Let’s stop treating it as somebody else’s job—we can and should contribute!

Get out of your silo, we can only win together!

One positive side effect of caring about our company’s profitability is that it forces us to get out of our silos and connect with other departments such as sales or finance. If we want to understand how we contribute to our company’s profitability, we need to understand how the business is making money and which motions it pursues to do so. 

In my own work environment, I have observed that this helped to bring different parts of the organization around a joint goal and with the incentive to better understand how we can succeed together. Part of this is finding a common language, another part is simply caring about what “they” do (which, based on my observations, many product people didn’t really bother doing as long as they could hide in their non-financial goal silos). Many of us may also just have been too arrogant to seriously connect to and team up with sales until the changed realities of the business forced us to do so.

Just as with being able to articulate your impact to the business in terms other departments understand, I also see this natural need to collaborate as an immense learning opportunity for product folks and as a chance for the organization to use the combined power of different perspectives and backgrounds to its advantage.

Treat any staffing as an investment

Another positive consequence of no longer seeing profitability as somebody else’s job is that it also helps us to clear up a misconception I have often observed in product development teams: The assumption that existing teams come “for free” and that it’s only a question of how to apply their capacity most impactfully. As we’ve seen in the recent layoffs, we cannot take existing staffing for granted and while this is truly uncomfortable, I think it’s a healthy shift of perspective.

In the past, whenever I encountered teams that were at risk of putting far too much effort into a perfect implementation of something that in isolation had its good reasons but had only little impact for the business, I helped them understand what it cost the company and asked if they would invest this amount of money if it was their own. Putting an exact number to what it costs for a fully staffed team to spend three quarters on a project (as an example), can really make their work less abstract and more tangible.

My hope is that such conversations will happen earlier and more often in the future because teams want to create real impact. Ideally the culture of the business supports this being a source of team’s price more than a consequence of fear.

Adjusting platform scalability investments to actual needs

As with staffing, I feel that the new economic realities can also have a healthy effect on how we think about platform investments. I have been in charge of platform products and I know that it’s in the nature of such efforts to prioritize non-functional requirements like scalability and extendability. 

Such teams will often take inspiration from examples shared by teams in very different contexts. As a consequence, there’s a natural tendency to aspire to solve things with as professional and waterproof a solution as the team from  (insert your favorite big global brand here). 

I have been part of such considerations myself, but I think that it’s important to question how our ambitions fit with the reality of the business. In other words: If your B2B business is currently used by a few thousand customers with a total of 50K users, how important is it to ensure that your platform can scale like Spotify vs. ensuring that your company is still in business one year from now?

I still strongly believe that even in times of pressure we will need to make reasonable platform investments (and I know that it takes extra effort from product and tech leaders to fight for this!), but it’s in our interest to invest in what’s really needed and worry about large-scale challenges when there’s a clearer indication that we’ll really run into such “luxury problems.”

Learning velocity—now for real!

We’ve been talking about fast learning cycles in product ever since Lean Startup came out. But be honest: How often have you polished your cheap experiments just a little bit, and a little bit more, and a little bit more… just because you could? 

In a situation where the existence of our company may depend on decision speed and informing those decisions with experiment-based learning, we have a stronger incentive than ever to really look for the quickest learning option and be more brave in exposing real users with early experiments. Yes, this is uncomfortable and yes, it comes with its own risk, but in general I feel this is pushing us to act on what we’ve been talking about for a long time.

Better arguments to push for focus

As product people we want focus, but that means saying no to a lot of things. And after many years in cross-functional leadership teams, I know that getting such a leadership team to agree to saying no to almost everything is tough. 

Under more economic pressure (and in particular if you’ve had to reduce development teams), it becomes more obvious that if you try too many things in parallel, you realistically won’t be able to make an impact fast enough. So it’s your chance to push for focus. Of course it comes at the cost of increased pressure on what you focus on, but that’s where your increased learning velocity becomes helpful.

Show how you help to de- risk and innovate like a pro

Finally, I feel that the current economic pressure also poses an opportunity for product folks to show how our ways of working and our perspective can be helpful for the business at large. As product people we have learned to de risk assumptions and how to compare innovative opportunities for their potential. These are the kind of skills a business under pressure not only needs for incremental product decisions, but also for the business as such. So let’s see how we can help to bring our mental models and methods to our new cross-silo rounds of conversations and how we can help the business navigate tricky decisions—and ideally, win. By the way, this is a relevant additional layer of showing how we not only contribute through our product but also with our general problem-solving and decision-making competencies.

But beware: Even if our mental models and frameworks really can help the broader business, it’s still safe to assume that our colleagues don’t like to be “productsplained”. So try not to run into the trap of losing them with too much product lingo and instead just apply what you know in terms that they are familiar with already. If it goes well, you can disclose at a later stage that the perspective you just took to contrast and compare different opportunities in a structured way is also referred to as the Opportunity Solution Tree.

Let’s stop complaining and instead embrace the positive effects of working under pressure!

To conclude, I feel that even if our past conditions of building products may feel more comfortable, it’s worth adjusting to the new realities of operating under pressure. First, because we shouldn’t expect the pressure to go away soon, but also because there are aspects of it which can help make us better in some aspects of how we build products in ways that also serve the business.

I’m aware that some of my statements above may be controversial to some and look forward to your feedback—or to hearing about any additional positive aspects that I may have overlooked.

Previous
Previous

Talking Clarity on The Product Experience Podcast

Next
Next

Clarity for Product Leaders