in Industrial Engineering, Invision, Pareto, Product Management, UX design

Pareto in Product

I first learned about Pareto’s Principle in my Industrial Engineering class — not sure which one.

I’ve since seen it used in many different contexts and analogies as a basis for this and that. To be honest, I cannot remember one where it’s been used accurately or at a depth where I thought it really proves the point.

My example belongs to one of those.

I was trying to explain to someone the other day about how the work effort that comes with designing something for a digital product is easy at first. You get general requirements, get user feedback, get some stakeholder input and presto — you have the all the ingredients for the product. You put some mockups together, some low-fidelity wireframes and you progressly get higher and higher in fidelity. You present it in meetings, on the side-of-desk, you share it on Invision, Zeplin or whatever is in these days.

There inevitably hits at point that you realize the wireframes are missing X, Y and Z. And then upon rethinking about it, you realize you also missed A, B and C. It’s not oversight so much as … I don’t know what really.

Intuitively and over years of experience bring products to life, you realize after some time that that last 20% of work is about 80% of the effort. I’m not sure if that’s in line with Pareto’s Principle but I’ve found this to always be true. As the thing gets closer and closer to reality, more and more questions bubble up of the woodwork. And the more and more questions come up, the more the more questions come up from that.

I’ve known no good way to go about it than to just say, these things we missed or things we realized was a lot more effort than we originally thought, we should move it to the product backlog.

But suffice to say, I didn’t really learn about Pareto’s Principle until I experienced it over and over again in real life.

Write your "think"

Comment