Yes.
My take on this is that we're building a prototype to be able to provide users something tangible to get feedback on. Maybe even a proto-prototype to explore internally with the team.
"Right Features" is a bit nebulous. It's "Build the features that need clarification as a prototype".
Let's see what I think about what the book says...
"build only features that are poorly understood" - Yep. Based on principle 11; I was pretty sure I'd be in agreement with the books take on this one too.
It highlights this is for a "throw away prototype", not evolutionary. An Evolutionary Prototype is just building the product itteratively. WHICH IS WHAT WE SHOULD DO!!!!
My use of prototype IS throwaway.
There's a lot of emphasis of not building throw aways for features understood well. I disagree. It depends on what the focus of the prototype is. We can understand the functionality perfectly well; but not the best UI.
The UI is not well understood - build a prototype to explore that. It could even be on top of non-prototype functionality. Or all hardcoded - either way... A well understood feature can have poorly understood components that prototypes would be valuable for.
I guess my earlier phrasing isn't good - "Build prototypes to learn something". It's really vague, but that's the goal. We'll spend little time to get feedback which can be quickly incorporated.
Quickly incorporate feedback. That's our goal in software - It's how we build products customers find useful.
Not a lot here. The idea is solid, just some different emphasis.