Note: I slipped in a weekend post on Product Team / Enabling Team Collaboration. Back to my Thursday cadence… A real estate investor constructs a rental property and skimps on quality. Every time the contractor asks the investor, "do you want to do X, which will cost more but will last longer, or Y, which is cheaper and will not last as long" the investor says Y. Unless, of course, the contractor says "X is more expensive, but in the long run it will save you money," in which case the investor says, X.
Feb 24, 2023·edited Feb 24, 2023Liked by John Cutler
I'd add "Quality is value to some person (who matters) at some point in time" as the nature of quality changes over time. For example, look at what quality means for a startup versus twenty years later when that startup is an enterprise.
When I think of that sentence I think of 3 possible *who's* : product, delivery and operations. All see quality in a slightly different perspective.
1) Product : Quality is building the right product
2) Delivery: Quality is building the product right
3) Ops : Quality is supporting the product well
So when Rob talks in point 2 talks to long-view and patience, is he talking to 1, or 2 or 3 or all of the above?
Because for point 1 I can understand. For point 2 less so. Is that translatable into: "Its ok to ship and then fix bugs in production"?
I personally advocate the speed is a quality attribute of delivery, but build speed by doing things well the first time, so that includes testing into mvps.
There's one proviso on this. If you're a startup, there's a case to justify quick and dirty experiments with little testing (as long as the risk is low).
Have I misunderstood the post? Love to hear your thoughts
The "controlled chaos" description resonates so much with some experiences of management I've had. Things sort of work but no one really knows why or how.
Great points. In my experience another thing that makes this hard is the “good enough” bar varies so much depending on context so it’s hard to define and apply a consistent standard, making execs that much more reliant on the judgment of team leaders. Maybe that’s where culture + hiring great ppl is extra important...
I'd add "Quality is value to some person (who matters) at some point in time" as the nature of quality changes over time. For example, look at what quality means for a startup versus twenty years later when that startup is an enterprise.
When I think of that sentence I think of 3 possible *who's* : product, delivery and operations. All see quality in a slightly different perspective.
1) Product : Quality is building the right product
2) Delivery: Quality is building the product right
3) Ops : Quality is supporting the product well
So when Rob talks in point 2 talks to long-view and patience, is he talking to 1, or 2 or 3 or all of the above?
Because for point 1 I can understand. For point 2 less so. Is that translatable into: "Its ok to ship and then fix bugs in production"?
I personally advocate the speed is a quality attribute of delivery, but build speed by doing things well the first time, so that includes testing into mvps.
There's one proviso on this. If you're a startup, there's a case to justify quick and dirty experiments with little testing (as long as the risk is low).
Have I misunderstood the post? Love to hear your thoughts
This Is a fantastic quote. "To me, quality is being able to ship and iterate on an item later."
Encapsulates so much in so little.
The "controlled chaos" description resonates so much with some experiences of management I've had. Things sort of work but no one really knows why or how.
Great points. In my experience another thing that makes this hard is the “good enough” bar varies so much depending on context so it’s hard to define and apply a consistent standard, making execs that much more reliant on the judgment of team leaders. Maybe that’s where culture + hiring great ppl is extra important...