Lessons on being a solo product manager in a non-agile organisation

There is a thought experiment in AI called the “Chinese room”.

I am in a sealed room. Notes are passed under the door to me — queries written in Chinese characters. I look up each phrase in a big book, carefully copy out the corresponding response, and pass it back under the door.

From the perspective of the question-asker, I “understand” Chinese, but from my perspective, I’m just manipulating symbols.

I’m not that interested in the implications for AI, but I think this is a handy way to think of the conflicting demands on a lone product manager in a non-agile organisation.

Nowadays, digital products are often developed by cross-functional teams of experts who unite around a problem that the organisation or users are having. The product manager/owner has sole responsibility for balancing many needs, figuring out what to build and (most importantly) what not to build.

The team understands that not everything that could be done should be done, and they can decide between themselves when an organisational need should overpower a user need, and vice versa.

In a truly agile organisation, the product manager is trusted enough that they can say no to stakeholders.

If you put all the responsibility for a product’s success on a product manager, but don’t give them the ability to refuse stakeholders when they feel it’s right, they will inevitably struggle.

Maybe something was promised to the users by stakeholders long ago and needs to be delivered by a certain date, regardless of what else is in the pipeline. Maybe other teams aren’t interested in changing their processes to make use of the new product right now, and demand that it behaves exactly like the old one did.

Both of these have happened to me, and both are reasonable demands, but every concession the product makes to demands like these waters down the vision that little bit more.

The notes come in under the door, and the product manager just passes them on, without truly understanding which are the most valuable to users.

And in this particular case, the notes are passed onto an agency which actually builds the things. The product manager is really just a relationship manager between a group of businesspeople and the agency.

There can be bad consequences to this whole setup:

• You might build the product you promised, but not necessarily the one users need
• You don’t understand how your own products work, and struggle to understand how to fix them when they break

It’s not impossible to deliver good stuff with this kind of set-up, but it’s certainly much, much harder.

Being allowed to say no is the number one test of whether an organisation believes in its product managers or not.