4 ms·
> 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) fe
by __alexs 6y ago
> 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.
- ChrisMarshallNY 6y agoGood 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). [0] https://github.com/RiftValleySoftware/RVS_BlueThoth https://github.com/RiftValleySoftware/RVS_BlueThoth [1] https://apps.apple.com/us/app/blue-van-clef/id1511428132 https://apps.apple.com/us/app/blue-van-clef/id1511428132