"While you mentioned this during the demo, I noted: 1. Your state-drop down has only 3 entries. 2. There is a validation error 3. You get an error at the end.
We need you to fix this ASAP !!!"
Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.
Something like https://wiredjs.com/ might work, if you are building a web-ui.
Sucks it has to be this way so often.
Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.
Polished things have a context of "use", not "evaluate", because we use so many polished things every day, but very rarely have any need to evaluate them (mostly only when we're buying them, or when a repair person asks us to describe what's wrong with them.) Whereas unpolished things are mostly "for" evaluating; it's rare that people use unpolished things (outside of, say, disaster-relief infrastructure.)
Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.
it's not a way of gaming the system, but a way of prompting better feedback. For instance, in a Design Thinking process prototypes are more useful when they look rough/unfinished. A more polished piece of work might result in people being afraid to break things.
I use both approaches in my work:
1) demo small, tested bits during show and tells and any meetings where the point is to demonstrate progress. 2) demo large, unfinished and barely stable pieces of work when ideating, trying to figure out the next steps
2) is hard and works only if: - we know what the unstable parts are (because we have tests, so we know the gaps) - we know the audience and how much context they have
The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.
I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting.
For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page.
It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.