> [JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.]
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
[JO: Yeah, that makes sense. I can see that in the context of a single product. The examples the OP provided made me think of the headlines as being more mercurial and greenfield in scope, but that was an assumption.]
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
[JO: That specific example that came to mind was a GRC system which I worked on years ago. The system was full of bugs, and a large insurance carrier wanted an enhancement. I forget just now what the specific enhancement request was. I do remember though that when I said "no", they said "Ok, then we are not renewing our subscription." I remember it vividly because I was surprised, that was the first time it had happened to me.]
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[JO: Yeah, that can be a problem sometimes.]
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
[JO: Yeah, that makes sense. I can see that in the context of a single product. The examples the OP provided made me think of the headlines as being more mercurial and greenfield in scope, but that was an assumption.]
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
[JO: That specific example that came to mind was a GRC system which I worked on years ago. The system was full of bugs, and a large insurance carrier wanted an enhancement. I forget just now what the specific enhancement request was. I do remember though that when I said "no", they said "Ok, then we are not renewing our subscription." I remember it vividly because I was surprised, that was the first time it had happened to me.]
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[JO: Yeah, that can be a problem sometimes.]
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
[JO: Thanks!]