How to structure your product development process?

Recently I’ve made a small research on how Latvian tech companies do structure their product development process. I’ve noticed that only a few of them pay attention to how exactly their product is developed.

Mostly, it is an unstructured process of impulsive decisions not only leading to financial and time loss but to customer disappointment.

As a person who is really in love with tech industry and product design I’ve decided to share my experience and view on how to develop the product.

Today I’ll make an overview of how product development should be structured in order to achieve best results and minimum loss.

Let’s start!

*Probably, there will be nothing new for high-advanced tech companies, but it might be really useful if you are a startup or tech company, who do not follow all the trends or is keen on learning something different.

1. Ideation

Who? Business team & Product team.

Everything starts with an idea. It’s time to set the direction of your product or feature. Simply free-form brainstorm. Give your feature or product an abstract shape. What could it be? How could it look like?


  • Set your mind free and write down all of your ideas, not only the good ones.
  • Tell your ideas to someone who helps to filter them. Critical view is always needed.

2. Business requirements

Who? Business team & Product team.

Collect all business requirements a feature or a product should have as its core. This is important as your mission is to impact the business — grow sales/market share or satisfy your customer needs.

Why is it very important to collect business requirements?

  1. It will help to avoid project failure that usually occurs due to misrepresented requirements leading to failure of meeting customer expectations.
  2. It will help to create positive collaboration between stakeholders by well-structured business requirement documentation.
  3. It will save your time and money.

*Note: A common format for business requirement collection is the business requirment document.

What questions should be answered:

  • How will the feature impact the brand?
  • How will the feature impact sales volume? (if it is monetization feature)
  • How will the feature impact your customer’s satisfaction?
  • Why your customers will use the feature?
  • What is the budget?
  • What is the deadline?
  • What goal business wants to achieve?
  • etc.

3. Research

Who? Product team & Development team.

Market research:

You should investigate the market, competitors and product analogs to see whether the feature is already introduced by someone else and how does it work.

What should you do?

  • Define your target audience.
  • Create a survey for potential target audience. It helps to make sure that they really need your solution and clarify in what way.
  • Collect geographical features. 
    *Maybe your solution will perform on a particular market much better, than on the other.
  • Analyze your competitors.
  • Collect overall industry data.
    *Industry growth, market shares, global problems.
  • Analogs’ research.
    *This one is very important because there might be an alternative solution provided that is better than yours.

Development research:

You need to understand how much it takes to develop your feature or product. This one is very important since the project success depends on how precise your estimation was.

What questions should be answered:

  • Do you need to build everything by yourself?
  • Are there any 3rd party solutions, which you can use?
  • Is there a way to use new technologies that will speed up your development?
  • What is the time estimated for product development?
  • What problems could potentially arise?
  • etc.

How to estimate accurately?

You need to gather developers with various backgrounds and knowledge to have an unbiased opinion. When they will provide you different estimation you should take the average and add 30% above. That will be a 90% accurate estimation for the project.

4. Prototype

Who? Product team.

Now it is time to shape your feature/product. I will not recommend to make HI-FI prototypes or to code in any way, because you don’t want to spend a lot of time on what might not be used in the future.

Create a schematic prototype that will show core functionality and value of the product for customers. Nothing else needed.

*Note: Watch this keynote from Apple's WWDC on "Iterative UI Design":

What tools to use for prototyping?

But at the very beginning, I would go for pen and paper. Once you’ve finished all your prototypes it is time to receive real customer feedback.

5. User research

Who? Product team.

As a business you should understand clearly that people will use your new feature and it will be worth your time+money investment.

You can either go and catch potential customers on the streets or invite your existing customers to watch their reaction on new feature, or you can use one of the user testing tools that will save your time.

There are two types of user research and you should do both:


This type of research takes big group of users to get an answers to following questions “how many people clicked here?” or “what percentage of users is able to find call to action?”, etc.


Qualitative research takes the form of interviews or focus groups with few users. It will help to understand why people do the things they do. It will answer the following questions “why people haven’t noticed call to action?” and “what else people have noticed on the page?”, etc.

*Note: Here you can read more on the user research and testing:

What tools can you use for user research?

And here is the full list of the tools that you can use for user testing purpose.

6. Technical requirements

Who? A person with technical writing skills.

After you’ve checked your hypothesis with real customers, collected all the data and understood how your product/feature will look like, it is time to bring it to life.

Many companies experience big problems with technical requirements.

Why? Software development is a very complex process, that’s why you need to give a very precise and accurate translation of a product and business requirement into a doable task that will lead to a correct result.


  • Use Zeplin for all the visual requirements. Very powerful and “easy to use” tool.
  • A well-known fact, but still. Break tasks into a smallest possible pieces. It will speed up the development process.
  • Make sure that before starting the development everything was checked 100 times and is correct and understandable.

7. Release planning

Who? Product team & Marketing team

When product development is in progress, it’s perfect moment to think of how to introduce this feature/product to the world.

There are two common ways to release the product:

  1. Gradual release: Partial release to a small group of users/ customers in the particular geo, to safely test feature assumptions.
  2. Immediate release: When you release the feature for all of your customers and geos.

I am a big fan of the gradual release, because it’s safer, but it totally depends on the size of the feature or the product. If you are releasing minor feature, that will only affect small part of users there is no point in gradual release at all.

What questions should be answered:

  • When and what time will you launch?
  • Where will you launch?
  • Will you give an access to all the customers or to a small group?
  • What is the PLAN B?
  • What is the marketing strategy?
  • What is the KPIs?
  • etc.

8. QA

Who? QA team, Development team & Product team.

After you have finished the development you need to make sure that the result is good and will not disappoint your users with bugs and unfulfilled promises.

I would recommend product team to have an active participation in the QA process to check the software and be sure that everything is made according to the business and product requirements.

*Note: Nowadays it is popular to have an in-house QA team, but I believe that there is no need until you are a huge company, that is why I recommend to use an outsource QA service. Try to use — TestDevLab.

9. Release + analytics

Who? Product team & Business analyst.

Finally, you have released your feature/product and now you are ready to see the results. It’s time to collect quantitative data.

What should you do?

  • Real-time activity monitoring.

Basically, every business metric that is affected by your feature/product should be measured and presented in statistics form. During the first day of release it is very important to keep an eye on how it goes.

You can use Grafana or Kibana ( if you are using ElasticSearch ) in order to track your business activities. Both tools are free and very customizable. But if you are ok with more high-level data, use Google Analytics.

  • Feature retention.

Besides knowing how the feature is affecting your business activity you should be aware of how much your customer likes it. Feature retention will help you to understand that. In short, it will tell you how regularly and for what amount of time customer is using it during certain period of time — 1, 2, 7, 14, 21 day from the feature release.

10. User feedback

Who? Product team & Support team.

When the feature is released and you have first quantitative results, it’s time to see what your customers really think. Qualitative data.

What should you do?

  • Go and check your support email/chat.
  • Talk with users in the social media and ask them how they feel about new feature.