The “Three Bucket Model” is something that
I learned by reading Scott Jenson’s excellent The Simplicity Shift[0]. This was a book about mobile UX design, written before the advent of smartphones.
It is all about prioritizing features, as the real estate back then was bad.
I call it “Front of the Box/Back of the Box.”
The Front of a box on the shelf has two or three major eye-catchers, in huge text.
The Back of the box has four or five more, in slightly smaller text, and the sides of the box have the rest of the features, in even smaller type.
This drives my development priorities, as well as UX.
Engineers always want to do the most difficult thing first, just to get a feasibility study done, and the most challenging part out of the way, which makes a lot of sense (engineers tend to be quite sensible and practical).
The problem is, is if the most important feature is easy, it can be left to last, and can be jettisoned, if work on the most difficult (but less important) feature borks the schedule.
So you get a technically marvelous app that does what no one wants.
I’ve done exactly that. Repeatedly (I’m a slow learner). It sucks.
> The problem is, is if the most important feature is easy, it can be left to last, and can be jettisoned, if work on the most difficult (but less important) feature borks the schedule.
This sounds similar to principle of WSJF and Cost of Delay that I learnt from "Principles of Product Development Flow". TL;DR. Ship the easy but valuable stuff first so that your users can get value out of it while you work on the hard things.
The mistake I've seen happen applying this in practice is that you end up cutting all the hard things which leaves you with a product made up entirely of easily copyable stuff and not much differentiation.
Good point. I never plan to skip the difficult parts, and one of the things that I have learned, is to not ship too early, even if it means a delay.
In fact, I am dealing with that right now, on a low-level Bluetooth SDK[0] I’m developing. It works great on iOS (and I even have a shipped app, based on it[1]), but I can’t consider it “shippable,” until I have test harnesses written for the other three systems (I’m just finishing up the Mac one, now).
It is all about prioritizing features, as the real estate back then was bad.
I call it “Front of the Box/Back of the Box.”
The Front of a box on the shelf has two or three major eye-catchers, in huge text.
The Back of the box has four or five more, in slightly smaller text, and the sides of the box have the rest of the features, in even smaller type.
This drives my development priorities, as well as UX.
Engineers always want to do the most difficult thing first, just to get a feasibility study done, and the most challenging part out of the way, which makes a lot of sense (engineers tend to be quite sensible and practical).
The problem is, is if the most important feature is easy, it can be left to last, and can be jettisoned, if work on the most difficult (but less important) feature borks the schedule.
So you get a technically marvelous app that does what no one wants.
I’ve done exactly that. Repeatedly (I’m a slow learner). It sucks.
[0] https://jenson.org/The-Simplicity-Shift.pdf