3 things everyone should know about product development

Technology has become a commodity. With enough resources we can build anything — from neural networks to a live-action “Cats” movie. The real question is, does anyone need it?

To help honestly answer this question — and tackle the law of triviality — I distilled my hands-on observations related to product development into three points.

We’re Selling a Story

Usually, we don’t have to invest months of work and write countless lines of code to discover if anyone needs our product. We need a good story, a relevant experiment and participants for that experiment.

A good story can make you spend thousands of dollars on a fake luxury music festival. We are shaped by narratives — the blend of stories, myths, facts and half-truths that we buy into throughout our lives. They define our beliefs and who we connect with, even more so than our DNA.

When it comes to product development, narrative often gets sidelined and the emphasis is usually put on technology or design. Yet, it’s safe to say that we’re neither trying to sell code nor pixels. We are trying to sell a story.

Product vision doesn’t care about Material Design or the cool thing you did with Redux. Users can appreciate value proposition, even if they don’t understand how API works. I noticed they are not concerned with the 2-pixel border radius on buttons, but they fancy a product if it can solve a pain point. While chasing growth, we’re perfecting the story for user acquisition or a sales pitch.

Embrace the Experiment

When we expose an idea to the world, it can either evolve, cease to exist, or leech off of wishful thinking and fallacies. We should accept the facts stoically, because fighting against the facts and reality is futile. Take communism, for example. It fought the reality and failed to get a happy ending. Theranos fought the reality, too, and it didn’t win.

Organizing an experiment and interpreting data is demanding, but falling for confirmation bias and investing time in a non-viable product is just tragic.

And the truth is — most products fail because they build the wrong things.

Instead of diving straight into development, we should ask ourselves, “What data do we need to validate the idea?” followed by, “What experiment do we need to collect the data?” Since we’re dealing with complexity, the outcome of the experiment might not be predictable or self-evident. Sometimes we might put ads on the side of a bus to test how effective they are as a marketing medium, and end up creating a demand for an imaginary drink.

Some years ago, I had an idea to create a visual website builder for SMEs. I set up a landing page explaining the product and paid $20 to promote it on Facebook. Several companies signed up, but I soon discovered they were not able to write a value proposition, create a cover image or an explainer video.

Because, you see, the real problem didn’t come from website development — it came from the inability to create good content. And as you noticed, the cost of a lesson can either be months of development or $20 for Facebook ads.

To maximize an experiment’s success and objectiveness, we should be familiar with certain research principles:

• We make irrational decisions — no one needed a fidget spinner, but at some point in human history, everyone had a fidget spinner.
• We don’t always do what we say — avoid studying behavior with surveys or other attitudinal research methods.
• Avoid asking about future behavior, as we tend to overestimate ourselves or have projection bias.
• Always consider the context in which a specific behavior occurs.
• It’s usually more useful to ask “how” rather than “why”. “Why you do something” is a philosophical question, whereas “How you do something” can help us recognize an opportunity for improvement.
• Don’t lead users to an answer, don’t fish for compliments.
• The relationship between our mind and statistics is difficult — be careful when analyzing data, we inherently try to frame it into a narrative or recognize causality when there is none.

There Are No Absolutes

In the context of websites and cloud apps, there is no such thing as the final product.

The co-evolution between a product and users never ends — as product improves users’ well-being and the users influence product features. Thanks to the continuous delivery approach, we can embrace the pivot points while releasing quickly and frequently. We could be working on cryptography and security software for PDAs, and at some point switch to creating worldwide online payments system.

Is it better to have a product that’s good enough every day or a perfect product on most days? It’s a trick question, really, because there is no such thing as the perfect product.

User experience is subjective. Some people like iPhones, some like Android — de gustibus non disputandum est. A German businessman and a Korean schoolgirl might appreciate different things. Without understanding user needs, we could be set on creating the best green stripe soap bar, only to discover users don’t care about the green stripe, but about other soap qualities.

Design plays an important role in marketing and the perception of the quality of a product, yes, but the product requires a certain balance between form and function. Usability will always trump aesthetics — except in Apple’s case. I don’t like my e-banking app, but I still use it every day because I don’t have to visit the bank office. Remember how Facebook looked in 2006? That didn’t stop it from becoming the monster it is today. When we look at Craigslist, we can forget that it’s in the top 20 most visited sites in the USA. People spend more time on Craigslist than on YouTube, Instagram or Amazon.

Sometimes, we might do everything just right — validate the market and have a working product — and still fail. Sega announced Saturn in 1995 and got killed 30 minutes later by Sony’s famous 299 announcement. When dealing with complexity, there are no best practices to rely on. If an experiment played out well in the past, it doesn’t mean the same thing will happen in different context. If a solution worked well yesterday, it doesn’t mean it will work tomorrow.