3 ms·

The vast majority of invented products - software or not - are complete market failures. No one wants to use them no matter how well engineered they are. When

The vast majority of invented products - software or not - are complete market failures. No one wants to use them no matter how well engineered they are. When we talk about building an MVP (minimum viable product), the V part is very important. It does have to be useful. It does have to look great and work great. It does have to be performant. Edge cases should not get past your QA department. So with those constraints, about the only way you can get out a prototype in a sprint or few is by ruthlessly reducing scope until you get to the core part of your product that is adding value. That process in itself results in far better products. My goal (that I sometimes don't achieve) is that each sprint results in a product we can ship that is better than the last iteration. Run out of budget? Company priorities change? No problem. We still have a useful feature we can ship. Per my previous comment, this is the wrong process for plenty of products. You have to know what you are building and what the risks are, what the constraints are that you are optimizing for, and the pros and cons of different types of processes before deciding which process is the best fit. If you have a strong idea of what you are building ahead of time and you have experience building those types of things and you know there is already a market demand for those types of things, then by all means come up with a solid plan ahead of time and then execute it.

thinkharderdev 6y ago
I agree, but I think the constraints are doing all the work in your statement. I've just been in the position many times in my own career where product managers are pushing to get something, anything out there so they can get "real user feedback" And the V in MVP goes right out the window. I was responding in particular to "a quick prototype in front of real users gives you far better information than any amount of internal brainstorming." Maybe it's just a semantic difference but to me "quick prototype" doesn't imply look great, work great and handle all edge cases. Perhaps you meant quick prototype that looks great, works great and handles all edge cases but I think that implication is often lost on product people. They want something deployed and don't care if all of the engineering team's fussy edge cases are handled.
- tchaffee 6y ago
  > I agree, but I think the constraints are doing all the work in your statement Yep. > I've just been in the position many times in my own career where product managers are pushing to get something, anything out there so they can get "real user feedback" Me too. There are a lot of bad product managers and even companies out there. But I have worked with great ones occasionally, so it's worth describing the ideal so we know what we are aiming for. > I was responding in particular to "a quick prototype... You're right that I need to qualify that because it more often means what you rightly assumed based on your experience. I guess I'm just so in the habit of demanding that we reduce scope that I too easily forget that "quick" more often means the compromise was quality.

thinkharderdev 6y ago

I agree, but I think the constraints are doing all the work in your statement. I've just been in the position many times in my own career where product managers are pushing to get something, anything out there so they can get "real user feedback" And the V in MVP goes right out the window. I was responding in particular to "a quick prototype in front of real users gives you far better information than any amount of internal brainstorming." Maybe it's just a semantic difference but to me "quick prototype" doesn't imply look great, work great and handle all edge cases. Perhaps you meant quick prototype that looks great, works great and handles all edge cases but I think that implication is often lost on product people. They want something deployed and don't care if all of the engineering team's fussy edge cases are handled.

tchaffee 6y ago
> I agree, but I think the constraints are doing all the work in your statement Yep. > I've just been in the position many times in my own career where product managers are pushing to get something, anything out there so they can get "real user feedback" Me too. There are a lot of bad product managers and even companies out there. But I have worked with great ones occasionally, so it's worth describing the ideal so we know what we are aiming for. > I was responding in particular to "a quick prototype... You're right that I need to qualify that because it more often means what you rightly assumed based on your experience. I guess I'm just so in the habit of demanding that we reduce scope that I too easily forget that "quick" more often means the compromise was quality.