Discussion about this post

User's avatar
Samuel Brynolf's avatar

I agree, but I´d like to question the "good"-part. I think we mean the same, but in my opinion it would be more on target to call it "depth of function". Example:

It´s okay that something is delayed = the solution are worked slow, but still has to be good (quality). Burn rate it slower, but probably when the invoices are summed up (when finished finished later) its probably the same expense if the result (good) should be the same.

If "good" --> "depth of function" you end up more with something that works within the diagram. A simpler version is planned, so the scope is restricted (not so complex) and harder prioritized. This should be faster, cheaper but the solution is still with a good quality for what was planned.

If you work as a designer my thoughts might not change that much, this model that I find very helpful (thank you!). But when you use this as a model when explaining to a stakeholder it could be more effective to level out specific functionality instead of using generic terms as "good".

Thank you!

Expand full comment
Gaby Prado's avatar

Glad I came across this post. Learned about it 25 years ago, as a PMI waterfall project manager. Applies to every aspect of design. It should be taught in the magical Design Thinking bootcamps.

Expand full comment
5 more comments...

No posts