When Des asked me to contribute to Inside Intercom, I had just introduced Jobs-to-be-Done to my co-founders at Aim – an advertising marketplace for the real estate industry. Our design process was riddled with ambiguity and lacked consensus. Myself, the CEO, the CTO and the head of design all had suggestions on what to design. But we didn’t have any effective way to support one idea and challenge another. Then it dawned on me. Without making any reference to Jobs-to-be-Done, I began pointing out the most successful suggestions my co-founders had proposed. I explained the struggling moment our customers faced, and described how their life would be better once it was solved. Then I explained how their suggestion was a good fit for this design problem. In effect, I described the customer’s job and what it was like for them when it was done. Using Jobs-to-be-Done language to communicate, we were able to knock out our first design in only a few minutes. We never looked back. • • • Personas and user stories made sense when customers and product teams were far from each other. That’s no longer the case. Traditionally, who the customer was and what they needed fell within the responsibility of mar- keting, business development, or even sales. Once this information was gathered, it would be syn- thesized into a portable format and then pitched over the fence to the product development team. The casualties of this waterfall process are the subtleties essential to creating great products: causality, anxieties, and motivations. Jobs-to-beDone is the philosophy of focusing on these subtleties. And a granular way to bring this concept into a product is to use Job Stories to design features, UI, and UX. 37