Five steps to making a product users love

Jenny Brown
Jan 28, 2016 · 8 min read

This is the culmination of a few years’ worth of discovery, practice and thinking from working with early-stage digital products. This is my playbook that describes what I do, and a little of how I do it.

It’s written from the perspective of a product right at the start of its life — an idea waiting to be realised, and primarily for people inexperienced in building digital products. But it can be applied to any stage of a product’s life and is by no means a definitive approach. It’s a guide to help the novice in particular navigate getting their idea to functioning product in simple steps.


“Your goal … is to make something users love… This is critical — think about the really successful companies of today. They all started with a product that their early users loved so much they told other people about it. If you fail to do this, you will fail. If you deceive yourself and think your users love your product when they don’t, you will still fail.”
Y Combinator Startup Playbook — http://playbook.samaltman.com/


Five steps to making a product users love

These steps are intended to help deliver a successful product that is designed with users in mind.

Testing is included in every step. It’s important to adapt the product in response to user feedback and keep refining until you are satisfied your product meets the needs of your users.

It’s also very important to understand your users and target the right group. Make sure you spend time at the Hypothesis and Service stages in order to get that bit right. And if you build your prototype and then find it doesn’t work for users, go back to the beginning and try again. The first three steps are there to help you get it right, even if that means failing a few times in the process. It’s better to fail at that stage than after you’ve spent time and money writing lots of code.

Hypothesis

It’s important to take the time to develop a set of hypotheses. This is where you learn about the problems that need to be solved and work out what makes your solution unique compared to others.

Even if you think you understand the problem from the start you should test that your theory is correct. You might find that your product changes as you learn more about the people who will benefit from it.

How to format your hypothesis:

[These people] [experience this problem] which results in [this outcome].

[These people] will want to use our product as it will provide [this improved outcome].


Exercise — write an hypothesis for your product:


Techniques to use to develop and test your hypothesis:

Resources:

Design the service

This is where you decide which tools and techniques you are going to use to solve the problem. You will identify all the different elements of the product and plan the flow that users will follow.

It’s important to stay focused on your users/customers and plan the solution based on what you learned from them as you were developing the hypothesis. You should use the research you did during the hypothesis stage to decide which technology platforms to use.

This is also a good time to start thinking about how you want the product to look and feel to users. Should it be formal and official or fun and playful? Start collecting examples of design and copy that illustrate the kind of feel you want for your product.

What you should end up with:

Techniques to use to design your service:


Exercise — map Uber’s service

Make a diagram showing how Uber works trying to identify all the different elements that make up the experience for users, drivers and the back office processes. This isn’t about accuracy and don’t worry if it’s very rough, it’s trying to help you think about all the different elements that make up one product.

As an example, here’s one I made earlier:

Doing this exercise with your own product will help you identify the different elements that your product needs to function.


Resources:

Make a prototype

Having a prototype will help you work out solutions for the user interface (UI) and gives you something tangible to test and show to investors. Keep it very simple — concentrate on core functionality (minimum viable) but keep a record of all the ideas you come up with that could be added in future.

For hardware products some engineering will be required, but for software products no coding is needed. Your prototype could be a series of flat designs that form a sequence. Designs could be highly polished, or hand drawn wireframes. Alternatively it could be a video that shows how it works — the way Dropbox did it, or launch a website to test the idea first like how Buffer did it.

What you will end up with:

Techniques to use to build your prototype:

Resources:

Build an ALPHA

This is where you launch your product to the world.

Take what you have learned from the prototype and build the minimum viable version of your product. This is where you should start building robust and extendable code that will support new features and improvements. Keep a record of all your ideas for future development and don’t be afraid of saying ‘No’ to features that are unnecessary at this stage.

You will want to use an agile project management technique such as Scrum or Kanban to focus your team on delivering the most important features of your product first. Prioritise the ideas in a product backlog and brief the team to work on the top priority items first. This means that you can focus on delivering the minimum viable version of your product knowing that other ideas and features can be added relatively quickly in the future. Nothing is forgotten, nothing is lost. But everything must be prioritized.

What you will end up with:

Techniques to use to build your ALPHA:

Resources:

BETA and beyond

Launching a product is just the beginning. There are many stages on the journey. Hopefully you will be working quickly towards a stable platform that is accepting revenue and supporting users. It is up to you when the BETA label is no longer required but typically it is when your fundamental platform is robust and you can set your sights on scaling rather than getting the basics in place.

Arguably this is also where your journey begins. Getting to BETA and beyond does not mean your product backlog is empty. In fact it’s likely to keep growing. It’s best to work in software sprints, building, testing and getting feedback from users every step of the way.

You may find that over time your product morphs into something quite different to how it started — as you get feedback from the people using it and respond to their requests.

Resources:


I hope you find this guide useful and that it helps make the product development process a bit less daunting.

UX Qatar

UX. Product Development. Startups. Qatar.

Jenny Brown

Written by

UX & product development specialist based in Doha. Helping startups in Qatar build brilliant products to change the world.

UX Qatar

UX Qatar

UX. Product Development. Startups. Qatar.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade