> I wish people would stop bringing up the Pareto principle. "Some things are consistently bigger than other things." Can we talk about why things are bigger than other things instead of saying it's because of some law of nature?
I see what you're saying, but it sounds like you haven't really internalized the principle.. because you're viewing it as a tautology rather than the useful heuristic it is. You can and should still have the probing discussions. But having 80/20 as a rule of thumb will actually help you know where to probe. So you might want to give it another look.
> I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated.
There's so much to say about this topic.. it's hard to give many pointed tips. But my advice would be to 1) read far and wide about product management (blog posts like this one, books, research, etc), and especially focus on first principles. 2) Experiment with your team! and 3) *Do not* think that doing one of those weekend certification courses or seminars or whatever is going to help much. Points 1 and 2 will give you far far more insight.
Re: pareto principle, I've never actually looked at what the principle means. "80% of the consequences come from 20% of the causes" is quite useful, as I understand it it means "don't assume that causes of consequences are randomly distributed".
I think I see it often misunderstood the way I misunderstood (/misunderstand?) it: "As with most things, there is the 80/20 rule (Pareto again), exceptions are sometimes warranted in important situations." this sentence just says "you should stick to the rule about 80% of the time"
Re: advice, thanks for taking the time! I hadn't considered research, but luckily I already agree with 3) :P
Thanks for the reply and the thoughts. Interesting to hear that you're having a similarly hard time finding answers.
I've come across these concepts of "sagas" and "process managers" that sound maybe like what I'm trying to do. But it seems to me like all it might need to be is a background process that issues commands.
There are tools for process maps that can execute code at specific steps based on criteria. I spent several years working with IBM Filenet process maps. There are other, similar tools. You can also build a rules engine in a DB with a either a background process checking those conditions or potentially triggers tied to the data (depending on the DB).
There certainly are answers to be had. I just believe that in this corporate world, people understand that it's best for their career to call what they work on by some fancy new name so they can look good and make more money.
I see what you're saying, but it sounds like you haven't really internalized the principle.. because you're viewing it as a tautology rather than the useful heuristic it is. You can and should still have the probing discussions. But having 80/20 as a rule of thumb will actually help you know where to probe. So you might want to give it another look.
> I am naturally a quite chaotic person, I have trouble helping other people create order when I'm already having trouble keeping an eye on all the streams that exist in the team. Any tips would be appreciated.
There's so much to say about this topic.. it's hard to give many pointed tips. But my advice would be to 1) read far and wide about product management (blog posts like this one, books, research, etc), and especially focus on first principles. 2) Experiment with your team! and 3) *Do not* think that doing one of those weekend certification courses or seminars or whatever is going to help much. Points 1 and 2 will give you far far more insight.