In doing some reading this morning, came across a couple examples of practitioners with a customer-centric orientation emphasizing the job-to-be-done. They come at it from different angles, but share the essence *first* understanding what the customer is trying to get done first, *then* getting down to design and development.
I need to relate the problem to a situation in order to understand it. The reason I am making a product is to give people capability they lack. That’s why they pay for it. The gap between the person’s current situation and the situation they want to be in defines value for them. They hire your product to do a job. The job is their definition of progress from here to there.
When the job isn’t well-defined, the team doesn’t know what to include and what to omit. They design based on logical speculations, not real situations. Instead of targeting a problem like a sniper, they cast a net and hope to catch the value somewhere within its expanse. Casting a net means building more functionality in more places, so the project grows in scope and complexity.
Sometimes people think they have defined the problem, but they really just defined a feature. Like “users want file versioning.” It’s important to understand that a feature is not a situation. You can dig into a situation to learn what is valuable and what is not according to the goal. Digging into a feature definition doesn’t do that. It has no origin and no goal. Analyzing a feature definition leads you to play out all the things a person might value from the feature instead of learning what they actually value.
Michael B. Fishbein on SinglePlatform founder Wiley Cerilli:
Wiley began hearing complaints from restaurants about how hard it was to manage their web presence and all the sites they have information on. He wasn’t sure what the exact solution was, but knew that the problem presented an opportunity.
Instead of building something and seeing if restaurants would want it, he start by getting feedback from customers and pre-selling.
Wiley began by going in to restaurants with a PowerPoint deck on an iPad describing a product that he thought they would want. In our conversation, he emphasized the importance of not simply asking “would you buy this” when delivering customer development interviews because people will generally feel uncomfortable saying no. Instead he described it to customers as his friend’s product or would ask them to write a check if they said they liked it. When you ask someone to pay for something you start hearing information that you would not have heard otherwise because people would rather not be disagreeable.
Over a three month period of delivering customer development interviews, a lot of “no-s,” and several iterations of the deck, Wiley came to 5 slides that resonated strongly. In fact, many were willing to write him a check, even knowing that he didn’t know have a product built yet. He had identified a strong enough customer pain point and a product value proposition that resonated strongly enough, that customers were willing to prepay. Wiley knew he had a real opportunity on his hands at that point and began building the product and brought on a couple sales people to distribute it.
The emphasis on validating customer needs and avoiding spending time and money on something that customers don’t actually want didn’t stop after the product was built. SinglePlatform would consistently test, pre-sell, and run customer development interviews on new features.
Image via flickr
Original Post: http://bhc3.com/2013/08/13/two-cases-of-job-to-be-done-driven-design/
