Practical tips for dealing with product reality


2024 has not been the best year for the product management community.

Tech companies continue to right-size their staff after overheated hiring during the pandemic. Anecdotally, those cuts seem to hit product managers particularly hard.

Whether that is the case, the product management job market has certainly tightened up from the free flowing money days of 2021 and 2022.

Then, the release of Transformed: Moving to the Product Operating Model seemed to draw wildly different reactions from the community. There was the expected joyous rapture about its release.

There was also a significant amount of blowback. Folks pointed out that very few organizations meet the criteria for “the best” product companies and probably never will. They also didn't appreciate the perceived implication that PMs who work in “the rest” of the organizations were partly to blame for their predicament.

The discussion was interesting to watch, but it wasn’t very productive. Fortunately, one outcome of that discussion was a few actionable articles that spoke to how product people can make the best of working in one of “the rest” organizations.

These suggestions are relevant for people who work in tech-enabled enterprises, so I wanted to share my interpretation of that advice. Hopefully, you can apply some of these ideas to make your current job more enjoyable and position yourself to make some great leaps in your career.


Discount to INDUSTRY Conferences

My friends at Product Collective regularly put on the premier conferences for software product managers. Even better, they put on three in person and one virtual conference each year so you have your choice of where to go.

The conferences coming up are:

New York Product Conference April 18, 2024 New York City, New York USA

Industry Europe June 17 - 19, 2024 Dublin, Ireland

Industry Global September 23 - 25, 2024 Cleveland, Ohio USA

Industry Virtual October 17 Anywhere

Registration is open for all four conferences. Go here for more information.

Plus, if you use the code INSIDEPRODUCT50 when you check out, you get an additional $50 off your registration. (Full disclosure - this is an affiliate offer)

And something else to consider - I’ll be at the New York Product Conference and Industry Global this year. I’d love to see you there.

Register Today!


Look at things from the perspective of “the business”

The terms “IT” and “the business” is a big contributor to the difficulties you face working in a tech-enabled enterprise. The phrases come about because the makers in tech often sit in a different organizational silo that the people who use the stuff the makers make.

This tip is not to invoke a reorganization to break down those silos. While nice, that’s probably above your pay grade. Instead, John Cutler suggests looking at things from the perspective of people in “the business” in order to understand why they behave the way they do.

  1. They think they’re doing you a favor by providing specific requests.
  2. A lot of different people need tech to do things, so they want to make sure they get on the list.
  3. Just like they ask for commitments from you, they have people they owe commitments to as well.
  4. The people who approve their projects expect explicit output focused plans.
  5. Their history with tech has not been altogether pleasant.
  6. Most of their exposure working with tech is through highly controlled projects (fixed scope, detailed requirements) Tech has, in effect, spent 30 years teaching them how to be bad stakeholders.
  7. Organizations that don’t sell the software they develop see added complexity.
  8. Organizational silos create difficult product manager/business stakeholder relationships.

When you consider the things John describes in the article, you’ll have more empathy for the people you’re building things to support and will be less likely to take their actions personally.

Love the one you’re with

(Hat tip to Steven Sills)

Chances are when you find yourself in a less than ideal situation, you’re first going to try to make it work before you hunt for a different job. That may not have been true a couple years ago, but with the shift in the product job market sticking it out may be better option.

Aakash Gupta provides some advice on how to survive and thrive in a feature factory. The general gist of his advice comes down to six principles that I’ve paraphrased below:

Accept that you work in a feature factory

figure out how to be effective in the current environment instead of trying to transform it all on your own, unless you’re in a leadership role in the org.

Adapt to your environment

Figure out what role your organization is really expecting you to do, and fill that role as best you can.

Often, that means you’re expected to be a delivery lead, not a product manager. This can work to your advantage if, by being called a product manager, you get paid more than what you would if you had the title that corresponds to what you’re actually doing.

Either way, make sure you and your leader have a shared understanding of what the expectations are.

Create a Promotion Path

Talk to people on product teams who recently got promoted and find out what actually drove their promotion. After you talk to a few folks and dive deep into their experiences, you’ll be able to identify trends that led to promotion.

Introduce practices to solve problems

Once you’re meeting expectations in your role, identify places where you can introduce good product practices to solve particular problems. When you explain what you’re doing don’t say “this is how product management is supposed to be done” rather, say “we seem to have this issue - let’s try this to solve it.”

Build Your Coalition

Establish strong relationships with the designers and developers you work with by making their lives easier. Get the engineers more time for refactoring, testing, and addressing technical debt. Advocate for designers to have more time for user research and testing.

If you have their back, they’ll have yours.

Make the most of it

Working in a feature factory is not ideal, but it provides an opportunity to get really good at delivery and increase your ability to ship fast and engage stakeholders.

Look at your job as a learning opportunity, or at the very least, a character builder.

Guerilla product management

Along with introducing practices to address issues in your day to day work, you may also gain skills commonly associated with “modern” product management.

I heard this advice repeatedly from people I interviewed who moved from business analysis roles into product management roles.

John Cutler shared these ten tips for practicing product management in a feature factory.

It's especially useful for people working in tech enabled enterprises, where the chances are that they're working in a feature factory are pretty good.

  1. Start collecting data about how people use your product. Use that data to guide future decisions about what you do and don't do.
  2. Interact with the people who use your product regularly. If your organization's customers don't directly use your product, make it a point to understand how your product indirectly affects them as well.
  3. Learn how your business makes money ( or why it's not).
  4. Collaborate with makers
  5. Write initiative briefs that start with the problem to solve and lead to the solution you've been told to deliver. See if there is a connection between the two that makes sense.
  6. Establish goals around adoption and usage.
  7. Talk with stakeholders about how your product impacts them and vice versa.
  8. Repeatedly look at your work from an outcome perspective
  9. Find others who would like to see your org adopt a new operating model
  10. Look for places to strategically use words that imply a different way of working. The easiest one I've found is to not use "resources" when referring to people.

Say “Not yet” in the right way

I have yet to find a product team that didn’t have enough to do.

Product people are usually inundated with additional requests, demands, ideas, suggestions, escalations, bug reports, and customer complaints.

A typical team can finish a few small things each week or make progress on one or two large things. So in order to stay sane, product people are going to have to say “not yet” to a lot of things regularly.

But how you say “no” or “not yet” plays a big part in how much you’ll be able to focus.

Rich Mironov explains that instead of using “the process” or being out of capacity as an excuse to not do something, use the language of money and high-level tradeoffs to say “not yet”.

Here’s one example of what that may look like.

“Roadmap Items X and Y specifically benefit your functional group, and were the ones that your directors prioritized as their top two. Do you want to postpone/cancel those in favor of this? Let’s check back with your folks”

Rich provided several others in the article

At the same time, ask your product leader to provide you with organizational “air cover” to postpone almost all new requests.

Research product management, but don’t drown in data

Part of becoming better as a product person is researching techniques you haven’t used before, but may have a good opportunity to try it out.

There’s a fine line between doing enough research to get started and diving down a rabbit hole.

Clement Kao put together a guide to help you manage the information overload.

He suggested three filters, some red flags to look for, and tips to put the theory into practice.

While his guide focuses specifically on dealing with information about your product, you can use these filters about information about product management

  1. Relevance - pay more attention to the information sources relevant to your context.
  2. Actionability - favor those sources of information that can lead to direct action. There's a lot of product management thought pieces out there that may be interesting to read, but if you have limited time to consume information, favor those pieces that you can apply to your work that day or the next.
  3. Depth - Go as deep as you need to in a particular topic, and no deeper.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent J. McDonald
Founder | KBP.Media

InsideProduct

Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!

Read more from InsideProduct

I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...

I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...

For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...