Matt Scott handed his customer a small electronic device and watched him reach over to switch it on.
It didn’t turn on.
Before Matt could apologise, the customer shook his head. “No, no, this is no good at all,” he said. Matt began to explain – it was working when he left the office, something must have – “It’s the wrong size,” the customer interrupted. Not broken. Wrong size. He wanted something bigger to grip with both hands.
Matt drove to the nearest electronics supplier, bought a bigger prototyping enclosure, put the same non-functioning electronics inside, and returned. The customer picked it up, turned it sideways, and said, “Yeah, this is great” – except he held it in landscape, not portrait as designed. And if you’re left-handed, the screen needs to flip too.
Two meetings. Two lessons that reshaped the entire product.
About this week’s contributor
Matt Scott is a futures thinker and innovator whose career spans agritech, the Internet of Things, and energy. After eighteen years as an audio engineer and music producer, he earned an MBA at the University of Canterbury and shifted his path – working on a digital transformation project, launching his own startup, and running an IoT consultancy before becoming Innovation Lead at a state-owned enterprise with 1,800 employees. He contributed to Innovation in Action, featured in the Testing chapter.
A widespread belief in modern teams is that you learn fastest by building an MVP, putting it in front of customers, and iterating from there. While this is typically better than endless planning, it still assumes that learning must start after building something.
Matt’s widget story directly challenges this assumption: you don’t have to build something to discover what actually matters to customers. This lesson is easy to miss, and often costly when ignored at scale.
Let’s dive in,
Your MVP may not fit your customers worldview
The widget wasn’t a bad product. It worked, technically – right up until the moment it needed to work in someone else’s hands, in someone else’s context, holding the way they naturally hold things. Size and orientation weren’t afterthoughts. They were what mattered to the customer, and nobody had thought to question them, because nobody had put the thing in front of the customer until it was already built.
This is the issue: the assumptions that matter most are usually the ones nobody flags as assumptions. They just feel like decisions. You don’t debate whether your customer holds a device portrait or landscape – you build it one way and move on – because this is your worldview. It’s only expensive in hindsight, once the customer’s already telling you it’s wrong.
Scale that up to any project inside a large organisation and the pattern holds. Every week of development spent before real customer contact is a week spent extending a guess, not testing one.
The instinctive fix is to build smaller. Ship an MVP, not a full product. It’s good advice, as far as it goes – but it still assumes the way you find out whether an idea works is by constructing a more complex version of it.
As Matt puts it: “You don’t have to build the thing to find out whether you should build the thing.” An MVP that still requires development time, still needs a team, still has to actually function. You’ve reduced the cost of being wrong, not removed it.
And the cost isn’t only the build time. It’s the false confidence that comes with something that looks finished. A working prototype invites people to judge it as a product, not test it as a question.
Test the assumption, not the product
A client of Matt’s wanted to rent out surfboards near the beach. Rather than build a payment system, a booking app or a vending machine, he parked an old van by the beach with a handwritten sign: want to hire a surfboard? Text me. When people texted, he drove down and handed one over. The next iteration added a hardware-store padlock – text him, transfer the money, get the door code. No app. No automation. Just enough to answer the only question that mattered: will people actually pay for this?
Only once that was proven did the fully automated vending machines get built.
Matt runs his own projects the same way. Every Monday, he asks what’s the biggest risk, what’s keeping him up at night about the project this week. By Friday, he wants an answer – found the cheapest, fastest way possible. Sometimes that’s a five-frame comic strip showing someone using an idea that doesn’t exist yet, just to ask, “what do you think of that?” Sometimes it’s a journey map, sketched out to see whether a customer even recognises the process as their own. “Invest a minimal amount,” he says, “to get the maximum learning.”
None of it requires building the thing.
The DUCTRI framework’s Testing phase was built around exactly this instinct — that higher fidelity is something you iteratively control, not something you default to. The book’s Testing chapter includes the Plan of ATTACK tool for structuring a sprint around your riskiest unknowns, and a fidelity experiment ladder – for choosing the cheapest test that will actually answer your question. If you’re still defaulting to “build a version and see,” these are the tools that get you out of that habit.
You can order Innovation in Action here.
Want to Go Deeper?
If you want to go deeper, the full conversation with Matt is live on my YouTube channel.
Thank you to Matt for sharing the insights, both in this conversation and in his contribution to Innovation in Action.
And if this is a challenge you’re facing in your work, this is exactly what Innovation in Action is designed to help with – from framing the right problem through to implementing solutions that actually land.
Practitioner Insights
Every unquestioned assumption is a guess. The things you don’t think to test can be the ones that feel too obvious to check. Size, orientation, sequence, context. List them before you build, not after someone hands the thing back to you.
Fidelity is a dial, not a starting point. Comic strip, journey map, cardboard mock-up, working prototype – each one answers a different question at a different cost. Before you reach for the next level of fidelity, ask what question you’re actually trying to answer, and whether a cheaper test could answer it just as well.
A question to sit with this week: what’s the thing you’re about to build that you haven’t actually tested yet?
Until next week,
Vaughan