The secret to making people buy your product
There is no greater waste than building something extremely efficient, well architectured (is that a word?), with high quality that nobody wants.
Yet we see it all the time. We have the Agile manifesto and Scrum probably to thank for that (the seeing bit.) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. It’s the valuable bit that is embodied by the Product Owner in Scrum, or “the value maximiser”.
Lean Startup has taught us that we suffer from cognitive bias and simply assume we know what customers want, and therefor should treat our requirements as assumptions. Get out of the building and ask our customers! We all know that Henry Ford would disagree. But could both be right.
Why people buy your product
Sorry, it’s not your design, functionality or even the price (though these contribute) It’s because it solves a problem. That’s it, a product is nothing more that a painkiller for something that hurts. If the pain stops or there is a significant better solution (switching cost), so will the usage of your product.
The expression is: “he/she chose with his/her heart”, but we choose with our brains, funny enough: we have three of them that work in different ways! A simplified model would be:
- The reptilian brain, related to our basic survival and biological need
- The limbic system, guides many or most decisions we make in life.
- The neocortex, is the logical, methodical, and analytical part of the brain.
When you look at how people buy products, it turns out that the behaviour corresponds with these three parts and it translates to the three core aspects of the job your product is hired to do. Let’s use a personal navigation device like TomTom Via as an example:
- Functional: I need to find my way efficiently and on a scooter I find myself stopping every 4 streets to pull out my phone and figure out where I am.
- Emotional: I could get lost or mis an appointment if I forget my phone, it’s dangerous to drive with my phone i my hand, my expensive smartphone may fall out of a steering wheel mount, this is a really cool device, whooo matches colours with my ride!
- Social: I will look cool among my friends, I’ll be the one they’ll follow since I know the way.
There is even a priority to these (product owners love priority stuff!) Psychologists have discovered that when these three parts are in conflict, the reptilian takes precedent over the other two. When there is a conflict between the emotional and intellectual parts, the emotional part wins over. This is why people often make poor, emotionally based decisions, then find an intellectual alibi to justify themselves.
Now step in your Tardis and go back to 2007. Was the original iPhone really really functionally better than the Nokia or Blackberry? Sure it had the touchscreen and did something novel with that, you can use the Kano model to explain that aspect of it, but what it did most of all is attack the two job drivers that had been neglected: emotion and social. It also works the other way around: Body shop was started to emphasise the functional aspects of products that were typically driven by image and emotion. They focus on organic, and they improve the quality of one’s skin (anti-aging properties)—blending function with emotion.
How it affects the product vision
What’s really important to realise is that you are not a product owner, but a problem owner. The good thing about that is that in a time of disruption and extremely short product life cycles, the jobs of a customer remain fairly constant over time. Which means you just need to be innovative in fixing it, but that is something we love to do. So your product vision should not talk too much about how you solve the problem or what your product looks like, but rather why someone should care about it. (Getting faster from A to B in comfort Mr. Ford!)
How it affects the Product Backlog
It doesn’t need to. After all Scrum talks about Product Backlog Items, but predominantly we see user stories as the main way to describe what the Product Owner wants the Development Team to change in the Product and there is a risk involved. Let’s look at the User Story template:
As a <User> I want <Action / Functionality> so that <Outcome>
The problem is in the assumptions.: Did we get our persona right, or did we just write “user”?, how do we know what it is that he or she wants? there might be a much better way to solve the problem. Expected outcome is usually specified functionality and doesn’t factor in emotional or social elements.
A better format would be:
<persona> has a <problem> and therefor suffers <consquence>
As a user I want to mount my device on the steering wheel so that I can use it while cruising
Eddy the Elder fears that his navigation aid will fall while he is driving which would cause him to be lost
As a user I want the device to be round so it matches my mirrors
Sally the Student wants her scooter to look better than that of her fellow students by adding tech but fears it will look nerdy
Or in case you were wondering why the new MacBook no longer supports the MagSafe connector:
As a user I want a magnetic connector on the power cable so that my expensive MacBook is not send flying through the room when someone trips the wire
Arnold the Average user fears to run out of power during the day which would make it only possible to use the MacBook with the charger attached
Apple upped the battery so you don’t need to charge during a normal workday, which makes even the need for that awesome magsafe go away.
Think about your product in terms of how it solves problems, then find out what it is that makes people buy your products. Circle back to functional, emotional and social needs and re-asses your value proposition from that point. If it does not reveal new competitors, substitutes, or novel ways to solve the same problem you may want to rinse and repeat.