CAN you make coleslaw with a gasoline-powered lawnmower? Of course you CAN. But SHOULD you?

This post is not about being afraid to do risky things or to break expectations. It’s about understanding who you are innovating for; your target audience.

If I am inventing a new way to make coleslaw, I’m not going to sell you a lawnmower… because it doesn’t mesh with your jobs to be done. The “coleslaw crowd” most likely wants something that shreds cabbage in a snap, requiring minimal storage space, and clean up should be a breeze. The mower ticks one of the boxes, but it fails on the other two. It also introduces new pain points, such as monitoring gas levels and the eventual spray-back of finely shredded cabbage on your kitchen walls.

While it CAN do the job, it SHOULD not do the job.

We see this too often when a tool or solution exists, typically crafted for a different problem or audience. “Wow! This thing is neat. CAN I also use it for this?”

“Wow! This mower cuts through yard foliage fast. CAN I also use it in the kitchen?”

CAN should be an innovator’s stop word. When a customer says “CAN it also do this?”, you should dive deep into why they even want to solve that problem this way. Think to yourself “How SHOULD we design a solution to this problem?” Sample questions to respond (out loud) to a CAN include:

1. What is it about Solution X, that interests you in solving Problem Y?
2. Why is Problem Y a problem?
   1. How does it make you feel?
   2. Where are you when you encounter Problem Y?
3. How do you currently solve Problem Y?
   1. What don’t you like about your solution?
   2. What do you like about your solution?
   3. What do you wish your solution also had?

We should be designing solutions that customers SHOULD be enjoying, not simply delivering solutions that CAN kind-of work. CANs are tempting because the customer is happy that a solution is at hand. But it is an imperfect fit and will ultimately fail. SHOULDs take longer because they require customer empathy, build-measure-learn loops, and hypothesis testing. But SHOULDs perform better than CANs in user experience and long term feasibility.

Be brave and courageous enough to steer your customer away from the siren call of the CAN.

Design the SHOULD.