Workarounds are sources of new features
Here's an example of why it's important to be present in the actual environments where users use your product.
Above is a receipt from an order at a quick-serve restaurant. The receipt is placed on a stand with an order number written large to help the server locate the person who placed the order.
(You cannot see this in the photo, but the written order number is the order number generated by the point of sale system with extraneous zeroes removed.)
This is a classic work-around - a user-created way of modifying the use of the product in order to achieve something not explicitly supported by the system. This is also an excellent candidate for a new feature. By redesigning the contents of the receipt so that the wait-staff don't have to
- mentally convert a long order number to a short one
- pick up a pen; write the large number on the receipt; put the pen down
- figure out how to fold the receipt
- strain to read a thin handwritten number from far away with plates in hand
... we can save service workers a set of repetitive and slow actions they would normally be performing tens or hundreds of times a day. The mental and time savings will add up eventually.
And it'll be a nicer experience for the restaurant customers, too. Perhaps something like this.
Of course, it is possible that a user may be able to recount this kind of detail verbally when they are far away from their use environment - but it is difficult (for instance, how well can you describe how you cook a given dish without actually being in the kitchen?). It is far easier to just show up there and document it oneself.
It also produces a empirically-grounded strategy for planning features (in the absence of other data):
- Build enough features to make the product minimally usable and useful
- Deploy, and give your users enough time to learn it
- Go to them and look for work-arounds and "excess" work
- Express that unsupported or excess work as features/jobs to be done/{insert your way of thinking about this}
Designers and product managers: go visit your users. It pays off.