How to build a product — a full guide to the product development process

In order for an idea to become a working product, it must be transferred from the plane of creativity to the plane of clear organization and planning. To do this correctly, one needs a product development process — a “step-by-step guide,” which will help gather information, organize the work, set some deadlines, and assemble the best team.

Below, we will analyze what steps are included in the product development process, why we need them, what product increments do they bring, and who is responsible for them.

First steps

So, this day has come. You have been nurturing your idea for over a year now and have discussed it with a whole bunch of people. It’s time to finally make your dreams come true and bring something new and useful to the world.

To move from an idea to product development, you have to be confident that your product fills a need for future customers that no one has filled before (or at least that does it better than what is currently available on the market). There is an almost 100% guarantee that your plan won't work if your idea isn't backed up by any of this, being just a weird fantasy or a mere imitation. We’re not going to talk about those since these products usually don’t last a year, and they are basically a waste of money and resources. They get thrown away for a bunch of reasons, and below we’ll discuss the most common mistakes startups make and the ways to properly adjust your processes in order to avoid them.

You can either do it yourself or have some professionals involved, but we strongly recommend being cautious about rushing your product to the development (but not too cautious — good timing sometimes accounts for 80% of success). Anyway, when you have some concrete data to back your idea up, and you know why you’re doing this, you can finally hire your first team and get rolling. The team can be outsourced or in house, it’s up to you to decide, but you may want to take a look at our article about some pros and cons of outsourcing here.

The main stages of product development

Discovery

Okay, so here you are in an office or on a Zoom call with your PM and likely some other members of the team who will work on your project. Where do you all start? First of all, you need a proper Discovery phase. This includes conducting research, writing some technical specifications, creating a proof of concept (PoC), and coming up with a list of high-level tasks or epics.

Why do we need a Discovery phase anyway? To make sure we don’t spend a couple of months worth of budget on implementing a new feature that the users won’t need. Or that we don’t pick an obsolete technology or service that will block us from adding new functionality in a year. Or that our system architecture won’t be able to handle a huge amount of users. Or that we spend 2 years developing something just to find out that now we have 10 new competitors and some of which are better than us. This list can go on and on.

How exactly can we identify the hurdles that we may face along the way? Through risk analysis. It involves examining how project outcomes and objectives might change due to the impact of the risk event. Once the risks are set out, they are analyzed to identify their qualitative and quantitative impact on the project so that appropriate steps can be taken to mitigate them.

The main risks are usually the same, and we do our best to have them covered as early as possible:

• Going over budget.
• Going over timeline.
• Choice of technology.
• Content and data migration.
• Integration with 3rd party services.
• Loss of traffic, SEO.
• Code quality

When we evaluate risks, we use a risk matrix.

Risk Exposure or Risk Score is the value determined by multiplying the Impact Rating (High – Catastrophic (Rating A – 100); Medium – Critical (Rating B – 50); Low – Marginal (Rating C – 10) with Risk Probability (High – (80 % ≤ x ≤ 100%); Medium-high – (60 % ≤ x < 80%); Medium-Low – (30 % ≤ x < 60%): Low – (0 % < x < 30%).

We then use the resulting values to add the risks that we know of to the matrix. The rule of thumb here is to come up with a response to everything we are aware of but accept the fact that some unidentified minor and medium-level risks might occur. You can’t predict the future, but you can better prepare yourself for what’s in store.

Sometimes we can skip some of the steps, but it’s usually better to spend another week on the research than have your devs change the framework two months after the work was started.

Tech specs are also an important part of any project — your developers will thank you when they see a proper document describing the project architecture, best practices, possible bottlenecks, concerns, and so on. Also, they won’t have to sit through several calls with ten members of the team, half of whom will be wondering why they are even there, with another half thinking all of it could’ve been easily replaced by a proper tech spec or an email.

PoC

This part can sometimes be skipped, especially if the product is small or the team working on it is experienced in this particular type of software. Usually, PoCs are made to test some new technologies and simply make sure that everything you want in your product will work the way it’s supposed to at later stages. Many great projects were blocked or even dropped because the developed product turned out to be inoperable, some API didn’t work, or the hosting was too simple for the technologies used.

Sometimes customers want to use a feature they saw somewhere on the web, and it’s our job to make sure this feature can be implemented. Who knows, maybe a competitor spent 1 year of dev time on implementing it, and we simply don’t have enough resources to do the same.

Design

Although here it’s just one of the points, in reality, this is a whole different project inside the development. It also has its own stages and processes, but we won’t cover them in detail. We start with the design concept that covers all of the required functionality, go through multiple iterations and finally come up with a UX — a wireframe of how your product will look.

When we work on some B2B or B2C solutions, clients usually care more about the functionality and the user experience rather than the design, so this UX can be rather simple design-wise.

After all, we can always fine-tune the design once the product is live. After the UX is done and confirmed, our designers create a UI — the very file that the developers will use for the markup.

Setting high-level tasks

This is your PM’s time to shine. Everybody loves a good and thorough ticket, but we need to start at a higher level first. Your PM will talk to the team and identify the key aspects of the future projects and their timelines. Then they’ll transfer all of them into a task tracker and will later use these tasks as a basis for everything more detailed.

A few words about the estimates — a thing that will keep your developers awake at night, making them want to block their PM in Slack. Giving estimates is hard, and the sooner we give them, the more approximate they are. Just take a look at the cone of uncertainty — depending on the project stage, the estimates may differ up to 400% from the final result.

Don’t be afraid, that’s why we are gathered here, and that’s why we spent so much time on this research. Having any estimates is vital for product development because the budget costs and the timing depend on this, but we constantly keep updating the values to make sure we have the best available estimates at any given time.

Minimal Viable Product

According to statistics, 35% of startups are left with nothing as their offer is not attractive to the market. If we look at successful examples of MVPs, it’s worth emphasizing their sustainable development. Amongst the lucky ones, we can point to Uber, Twitter, Snapchat, Dropbox, and even YouTube. The minimally viable product should be used as bait for the users to show their feelings about the product and disclose what should be improved and which new features should be added.

Sometimes it’s challenging for the client to agree on a minimal scope and improve the existing product feature by feature. In such cases, we try to help our client to decide on: key functionality, user portrait and niche, how users learn about the product.

This is necessary to start a small working business, which will then evolve. The possibility of validating your idea as soon as you can sounds very exciting. Often it’s better to have a product with minimum functionality that doesn’t work perfectly than spend another year on gold-plating and realize that you are too late.

Sprints

Sprints are the timeboxes where previously planned tasks turn into value. Basically, we decompose the team's work into small pieces (tasks) and fill sprints with them. The manager will apply one of the frameworks to run the processes smoothly. Sprints will involve routine meetings dedicated to daily issues, planning, demos, and even meetings focused on continuous process improvement.

In Halo Lab, we have a dedicated Sprint 0 (just don’t tell our Scrum masters about it). We use it to review our processes both with the team and the client to find the best ways of cooperation. We define the scope of the pilot sprint to see how things go between the team and the client. Here the PM begins establishing the development process, the team sets up the working environment, and we start rolling.

Pre-release activities

Prepare and test everything before the release. A few things need to be done before launch, and one of them is to stop working on the project scope. There will be bugs, so you better prepare yourself. It’s hard to hear that, but unfortunately, that’s how the development works — the more complicated the product is, the higher the chance some code won’t be working properly. To make sure we face as few bugs as possible, it is a good idea to involve a Quality Assurance engineer. Together with your PM, you will create a plan on how the release should go and once you’re all set, just give the team the green light.

Going Live

Get a fine bottle of champagne and relax, you’ve earned it. But don’t celebrate for too long, because the work is never over, and new things will keep coming up again and again.

One thing to keep in mind — don’t ever plan your release on a Friday.

Post-release activities

We still need to perform post-release QA because you never know what exactly can go wrong after the launch since some users are very inventive when it comes to finding new bugs.

Depending on your goals, after the release, we can pick one of several scenarios to continue our work. Usually, we keep developing the product because, in a modern and rapidly changing world, you just can’t afford to stop. We add new features, closely follow our competitors to stay on top of the latest trends, and talk to our users to identify and remove bottlenecks. We also focus on fixing the remaining bugs, if any are still present.

Next version

To continue developing new features, we need to start the process all over again. We’ll talk to the users, create a backlog of tasks, assign them to our developers, and test everything in the end. Now that all release activities are set, we can release new features more often.

How the product development process works in real life

Enough with the theory, let’s get down to some interesting stuff. We’d like to talk about how this process works in real life because it’s all fun and games until you start working. We were developing a product for a European company and went through all the stages described above. And we also had a whole bunch of people working on each and every step along the way.

What problems we tackled with the discovery phase

As mentioned above, we start at the beginning — the research. That was the case here as well. We had a client with an interesting idea, but we needed to make sure it was viable and implementable within the required time scope and budget.

The range of ideas is enormous. One of our clients was working on a service that allowed users to call up a specialist to their home — be it a technician to repair something or a nurse to provide medical assistance. And another one created an NFT store. You never know what your next project will be about

.At the project start stage, we had 3 people on the team — a project manager, who was partly acting as a product owner, a tech lead, who was responsible for making sure all of the features we need can work, and a designer, who was working on the product interface.

We started with a brief market research — studied the competitors, checked market trends, created some user personas, the usual stuff.

The next step was holding a workshop with our client to get as many requirements as possible and understand the overall expectations from the project. During the workshop, we discussed several important questions:

• How the success of the project will look like and how will we measure it;
• What challenges and constraints are we aware of at the project start;
• Which personas will our product have;
• What are their needs and expectations, goals, and pain points;
• What’s the sitemap for the product;
• How will the user flows for different roles look like.

Having gathered all this information, we proceeded to another step of our research — potential user interviews. We were lucky to have a few of those; that’s a really powerful and helpful tool, but unfortunately, it’s a rare case. We already had an old system running, so this was a bit easier for us. During the interviews, we were able to better understand the expectations from the new system in comparison to the old one, and identify the major bottlenecks and processes that were organized poorly.

When was the first line of code written

At this stage, we already had a huge pile of data, and it was now time to finally bring something to life. The first thing to consider, even before the design, was the integration of a 3rd party service for an important part of our product. The need to introduce this service was based on the info we gathered before — our tech lead decided that it’s better to use a ready-made tool and save us months of development time. But before proceeding, we needed to pick a vendor and make sure it suited all of our needs.

That’s where our tech lead created a PoC. It didn’t cover the whole product, we were only focused on making sure the service we pick won’t eventually block us feature-wise. The tech lead went through several services, picked the one that seemed like the best fit for us, and created a small PoC. The good news was that everything worked smoothly, and we were sure that the service — CoreLogic in this case — could meet our needs no matter what. Even better news was that even though we spent an extra week on this early in the project, we had confidence that our project architecture was solid, and the client gave us the green light.

How did we start to visualize the product

After that, we felt that we are finally ready to proceed with the design. Again, this was a whole new project inside our current one, so it took us quite some time. The designer took the user flows that we prepared beforehand and came up with a wireframe of how the product will look like for different roles. Our small team went through it and made sure we had everything covered. We presented the results to the client and received some valuable feedback from their side. After all, they are the ones that know their product the best. Later we used this wireframe to build a proper UI for our developers to start creating a web application.

Please mind that even though the paragraph above is only several lines long, the amount of work here is enormous. We have a lot of iterations, and I can’t even count the number of calls we had with our designer when dealing with everything. When you start to see the product design, a lot of things emerge that no one has thought of before, those that seem obvious now. Anyway, long story short, after several weeks of work, we had a Figma file with all of the designs and were ready to proceed with the development.

How did we make the job for our developers easier

While our designer was busy with the UI, the tech lead prepared a technical specification in cooperation with the PM. It included general project background, description of the current and proposed solutions, business logic, test, and deployment plan, third-party service considerations, security and accessibility considerations, risk analysis, SEO plan, rough estimates and scope of work, etc., etc. This was done to make life easier for our development team, and over the course of the project, we thanked our past selves for being so cautious and having spent so much time on the preparation. We also engaged our SEO specialist and Head of QA at this stage to make sure we have everything covered.

When did we establish a stable work cadence

Finally, the first day of the Sprint 0 came. We usually start with a Sprint 0 because launching the development of a big new project is complicated, and there’s always some friction at the start, no matter how prepared you are. But on this day, our dev team, which initially included 2 BE and 2 FE developers, had a whole bunch of info prepared — very thorough project research, PoC of a third-party service, technical

specification, and the design itself. This is where serious development work starts, so during this sprint, we pay extra attention to teamwork and interaction with our client. We need to solve process problems at an early stage and not let them overwhelm the project. All of this is covered in this Sprint 0.

After this was concluded, we had a short sprint demo with our client to show everything we’ve been working on over the last 2 weeks and to confirm the further scope. After this is done, we can finally say that the preparation stage is over, and we can proceed to a more or less stable work cadence. The work is split into 2-week sprints; we hold sprint planning and sprint retrospective meetings with the team and demo our work to the client every 2 weeks.

What did we do to complete the project

After several sprints, a QA engineer joined our team. They were responsible for manual testing. When the project was coming to an end, an SEO specialist and a dev ops also joined. The SEO expert was responsible for adding the required content and properly configuring all of the analytics tools. The dev ops owned the release — they went through a thorough pre-release checklist with over 50 items, configured the infrastructure, and deployed the codebase.

Finally, after almost half a year of development, we had our product up and running. But this wasn’t the end of the story, modern solutions are constantly evolving, so we still keep a dedicated development team on the project — they add new features and fix things if something goes wrong.

As you may have noticed, our extensive discovery phase was mainly aimed at eliminating or mitigating possible risks. We had our tech lead pick the best technologies for the project and create a PoC for the 3rd party service. We also used the extensive data that we had on our hands to provide the best possible estimates that we could. We engaged an SEO expert to cover search engines, and since we always pick the best developers, we didn't have issues with the code quality. The only thing that wasn’t important for us was data migration, but that depends on the project.

All of this may seem like an easy journey, but we had our ups and downs. Of course, we prepared a risk analysis, but you can’t be prepared for everything.

Conclusion

Congrats on making it this far! We hope this article provided useful insight into how the web development of products is done. You are now almost an expert, and you’ll definitely have more confidence when talking about the work with your team. Just remember that cases are unique, and there’s no magic pill for each and every project. You and everyone on your team will have to be flexible and properly react to new challenges that will definitely arise at various project stages. But at least you know which tools we use to tackle these and how some issues can be avoided with proper planning. Remember that having no plan is a plan to fail, and help your team bring your vision to life. At Halo Lab we are constantly improving processes and interaction, minimizing risks to achieve the best result. Let's create a great product together!