Simple product management tricks

The last point is one I've been employing very successfully lately. I think Toyota speaks of it as "figure out a really good process using humans first, then consider automating."

Doing something manually takes less time than you think if you create a good standard sequence that irons out most of the mechanical waste involved. Once the process starts to provide a lot of value (or no value – which is most commonly the case!) you can decide to automate further (or not at all.)

But also at that point you have to be careful. Automate little steps at a time. Automate the easy, happy path first and quickly bail out to the human operator if something goes wrong, then reconsider if the economics are still in favour of further automation. The last percent of automation are invariably the most expensive, by far.

For three, I've been trying an approach that I took from an HN article a while ago. Instead of a Playbook, create a Python script that just prints text for each step and prompts for YES to confirm the step was completed. Then, I automate the most confusing or particular parts. Need a particular user to perform the task? Query for it and make a link to login as that user for the operator of the script. You get a lot of the repeatability of a fully automated script and slowly improve it over time.

This might be a simplified generalization but: every good product manager I've had focused on people, every bad one on processes and "simple tricks".

Let's take the automation point for example. Some workers deliver the "theory" graph from the article, some deliver the second. And it's pretty consistent. A good worker knows when automation will pay off and when it's a waste of time. Let everyone try the first time you work with them and only intervene and adjust when necessary. With time you will learn who knows what the hell they're talking about and who doesn't. Who delivers and who just wastes time playing. You have NO way to know before.

And even if the investment does not clearly pay for itself for that task: a year ago they let me (linux sysadmin) take time to learn Go for a small thing. I could have done it in python in 1 day, it took me 3 weeks to deliver a Go version. Totally not worth it. But since then I've dived into multiple Go tools we use and significantly reduced our servers hardware requirements. I've even submitted some patches upstream.

I've read (and probably written) many a playbook that has dated badly.

In many cases having the playbook was worse than no playbook at all because it drove me down some blind alleys ("oh yeah we stopped using that acccount for X months ago..."). You can often not be certain if it's you who did something wrong or a bug in the playbook, especially if some elements are vague.

In other cases I've written a playbook, somebody else has read it and missed step 4 and we've together spent many hours tracking down the issue in a playbook that ought to take 5 minutes to go through if run consistently. And conversely ive done the same thing - we are all. fallible.

I think even for tasks that are run infrequently code automation can be more cost effective because it can avoid the above scenarios by being executed consistently and failing noisily and obviously.

All of these product management processes seem to assume there's no underlying maintenance or tech debt that needs some level of attention. And there almost always is, but it's really hard to measure impact because it's usually "hidden" (that is, it's not a direct impact, but it ultimately affects velocity, on-boarding, developer happiness, etc). So with "tricks" like this they get relegated to "low impact", while "high impact" (typically "user facing features") get prioritized.

And there's lots of other things that have hidden or very difficult to measure impacts. These often revolve around developer happiness and growth. For example, ignoring a complex, bugging and/or aging codebase can affect attrition (among other things), which will quickly get _very_ expensive: as a team starts losing developers, the remaining developers have to carve out more and more time to interview and onboard. Not to mention the direct company costs of turning over employees. And trying to find quality employees who are willing to work with in that codebase.

And maybe this sort of thing should be addressed "out of band" - ancillary to the product management lifecycle. But that's really hard to maintain in most orgs.

Talk to customers. Talk to customers. To talk to customers. A 2 minute talk with the right customer is worth a day (or a week’s) work in a vacuum. You have to talk to a lot of customers to talk to the right customer.

Pretty basic list to be honest. Intercom.com has some infinitely more detailed insights on how to manage products.

E.g.

https://www.intercom.com/blog/the-right-way-to-respond-to-fe...

and many more here: https://www.intercom.com/blog/product-and-design/

The first tip - Weighted Shortest Job First/WSJF) is such a great tool. It's easy to get caught up in the middle ground. Sometimes those easy wins get lost in the mix if you're not disciplined about this.

Timeboxing is so powerful, done right.

You can do it all the way down to Pomodoro-like work chunks counted in minutes, up to long term strategic goals and have things like quarterly OKRs and Scrum-like sprints in the middle.

The best entrepreneurs naturally think and act like this, from Elon Musk to the late IKEA-founder Ingvar Kamprad, who is quoted saying:

“You can do so much in 10 minutes time. Ten minutes, once gone, are gone for good. Divide your life into 10-minute units and sacrifice as few of them as possible in meaningless activity.”

sounds like common sense but with fancy tables and diagrams. explains why i never passed initial phone screens for senior PM roles at FAANG even though i developed and launched several succesful hardware products from start to finish into retail, without any PM education or training.