The fastest teams don’t ship more—they learn faster. They validate features before code is written. And they know something many teams still forget: Code is a liability!
1. The development used to be slow and expensive. It's becoming increasingly faster and cheaper. And will become better at that still.
I would thus, be far from basing the argument on that.
Having said that, it doesn't invalidate it! Drucker's "There is nothing so useless as doing efficiently that which should not be done at all" applies here perfectly.
However, we do indeed have one new option for validation. We can consider early prototyping, proofs of concept, etc., as *one of the available ways* of doing that. Then remembering, of course, about all the technical caveats of such code and addressing them properly.
2. I don't share your sentiment against Shape Up. I didn't pick that focus on coupling validation with delivery when I went through it.
Granted, one may infer it, but I think it would be the outcome of looking at Shape Up through own lenses. And the conclusions may have more to do with the lenses than with the method.
It's by no means the defense of Shape Up of any sort, by the way. I see it largely as if Scrum was rewritten by product engineers. It surely makes some things easier for one interested party (the engineers), but I'd question whether it translates well to a broader context.
Anyway, as much in Shape Up as in Scrum, there isn't really any focus on discovery/validation/exploration. And I don't blame either for that.
ShapeUp's own creators use it as a way to "just do it from beginning to the end", this implies no market validation, or only minor details.
I wouldn't say ShapeUp is similar to Scrum, I'd say it adds some interesting concepts (appetite), which help us deliberately talk about how much we want to invest. That's a good move in my opinion.
I also agree with you that Scrum does not explicitly mention market validation. This is only one of the many aspects that are not explicitly mentioned. I don't think that's a problem. But I do think many people will take it as a a problem. Especially where they expect a prescriptive method.
Ah yes, of course it's "from the beginning to the end." However, it's always in the context. What is their context? What's their beginning and their end?
It's largely engineering. Yes, they built a successful product, but the leaders, the faces of the company are engineers at hearts.
And it's pretty clear if you consider the ShapeUp details.
That's why I didn't expect any focus on discovery/validation of ShapeUp. Subsequently, I wasn't disappointed when I didn't get it :)
It's not that I praise ShapeUp (I don't). I just don't consider they promised to touch a broader process.
BTW: I prefer Annie Duke's bets as a more useful metaphor than appetites. It also precedes ShapeUp and addresses at least a part of validation.
I think the two vantage points, bets and options/commitments, are supplementary.
Anyway, I'd say some bets are all or nothing. A lot depends on the context.
Some decisions lend themselves to choosing a point on a scale. Think layoffs. It's a trade-off between short-term cost savings and long-term reboundability. The more people you let go, the more costly the capability rebuilding later. On the other hand, sustaining all the future capabilities incurs costs here and now. So, an organization decides *how far* they want to go with the layoffs (a point on a scale decision).
Conversely, a startup making a pivot is a binary decision. The strategy so far didn't work out well enough, and it's either double down on the old plan or a rapid turn into a new one. There isn't enough runway to keep both options open. Or rather, each of the options requires full focus in order to make it work. It's an either-or choice.
Both types of decisions are bets.
BTW: circling back to our ShapeUp exchange--it doesn't get even remotely close to such considerations, even in the product context. It kinda follows an unspoken assumption that a product has already been established, and it's more of an ongoing effort by now. What follows, the main goal is sustaining the momentum, rather than validating it altogether. Which, incidentally enough, is precisely the Basecamp case (what a surprise!) :)
I heard about "bets" in software environment in 2011 when joined Nokia. But back then, they were not talking about "Bets" (the term that Annie uses) as a concept to envelop decisions. They were just calling "bets" something BIG we want to do, and don't want to treat is as a bet (using probabilities, future discounted value vs. other metrics, etc.)
I'm thinking of "Bets" as in investment. We look at company's PE and "bet" it will go up by x% over the next y years.
We can use this as a metaphor for (product) portfolio decisions (projects are so dead... another discussion), and then use signals from the market, and our own work (execution/validation) to value that bet (like when we look at the PE multiplier in a company's evaluation).
If you have written more about options/bets, let me know.
In principle, I'm with you on this.
A couple of a comments on details, though.
1. The development used to be slow and expensive. It's becoming increasingly faster and cheaper. And will become better at that still.
I would thus, be far from basing the argument on that.
Having said that, it doesn't invalidate it! Drucker's "There is nothing so useless as doing efficiently that which should not be done at all" applies here perfectly.
However, we do indeed have one new option for validation. We can consider early prototyping, proofs of concept, etc., as *one of the available ways* of doing that. Then remembering, of course, about all the technical caveats of such code and addressing them properly.
2. I don't share your sentiment against Shape Up. I didn't pick that focus on coupling validation with delivery when I went through it.
Granted, one may infer it, but I think it would be the outcome of looking at Shape Up through own lenses. And the conclusions may have more to do with the lenses than with the method.
It's by no means the defense of Shape Up of any sort, by the way. I see it largely as if Scrum was rewritten by product engineers. It surely makes some things easier for one interested party (the engineers), but I'd question whether it translates well to a broader context.
Anyway, as much in Shape Up as in Scrum, there isn't really any focus on discovery/validation/exploration. And I don't blame either for that.
ShapeUp's own creators use it as a way to "just do it from beginning to the end", this implies no market validation, or only minor details.
I wouldn't say ShapeUp is similar to Scrum, I'd say it adds some interesting concepts (appetite), which help us deliberately talk about how much we want to invest. That's a good move in my opinion.
I also agree with you that Scrum does not explicitly mention market validation. This is only one of the many aspects that are not explicitly mentioned. I don't think that's a problem. But I do think many people will take it as a a problem. Especially where they expect a prescriptive method.
Ah yes, of course it's "from the beginning to the end." However, it's always in the context. What is their context? What's their beginning and their end?
It's largely engineering. Yes, they built a successful product, but the leaders, the faces of the company are engineers at hearts.
And it's pretty clear if you consider the ShapeUp details.
That's why I didn't expect any focus on discovery/validation of ShapeUp. Subsequently, I wasn't disappointed when I didn't get it :)
It's not that I praise ShapeUp (I don't). I just don't consider they promised to touch a broader process.
BTW: I prefer Annie Duke's bets as a more useful metaphor than appetites. It also precedes ShapeUp and addresses at least a part of validation.
I'm with you on Annie's work. Have been talking about that at portfolio level:
- what are bets
- how to quantify bets
- how to measure bets over time (investment metaphor - bets are never all or nothing in our domain).
How about you? Have you written about how you apply Annie's ideas?
The frame of portfolio decisions as bets is sooo neat.
I think I first heard about that frame from Jim Benson in 2015? 2016? Anyway, it was before Annie Duke's book.
Before that, I mainly used the frame of options/commitments at the portfolio level and how that affects the finer-grained decisions (project level, feature level): https://brodzinski.com/2013/09/options-options-options.html
I think the two vantage points, bets and options/commitments, are supplementary.
Anyway, I'd say some bets are all or nothing. A lot depends on the context.
Some decisions lend themselves to choosing a point on a scale. Think layoffs. It's a trade-off between short-term cost savings and long-term reboundability. The more people you let go, the more costly the capability rebuilding later. On the other hand, sustaining all the future capabilities incurs costs here and now. So, an organization decides *how far* they want to go with the layoffs (a point on a scale decision).
Conversely, a startup making a pivot is a binary decision. The strategy so far didn't work out well enough, and it's either double down on the old plan or a rapid turn into a new one. There isn't enough runway to keep both options open. Or rather, each of the options requires full focus in order to make it work. It's an either-or choice.
Both types of decisions are bets.
BTW: circling back to our ShapeUp exchange--it doesn't get even remotely close to such considerations, even in the product context. It kinda follows an unspoken assumption that a product has already been established, and it's more of an ongoing effort by now. What follows, the main goal is sustaining the momentum, rather than validating it altogether. Which, incidentally enough, is precisely the Basecamp case (what a surprise!) :)
I'll read your options article.
I heard about "bets" in software environment in 2011 when joined Nokia. But back then, they were not talking about "Bets" (the term that Annie uses) as a concept to envelop decisions. They were just calling "bets" something BIG we want to do, and don't want to treat is as a bet (using probabilities, future discounted value vs. other metrics, etc.)
I'm thinking of "Bets" as in investment. We look at company's PE and "bet" it will go up by x% over the next y years.
We can use this as a metaphor for (product) portfolio decisions (projects are so dead... another discussion), and then use signals from the market, and our own work (execution/validation) to value that bet (like when we look at the PE multiplier in a company's evaluation).
If you have written more about options/bets, let me know.