Explaining the value of product discovery can, at times, be tricky. Charles Lambdin, an experienced UX consultant, summarises his experience like this.1
They (business stakeholders) wanted to pull up, place their orders, and then focus on the speed of execution. The whole setup required teams to keep the focus on cost and deadlines, ignoring that the “requirements” given were just someone’s ideas—and usually weren’t even good ones. Typically, no user research had been done at all. No time whatsoever had been spent surfacing and vetting assumptions. No work had been done to optimize the problem frame.
He provides a helpful metaphor for the increasing amount of impact that the successive phases of product development offer. This he calls "discovery leverage points".
Instead of focusing on more effective leverage, teams focus on speed. This I think, is appealing as it feels like a less complex challenge. Charles Lambdin reminds his readers that speed is not answer.
.. if you’re making stupid bets, then your goal should not be to make them faster! It should be to make smarter bets.
But what is? He provides a nice, easy to understand framework for the types of questions one should ask and when.
| Question | Research |
|---|---|
| Is the problem worth solving? Is there a need? | User interviews and observation |
| Is there value in these ideas? | Quick prototyping and testing |
| Is this usable? Does it provide a good UX? | Test coded product released in environment |
Teaching UX by Charles Lambdin