What is a Process in Product Development?
The simple answer — it is any activity or set of activities that we apply to solve a particular problem. And all these activities must be described and regulated.
Let’s take a look at the example.
In a daily-scrum, everyone briefly describes what s/he did yesterday and what s/he will do today. This seems to be a mundane task, but that is literally the process: it was created by one of the managers or team leads, its rules were specified, regulated, and everyone follow them.
Other examples:
1. The process of recruitment.
2. The process of agreeing on treaties.
3. The procurement process.
4. The process of supplying the company with goods and services.
5. The process of customer handling potential.
Things don’t always go as planned and it isn’t always possible to see the true reason for non-compliance. But it is exactly the ability to process gaps, analyze them and correctly build a strategy to correct them will help to achieve good results in product management.
A process is a separate product you are working on
How to set up a process?
It’s worth starting with the problematic. What problem do we want to solve? Not everything is what it appears on the surface.
For example, you have too many code review tasks remain daily. You are constantly pushing your developers to plan their time and carry out tasks faster, but it it’s not working. Several reasons come your head at once:
• developers don’t devote enough time to review;
• developers don’t have time to do a review;
• the quality of tasks is too low and there is a large percentage of defects among them, so a review takes a long time.
Quite often, we assess the situation superficially and make a decision based only on our assumptions. In our case, it may be said that the solution is obvious — you only need to push the guys even more often to remind them of deadlines. Most likely, such actions either won’t bring results, or will be short-term. Temporary solutions will one day “shoot you in the knee” if you don’t approach them correctly.
Let’s tackle the situation from different angles. There is an identified problem — a lack of code reviews acts as a brake on aid projects.
The next question, which will identify follow-up activities: “How should it work at all now? How and why did it work before?” Perhaps developers are simply acting out of sync, because of the lack of standarts. So we identified one of the actions to be taken in fixing the process — to create a guide to code review.
Let’s assume we already have it.
Then it’s quite logical to read it and check its relevance, and if it is followed. If any of this is not revealed, this is again another item for future improvements.
Working out options for solving the problem
So, we have a guide that is updated regularly. All the developers are aware of it and trying to comply with it. Now what? We go back to the beginning and look at other possible causes and work out hypotheses. Sooner or later, you will find the root cause.
We defined the problem, worked out hypotheses and even understood the root cause. Now you need to identify who are the consumers of this product (that is — the problem). In other words, we identify our target audience. It is important to take into account all the stakeholders, because each cohort needs its own solution — the same approach is used with B2B and B2C products.
Do your research and learn about similar cases from your colleagues: see what problems other teams faced and how they solved them.
When the solution begins to more or less emerge, it’s time to perform an A/B test of the specific process.
Discuss your hypotheses with key people: what actions they think you should take. Don’t skip this step, since self-analysis often limits your, and experienced people are able to share their thoughts and help share responsibility for solving the problem.
We found a solution — what’s next?
Well, this is a simple matter. Then we work out a solution, agree on a new process, document and deliver it. The process delivery and the product delivery are quite the same: testing, getting feedback, watching the results.
Don’t forget to implement the process as well. You did a great job, found the problem, thought over the solution and eliminated it, didn’t you?
To make sure the problem has been solved successfully, you need to make all participants be aware of changes. Therefore, don’t ignore the final step — to present the changed process to the team.
So it’s time to sum up
Process changing should be approached in the same way as any product changing. For successful implementation, you need to go through exactly the same steps: creating a BRD, identifying a problem, working out a solution, analytics and decomposition, delivery and post-support.
Processes are an integral part of the work. They improve the quality and efficiency of the team activity. Fixing the processes is long and difficult, but it is clearly worth it. If you decide to tackle this, do it in a comprehensive manner. Otherwise, at best, you simply won’t see the result, and at worst, it will be negative.
By the way, it’s time to follow my Telegram Channel: https://t.me/productmonkey
