4 ms·

This is a common sentiment but I don't think it's actually true. Users like software the works and is performant. Putting a quick prototype in front of users do

This is a common sentiment but I don't think it's actually true. Users like software the works and is performant. Putting a quick prototype in front of users doesn't tell you anything beyond what the users think of the quick prototype. Did they have a bad impression because they ran into one of the many edge cases you didn't account for in the prototype? Or is it because the software is ill-conceived and not something they would like even if executed flawlessly. It's hard to tell. I think you run the risk of putting together a crappy prototype and then iterating your way into a local optimum that is still far inferior to what a properly engineered piece of software could be. Or it never gets that far because users hate the initial iteration because it doesn't work very well.

tchaffee 6y ago
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.

tchaffee 6y ago

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.