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 — I distilled my hands-on observations related to product development into three points. the law of triviality 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. 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. A good story can make you spend thousands of dollars on a fake luxury music festival. 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, “ ” followed by, “ ” Since we’re dealing with complexity, the outcome of the experiment might not be predictable or self-evident. What data do we need to validate the idea? What experiment do we need to collect the data? 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 “ ” rather than “ ”. “ ” is a philosophical question, whereas “ ” can help us recognize an opportunity for improvement. how why Why you do something How you do something ● Don’t lead users to an answer, don’t fish for compliments. ● -- be careful when analyzing data, we inherently try to frame it into a narrative or recognize causality when there is none. The relationship between our mind and statistics is difficult 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 -- a product improves a user’s well-being and the user influences that product’s features. Thanks to approach, we can embrace the pivot points while releasing quickly and frequently. the continuous delivery 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 -- . A German businessman and a Korean schoolgirl might appreciate different things. de gustibus non disputandum est 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. 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 a different context. If a solution worked well yesterday, it doesn't mean it will work tomorrow. Sega announced Saturn in 1995 and got killed 30 minutes later by Sony’s famous 299 announcement. I translate human needs into the product features. I published a few articles about the design process and complexity . In my spare time, I like to compose music and write fiction. I don’t talk much, but feel free to reach out and chat me up on LinkedIn .

Amazon

Apple

Facebook

Instagram

Sony

Stripe

YouTube

Subjectivism and Organizations: Part 1

Ask Me (Almost) Anything

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

3 Things Everyone Should Know About Product Development

3 Things Everyone Should Know About Product Development

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Meet the Writer: HackerNoon Contributor Novi Milenkovic Talks Complexity Management and More

10 Prioritization Techniques for Agile Product Development

10 Online Free Courses That Can Help to Learn Agile Development

20 Trackable Metrics to Make Software Development Teams More Efficient

140 Stories To Learn About Agile Software Development

Meet the Writer: HackerNoon Contributor Novi Milenkovic Talks Complexity Management and More

10 Prioritization Techniques for Agile Product Development

10 Online Free Courses That Can Help to Learn Agile Development

20 Trackable Metrics to Make Software Development Teams More Efficient

140 Stories To Learn About Agile Software Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps