Simple product management tricks

https://jacobian.org/2021/oct/20/simple-pm-tricks/

244 35 5 years ago

kqr• 5 years ago

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.

xorcist• 5 years ago

Automation is such a useless word. It can mean "no human in the loop" but is can also mean "human pushes this button and machine works" and also "all I have to do is frobnicate the urbanizer, input the result, doublecheck the nitifier, push the button, and then the machine does the rest!".

The Toyota quote is clearly skewed towards industrial production, where the word is a little more useful though. But other times, a simple process without human involvement might very well be the cheapest and easiest to start with too.

bschne• 5 years ago

Granted, this was also in the context of mechanical engineering and manufacturing (cf. remarks in sibling comment), but Elon Musk has talked about his engineering philosophy in five steps in a starbase tour/interview video:

1. Make the requirements less dumb 2. Try deleting the part or process 3. Simplify and optimize the design 4. Accelerate cycle time 5. Only then: Automate

I think this touches upon the same issues, namely that you shouldn't automate something if you don't have to, and even less if you don't need it in the first place.

toss1• 5 years ago

I also recently read Elon strongly criticizing/advising another company to 'get their factory [processes] working before building the big factory', which is the exact opposite of what said company was doing...

Seems like Elon is correctly advising those guys to avoid a lot of pain (while not-so-subtly pointing out to everyone the big mistake being made).

When being hired to automate a business process, I always tried to get/work with the client to explicitly streamline the paper/people version of the process first, and when they did a good job of it, the automation went well. I'd tell them that automating a mess just made a turbocharged mess, and merely guessing at what changes (implemented in automation) would be better was a crapshoot. If anything, I'd recommend making that approach a stronger requirement for taking on jobs.

a-priori• 5 years ago

Yes, I recently planned out how to transition a company to a continuous delivery release model, and this was part of the plan.

One thing I insisted on was on building and running playbooks, rather than jumping to full automation from merge to production. This phase was temporary: it might only take a few weeks or months before people will get bored with this and find it tedious. When _boredom_ is the biggest problem you have with a process, then it's time to automate.

But in the meantime, going through these motions manually has educational value, and lets you refine your processes easily.

Automating a process tends to ossify it, and concentrate knowledge about it in whoever creates and maintains the automation. Playbooks distribute knowledge to whoever executes them, and make systems amenable to change.

rrrrrrrrrrrryan• 5 years ago

I read that the Airbnb founders tried to instill an ethos in the early days of "do everything by hand until it's painful," because they were scaling so fast and they wanted to avoid nailing down a process too early.

tylerrobinson2• 5 years ago

Completely agreed on all points. It can be all too easy to say, we need to build a widget factory so we can automatically create 100 widgets for our customers. It'll be so efficient! But once you start building the factory, you realize that you'd probably have reached your goal faster by making them manually and only coming back later to find out what was common between them. Start small.

metanonsense• 5 years ago

In my experience, this is also good advice when thinking about distributed systems. If an algorithm doesn't make sense when imagined with people in an office, it usually also doesn't work in a computer.

erikstarck• 5 years ago

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.”

loremipsium• 5 years ago

Divide your life into 10-minute units and sacrifice as few of them as possible in meaningless activity.

Sounds like hell. I am not a robot. And how am I going to do it. Take an hour before work to plan 48 10 Minute sessions for the day. What if something important comes up? Or take a 1 minute block every 10 minutes to figure out what to do for the next session? God forbid I have to take a call, take a p*ss, or my noodle pot boils over while I wfh.

derekjdanserl• 5 years ago

With smart planning, you could clean up the noodle bowl and take a piss in the same 10 minute chunk. And with enough practice you could have a few minutes to spare for something important to come up.

jon-wood2• 5 years ago

I agree that scheduling your entire life in 10-minute units with no space left for just living sounds somewhat hellish, but I like the core concept of being conscious about what I'm doing with my time. I would look at it more as not just defaulting into meaningless activity, but making a conscious decision that it's what you want to be doing for a while.

samsolomon• 5 years ago

I don’t think this is meant to be taken literally.

The point is to use your working time productively. Figure out the most important thing you can be working on, time box it, then reassess.

That process has served me well for the last 10 years.

techbio2• 5 years ago

Whoops, I just continued reading into an emotional strawman argument derogating a transnational CEO's time management strategy.

Not going to do that for the next eight minutes, I'm too busy dividing the rest of my life into annotated 100ms segments so I can get some real work done.

onion2k• 5 years ago

It's ironic that Ingvar Kamprad said that and then optimized IKEA stores for spending as much time walking round looking at everything before you get to the shop bit as possible.

Maybe he should have added "... and don't let anyone else steal your time units from you." at the end.

mook• 5 years ago

Interesting; at my local IKEA, the warehouse bit is on the ground floor, and while the normal path is through all the showrooms, there's a shortcut right by the entrance straight to the warehouse. Additionally, there's various shortcuts throughout their showrooms. I wonder if that wasn't in all their stores?

trabant00• 5 years ago

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.

pydry2• 5 years ago

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.

Zababa• 5 years ago

On the other hand, in my team we have playbooks and they're great. One thing that helps is to consider them as living documents (we have a tool with history and comments that helps, Quip), use them every time you do the task instead of relying on memory, and put a comment every time you encounter a problem so that the playbook can be improved.

To give a bit of context, this is for tasks usually done once a week to once a month individually, multiple times a week for the whole team.

simonbarker87• 5 years ago

This feels like the

“Documentation just goes out of date so don’t bother argument”

Documentation (which is what a playbook is) isn’t milk, it doesn’t just “go out of date”.

People let it go out of date by not keeping it up to date. Docs going out of date isn’t the problem, the problem lies in the system that causes it to go out of date.

The only reason automation doesn’t go out of date is because it breaks and so you have to fix it, the problem is that each of those little fixes takes time, probably more time that updating the docs.

Automation is great but to approach it as a binary choice is wrong.

pydry2• 5 years ago

I was saying that the benefits of automating are often misaccounted for.

In the examples above a 5 minute manual task run once a week, for instance, wasnt just a cost of 5 mins x 1 week.

Automating potentially saved debugging time, time spent analyzing why the playbook went wrong, etc.

Those benefits wouldnt typically be measured but theyre very real.

tedmcory77• 5 years ago

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.

aj7• 5 years ago

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.

aero142• 5 years ago

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.

abap_rocky• 5 years ago

Yep, I remember that post as well. Was described as "Do-nothing scripting" and I've applied the concept as well.

Original Article: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...

HN Discussion: https://news.ycombinator.com/item?id=20495739

b200002• 5 years ago

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.

mindtricks• 5 years ago

In all fairness, the author is not a product manager by title or training. He's only sharing "product management" tricks or techniques that's helped him during his own development. If you've done these things for a while, may not be much to take away here, but for junior PMs or junior engineers, this is probably enough to shift their thinking a bit.

b200002• 5 years ago

i see. i had a conversation about a director of PM role and the guy i talked to seemed perplexed i was not going to go through the PM ladder step by step starting at the bottom. certainly not after 25 years of experience of building and shipping.

simonswords82• 5 years ago

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/

joekrill• 5 years ago

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.

tylerrobinson2• 5 years ago

This is where trust between Product and Engineering is critical. Engineering must be given some "out of band" capacity as you put it, which is locked down and kept available for Engineering to perform maintenance _as they see fit_.

But that's really hard to maintain in most orgs.

For engineering teams with an embedded Product Owner, this is where a good PO can really shine. Show, don't tell, the value of all your maintenance work. Yes, it's hard to show to a nontechnical audience, and yes, it's supposed to be a "safe zone" for engineers to have discretion. But you will lose your maintenance capacity if you don't show nontechnical people the value they're getting out of it.

Business leaders understand productivity trends, feature cost, time to deliver, support ticket counts, and aesthetic improvements. Use this to your advantage to communicate in the language they understand, and keep your maintenance capacity.

Simple product management tricks

Related Stories