Simple product management tricks(jacobian.org)
jacobian.org
Simple product management tricks
https://jacobian.org/2021/oct/20/simple-pm-tricks/
35 comments
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Original Article: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...
HN Discussion: https://news.ycombinator.com/item?id=20495739
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.
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.
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.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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/
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.”
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.”
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.
Maybe he should have added "... and don't let anyone else steal your time units from you." at the end.
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?
All the warehouse should have these shortcuts due to fire hazards and emergency policies.
> 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.
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.
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.
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.
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.
I'll now make the conscious decision to stop posting on Hacker News and go do something useful!
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.
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.
I don't think there's any reason to assume that a "transnational CEO", whatever that means, is any worse or better at time management than other people.
And if they are, there's no reason to assume that their "strategy" will work for others. A lot of CEOs are workaholics. What works for them won't help a healthy human.
And if they are, there's no reason to assume that their "strategy" will work for others. A lot of CEOs are workaholics. What works for them won't help a healthy human.
It means that becoming the CEO of a transnational corporation is a pretty strong filter for effectiveness, and the comment I replied to is probably not in the spirit of their advice.
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.
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.
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.
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.
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.