9 Steps To Building A New Product — From Idea to Launch

9 min readJul 7, 2020

A breakdown of the Product Development Phase.

As promised in my last post which covered a few things to consider before building your digital product, we’ll be discussing the product development phase in this post.

I’ll try to cover a lot (as succinctly as I can), so this post may be longer than usual, but well worth it.

It’s also important I clarify a few things:

These steps may vary across organizations and the type of product you’re building (yours might be more or less than 9 phases), but I’m 100% certain you will have to cover a majority of the phases discussed below; if not all.
Building a successful business is not akin to building a successful product. You can hit one and miss the other; this post focuses on the product, as the title implies, so there’s also a business side to consider which is not discussed here.
For those unfamiliar with the landscape, I’m referring to digital products in this post (Web/Mobile Apps, etc).

The 9 Phases

Ideation
Research
Sprint Planning
Product Design
Review & Feedback
User Testing
Development
Testing
Launch

1. Ideation

In this phase, your product idea needs to be fleshed out to a certain extent. Emphasis on “a certain extent” because your idea may not be fully formed until the 6th stage, and in some cases, your idea is actually never “fully formed”, nor is it supposed to be.

In the ideation stage, you sit with key stakeholders (your partners or close friends) to discuss all angles of the idea. Sometimes, this is referred to as Problem Analysis:

What’s the problem this product is solving? (Ps. I don’t believe every product needs to “solve a problem” per se, but every product must provide value. Products can be built for different purposes; for example, Snapchat doesn’t necessarily “solve a problem”, but it provides value to a certain group of people).
Who is this product for? or Who has this problem?
Is it a mobile app? Web app? Do you even need an app?
How does it work?
What are some of the risks involved?
How sustainable/scalable is it?
Is this the right time to build this?
Why is this even being built? (Keep ego out when answering this)

In this phase, your goal should be:

Understanding the core idea of the product you want to build
Understanding the problem you want to solve (or value you want to provide).
Understanding the market you want to address.
To the best of your ability, you need to understand why this is the right product to build, why no one else is building it (if there’s no one else), and what your idea looks like in the marketplace. You want to be able to answer hard questions about this idea. So find some people to discuss the idea with.

Something I practice is having a one-page document for any product idea I have then sharing that with people to question. The document consists of

What [it is]
How [it works]
Why [I want to build it]
When [I want to build it]
and possible Challenges I might face.

Find out as much as you can about your idea before spending any money on it.

2. Research

As mentioned in my previous post, Research is probably the most important phase of this process. If you did everything else right but skipped this phase, the possibility of failure is very high. It can get emotional because this is where you find out the truth and validity of your idea, whether it’s feasible or not.

By the research phase, we assume you already have a solid idea of how this product is going to work and you can answer tough questions, so it’s time to talk to people. There are multiple ways to conduct research, some of which include (1) Online Surveys, (2) User Interviews (3) Online [Unstructured] Research.

In this post, we’ll focus on User Interviews. User Interviews consists of speaking to your potential customers about the product (This means you already know who your product is serving from the ideation stage).

Say your product is a mobile application that helps university students solve math equations; the first thing you’d want to do is come up with a list of questions before carrying out interviews. When conducting interviews, it is VERY important that you avoid imposing your beliefs/ideas on the users, and instead let them answer without bias. Here are some good and bad questions for the equation-solving app.

Bad Questions

We have an app that will help you solve math problems, is that something you’d be interested in?
How much would you pay for an app that helps you solve math problems?
If we built an app that helps you solve your toughest math problems in seconds, is that something you’d pay for?

These questions are bad because they lead the person being interviewed towards an answer.

Good Questions

Do you have any issues when solving math problems?
How do you currently solve math problems?
What other methods have you explored in solving math problems?

You’ll notice in the questions above that your product is never mentioned. During interviews, you’re not selling, you’re learning. User interviews are about user behaviour, finding out how your users currently behave, and then finding where your product fits in, not the other way around.

Until now, your idea has been just that, an idea. The answer to question 1 will let you know if there is any validity to your idea or not, because if they have no issue solving math equations, then your product is not needed.

It’s also important that you talk to a good amount of people in order to create a sample size that yields valuable results you can act on. Try to get emails from these users as well, because you’ll need them later. Ask them “Would you like us to email you about a solution we’re building to solve this problem?”

You also have to make sure you’re talking to the right people.

Imagine how imminent failure is when the app you’re building is to solve problems for university students but you’re interviewing Middle School students. Make sure you define the audience before you go out.

3. Sprint Planning

In simple terms, Sprint Planning is a meeting with your team (designers, developers, analysts, etc) to determine what you’re going to build in the upcoming Sprint, based on the data you have garnered from research.

A ‘Sprint’ is usually a timeframe between 1–4 weeks, but don’t let that constrain you. Feel free to set a more comfortable timeline, but it must be defined and understood by everyone.

The main goal here is to determine what your product is going to look/feel like at the end of the Sprint.

It’s important that your developers and designers are in this meeting. Although the developers don’t start the main development work at this stage, it’s important that they have input in designs in order to avoid conflict in the future.

Because this is the first version of your product, your MVP (Minimum Viable Product), you should focus on building only the things you need. The university app mentioned above, for example, only needs to solve math equations as the core offering. Not payment, video, social interaction or any of that fancy stuff; solving mathematical equations is the ONLY important feature. This is where you need to prioritize what features are being built. Usually the job of the Product Manager.

4. Product Design

Now that the team has agreed on what is being built, it’s time for the designers to start putting sketches together. At this stage, there should be a circulated PRD (Product Requirement Document). I discussed PRDs in the last post.

There are usually 3 sets of design:

Wireframes
Mockups
Prototype

Your designer(s) may either build according to these 3 sets, or decide to jump to step 2.

Personally, I like going through the 3 steps, in order to give feedback in-between.

It is very important that you and your stakeholders review the design and give feedback after every step.

The wireframes will give you an idea of what the product looks like, structurally, in greyscale. This is a skeletal view of the product, in which you review for any structural changes needed.

After implementing your feedback on the wireframes, the designer goes on with the mockups.

Mockups are basically wireframes, but with color. The reason I look at wireframes before mock-ups is so the designer makes changes before applying any color to the design.

Prototypes are a form of interactive design. They can be used to test how the product feels, since it lets you play around and switch between pages.

5. Review & Feedback

Although this was partially mentioned in the Design phase, it deserves a section of its own.

Now that the designs are done, it’s important that you thoroughly review every aspect of the product. A good way to do this is by creating a user story map. In simple terms, try getting from point A to Z then jot down all the glitches you face along the way. Point A-Z in the equation app mentioned above is as follows: Download App > Register > Enter Equation > See Answer > Close App. Something along those lines.

Remember, the technology behind your product hasn’t been built yet. You’re still testing the design and the fluidity of the product, so there might be some areas where backend development is required, therefore might not be responsive, depending on what platform your prototype is built upon.

6. User Testing

Now that you have somewhat of a working product (prototype), it’s time to test it. Remember the people you interviewed during research? Those will be part of your testers. You have various types of testers;

Alpha Users (You, your stakeholders, internal team)
Beta Users (Research users, Family, Friends, etc)

Alpha Test

Your internal team tests the product based on the PRD and deliverables. You can also include people who aren’t part of the product team to get a different perspective.

Beta Test

This group is the most important when testing. Reach out to private beta testers (Family, friends, and some of the people you interviewed) to help you test your product, and make sure you’re monitoring how they use it.

Remember, there has still been no code written for your product yet, so some things may not work, but for well-defined prototypes, a lot of the functions should work.

What this test reveals are the areas where users might have issues which you or your team may have forgotten or just not accounted for (You’d be surprised the kind of things you miss. Even if you’re part of the potential users of the product). It’s always good to get a fresh set of eyes on your product in this stage because you don’t want developers building something people can’t use because of a minor issue.

When you’re done, get all the feedback from testing, then send back to the team to implement in the design.

7. Development

Now that your product has been designed and the prototype has been tested, the developers can start writing the code to bring the product to life. The only areas you may need to focus on here are:

Milestones & Deliverables
Deadline

8. Testing

Post-development testing is different from post-design testing. In this phase, you’re testing the entirety of the product.

How do the pages transition between each other?
Do all the buttons work?
Is the product responsive? (How does the product look on mobile and other devices?)
Does it accomplish its core purpose?

Testing happens with the same group of people from the post-design test, but this time, you can invite more beta users.

Remember, the most important part of testing any product is monitoring how it’s being used. You may not be able to closely monitor each person’s usage, but the more you can monitor, the better.

Don’t make the mistake of sending your product to beta users for testing, and then expect the users to give feedback. The users may not capture all of the problems they face, especially when they ultimately arrive at the desired result. For example, if a user, while testing, had to tap a button twice for a page to load, they may not record that as a bug, since it’s pretty minor and can be attributed to something else, like network connection. However, when you watch users use the product, you’ll be able to see that tapping a button twice is an anomaly, so you can take that feedback to the team to get it fixed.

9. Launch

When testing is done and all the feedback have been implemented, you can now launch your product, based on your launch plans. It’s important you launch your product via the right channels in order to reach your target audience. Launching via the wrong channels will only cost you valuable resources.

Launching your product may be the end of the development phase, but it’s only the beginning of an even more important journey, which is managing the product. In another post, we’ll discuss a few things to look out for when your product has been shipped.

That’s it for now.

Thanks for reading.

I’m a Product Manager & Consultant at Olubrain.