V1 is usually time based. Get it done by Friday. V2 is often based on bug fixes and feature requests. Lets make it better by adding stuff. V3 tends to be based on experience. Lets remove all the unnecessary stuff and ship what's left.
Comments
Log in with your Bluesky account to leave a comment
Fred Brooks described the Second System Effect in the Mythical Man-Month talking about the v2 problems. To go from a great small system to an over engineered system.
The problem I’ve typically seen with most companies is that they never progress to V3. They just want to keep extending V2, adding more and more as the project slowly dies from accretion.
They ship all desired features in whatever state as v1, but add more features and only fix reported problems, leaving a mess of bugs on little used features.
I've seen this so many times on projects I've worked on. It's a source of frustration and the cause of good people leaving teams when they realise they'll never get to v3.
I love this, and relates to the important shift from project or product model:
“Truly empowered product teams are durable, dedicated, cross-functional teams of missionaries, not mercenaries. They own the product end-to-end and have the stability to go deep and build expertise over time.”
Jax, for example, removed far too much from tensorflow's feature set, leaving its users with a burden to reimplement the missing features, often badly or at great cost
V3 is when you go viral. Everyone wants it in V1, but it ain’t going to happen. VMware TAP was still (a virtual and subjective) V2 when I left. Hoping they get to build V3…
Comments
“Truly empowered product teams are durable, dedicated, cross-functional teams of missionaries, not mercenaries. They own the product end-to-end and have the stability to go deep and build expertise over time.”
Jax, for example, removed far too much from tensorflow's feature set, leaving its users with a burden to reimplement the missing features, often badly or at great cost
Regret based.
Then learning based.