Generally speaking, non-technical people are unaware of the wide array of possibilities technology has to offer and the ways their problems can be solved. Heck, they do not even think about having a problem in the first place.
That is where product people come in and offer their expertise. By observing, asking the right questions, and identifying problems, we are able to come up with solutions that have the potential to improve people's lives.
The three simple steps below will help you to build products with the end-user in mind, and not get lost in the realm of fancy frameworks, complicated features that no one needs, and the desire to ship flawless applications. Done is better than perfect.
It is tempting to look at a request, think about a solution, and immediately start getting our hands dirty to ship it. But was the original request really a problem, a short term pain or just confusion?
We do not know until we start to ask questions. Lots of them. Doing it we will be able to identify the root of the problem, and that can be totally different from the initial request.
Asking open-ended questions that help to describe the problem (for example "Do users struggle finishing purchases and why?"), instead of seeking validation for a given idea (for example "Will universal login reduce the friction of finishing purchases?") is crucial. This way we are going to be more open to different solutions and less exposed to confirmation bias.
Our resources are limited, so it is necessary to prioritize based on what the impact is going to be. Failing to do this could hijack our attention and lead us down the wrong path.
The moment I realized that I am here to solve problems, and not write the most beautiful code, I started to enjoy even more what I do. I love seeing when a piece of code I shipped makes an impact.
It is a good practice to think about how the minimal viable product (or simply the "MVP") could look like. Erik Reis, in his popular book, "The Lean Startup", defined the MVP as:
The MVP is a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
This can be done by having a discussion with your team and the different stakeholders about the MVP, define the features you want and stay on target. By doing this, you will be able to remind yourself about the big picture when the pressure to add a new feature is going to rise.
Before we go nuts, it is better to implement the simplest version of our product and test it with real users. We will save lots of time by skipping the work on features that no one will ever use and we will start adding value to the user by shipping a product they can start using right away.
As I said before, our time is limited, so let's use it in the best possible way.
I have fallen into the mistake of trying to have the best version of the product ready for the launch countless times. And it was never efficient. There were quite a few times when we did not even release what we have built.
It is a better practice to release a usable version of the product as soon as you have it ready, and iterate after. You do not know how your users are going to use your work until you deliver it to them and see it in action. Give them time to learn how to use it. See where they struggle. Listen to their feedback. And then start over from step one.
Product development does not need to be complicated. It is a relatively simple process that you can start mastering by implementing the three principles outlined in this article.
How do you approach product development? What is your secret to keep it simple and functional? How do you make sure that you are delivering value?
Reach out to Robert on LinkedIn, Instagram, GitHub, Goodreads, and make sure to check out his website!
You are a tech freelancer and want to join our community?