Stop Validating and Start Co-Creating
producttalk.org
Stop Validating and Start Co-Creating
1–10 of 10 posts
Re: Stop Validating and Start Co-Creating
#2Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something.
Pretty good advice for any creative engineering discipline.
The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define what makes someone good at this- though it’s incredibly important for product success.
Software design is still a very creative endeavor and probably always will be.
Re: Stop Validating and Start Co-Creating
#3[deleted]
Re: Stop Validating and Start Co-Creating
#4Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something. Pretty good advice for any creative engineering discipline. The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define wha…
Good advice. I'm all for getting a quick MVP version out and then iterate.
But, I also think why Apple did not do it with iPhone? They could have just built a device with phone only capabilities. Leaving aside that, they rebuilt\redesigned a ready-to-market iPhone (first version)
Re: Stop Validating and Start Co-Creating
#5Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something. Pretty good advice for any creative engineering discipline. The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define wha…
Good advice. I'm all for getting a quick MVP version out and then iterate. But, I also think why Apple did not do it with iPhone? They could have just built a device with phone only capabilities. Leaving aside that, they rebuilt\redesigned a ready-to-market iPhone (first version)
Go to market strategy is different for established company like Apple and small startups. Apple can afford later entry into the market, can afford to acquire innovations, product teams and spend more time on research. Also if you fail - you standup and do it again, if company like Apple fails - stock goes down and many people can get hurt — different dynamics.
Re: Stop Validating and Start Co-Creating
#6Earlier quoted context omitted.
Good advice. I'm all for getting a quick MVP version out and then iterate. But, I also think why Apple did not do it with iPhone? They could have just built a device with phone only capabilities. Leaving aside that, they rebuilt\redesigned a ready-to-market iPhone (first version)
Go to market strategy is different for established company like Apple and small startups. Apple can afford later entry into the market, can afford to acquire innovations, product teams and spend more time on research. Also if you fail - you standup and do it again, if company like Apple fails - stock goes down and many people can get hurt — different dynamics.
also, don't underestimate how much market research and focus group testing is involved. There's lots of customer feedback going on with "traditional" design, it's just done privately not publicly.
It's also not as good feedback - it's too easy to tell the focus group what to think. But done right, it can lead to the same place.
Re: Stop Validating and Start Co-Creating
#7Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something. Pretty good advice for any creative engineering discipline. The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define wha…
Good advice. I'm all for getting a quick MVP version out and then iterate. But, I also think why Apple did not do it with iPhone? They could have just built a device with phone only capabilities. Leaving aside that, they rebuilt\redesigned a ready-to-market iPhone (first version)
When the Motorola Rokr came out circa 2005, it was basically "just a phone" except for the iTunes features, and at the time, as far as I knew, it was "the" much anticipated Apple phone. Now, with hindsight, it's become obscure.
See: https://en.wikipedia.org/wiki/Motorola_Rokr http://www.ubergizmo.com/2005/09/official-apple-motorola-and...
Re: Stop Validating and Start Co-Creating
#8Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something. Pretty good advice for any creative engineering discipline. The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define wha…
Good advice. I'm all for getting a quick MVP version out and then iterate. But, I also think why Apple did not do it with iPhone? They could have just built a device with phone only capabilities. Leaving aside that, they rebuilt\redesigned a ready-to-market iPhone (first version)
I'm not sure I agree with your terminology. Many engineers and startups confuse MVP (minimum viable product) with prototype or something to that effect. If a new product you've put out isn't viable, as in selling well enough that it sustains your business or will do so in the foreseeable future, it is - by definition - not an MVP; it's just a prototype.
iPhone was an MVP by any reasonable definition IMO. It was a 2G device and the build quality was meh if memory serves me well, it was slow, it lacked memory, the camera was trash, it didn't support 3rd party apps, it was expensive, it only worked on AT&T, etc. But it took off regardless because it was good enough.
Re: Stop Validating and Start Co-Creating
#9Summary: don’t let the perfect be the enemy of the good. And don’t overoptimize before you build something. Pretty good advice for any creative engineering discipline. The hard part is always defining “overengineered”. Is 1 day of design work enough? Is 2 weeks too much? Good taste and experience rule here, and the best engineers make the right decisions, leading to great products. Problem is, it’s hard to define wha…
I don’t think that’s a good summary of the article.
Rather, the article is saying: you don’t even know what is good yet, so stop wasting time trying to perfect what you are likely to need to replace anyway.
Re: Stop Validating and Start Co-Creating
#10soo basically, backtracking and refactoring after having started small. Sounds nice, also sounds like something my network infra colleagues completely fucking hate.