THE METHOD

Steps in the method are as follows:

Choosing the KPI to improve based on the business model of the start-up and the stage the start-up is at. The major differences in the KPIs based on these two criterions can be found in the 1.8. sub-chapter. There are also the most often used sets of metrics already proposed. These can be tailored for each individual case using segmentation and other techniques to look at more specific sets of data. When trying to understand the stage the start-up is at, can use the goals or gateways for each of the stage as an indicator – first stage, which goal the start-up have not reached will be the stage it is at.
Setting the goal value for the chosen KPI. The start-up for each KPI most probably will have to go through several cycles and the value can change after each of the cycle if it is clear that the goal value was not realistic or on the contrary – will not bring the desired effect and a higher value is needed. In some cases the goal value will even change during the cycle if these conclusions are clear sooner than after implementing the changes and measuring the results.
When the KPI goal value is clear then starts the requirements elicitation (E1) and trying to find the changes that could bring the start-up to the desired value. A set of requirements elicitation techniques for this step are proposed in the 2.5. sub-chapter, but it might be that the solutions are already found and in the backlog, so the first step at this step would be to check the product backlog for the solution if the team do not know what exactly they have in the backlog.
Together with the previous step starts also requirements management (M1), which is a bigger phase and is happening throughout the elicitation, analysis, specification, prioritisation, validation phases and continues after learning step and second requirements elicitation phase. Some of requirements management techniques are proposed in later sub-chapters, but this was not the focus of the work and there is not an elaborate list of these techniques as in most cases they will not change throughout the start-up stages.
Together with the previous 2 steps starts also requirements validation (V1) and continues throughout elicitation, analysis and specification phases as this is a continuous process. Requirements validation is an important step for start-ups as the resources are limited for these organizations and it is important that they perform extremely efficient and do not build requirements, which does not bring needed value, and therefor waste precious resources. Quite an elaborate list of requirements validation techniques will be proposed and, as the validation happens throughout also other phases, a big part of these techniques can be used also for those.
After requirements elicitation comes specification (S1). At first the requirements are specified as simple as possible but then after analysis and prioritization, if needed the team can come back to this step and use more elaborate specification techniques. However, in the earlier stage start-ups more sense will make to elaborate the specifications during the building and implementation steps as no resources are wasted over-specifying the requirements.
Next step is requirements analysis (A1), for which a comprehensive list of techniques is proposed as well, but as this phase is very closely connected with elicitation, specification and validation, then these techniques in most cases will be more broadly usable and will apply also for those phases. The goal here is to make sure that the requirements are clear, understandable and complete.
Requirements prioritisation (P1), which is always tricky part in the start-ups comes next. Very often start-ups prioritise subjectively on the spot based on one person’s opinion and can be reprioritized during the building phase also quite a bit. That is partly also one of the reasons why this phase is a separate step and divided from the requirements management phase. Choosing one KPI and proposing a list of prioritisation methods for each stage should take care of that problem and make the prioritisation more clear and systematic.
Last step before building and implementing the changes is second round of requirements validation (V2), because as mentioned before this is an important phase for start-ups. In one cycle the start-up can go back and forth between different requirement engineering phases. In this step the same validation techniques can be used as in the step V1.
After validation, the start-up should choose the data mining technique and maybe even set goal values for several or all requirements, which are chosen to be built during this cycle. A list of data mining techniques is proposed in the first chapter as well as the process for data mining. We also explained the difference between supervised and unsupervised data mining and in this case most often supervised data mining techniques will be appropriate as most often we will know the goal and the goal value for the data mining.
Building and implementing the changes.
After building the start-up should measure the effect of the changes on the KPI. In most cases that will be the last validation (V3) phase for the implemented requirements and if the requirements do not bring the supposed value or even harms the start-up, the changes can be rolled back in one of the next steps. No validation techniques are proposed in this step as the validation in this step will come from the datasets.
After comes lessons learned and this can be also the second elicitation step (E2) as from those lessons, some new requirements most probably will be elicited. Also here now techniques are needed as this will be more or less automatic.
After that the cycle is almost over and it is time to make the decision whether to proceed with the next iteration.
1. If the goal KPI value is reached, the cycle is over and the team needs to understand if they have reached the goal of the stage and can they move to the next stage or choose a different KPI and proceed in this stage. In some cases although the value will be reached, the start-up might proceed to some of the previous stages as well, because of the lessons learned at the previous step.
2. If the goal KPI value is not reached, the start-up can proceed with another iteration with the same KPI and goal value or go to some of the previous Lean Analytics stages or get feedback from the customers and choose to change the goal value for the KPI or choose even a different KPI. This customer feedback sometimes will be also as the third elicitation step within the cycle. In more extreme cases the lessons learned can lead the start-up also to giving up or doing a pivot towards a different product or business model.
After that the start-up can start the next iteration in the cycle.

As can be seen in the picture requirements elicitation and requirements validation can be found in 3 places in this method, but a specific list of techniques will be in the steps E1, V1 and V2, because in the rest the validation or elicitation will be as a result or as a side product if that step.

Explore the stages:

THE METHOD

Steps in the method are as follows:

Building and implementing the changes.

After comes lessons learned and this can be also the second elicitation step (E2) as from those lessons, some new requirements most probably will be elicited. Also here now techniques are needed as this will be more or less automatic.

After that the cycle is almost over and it is time to make the decision whether to proceed with the next iteration.

After that the start-up can start the next iteration in the cycle.

As can be seen in the picture requirements elicitation and requirements validation can be found in 3 places in this method, but a specific list of techniques will be in the steps E1, V1 and V2, because in the rest the validation or elicitation will be as a result or as a side product if that step.

​

​

Explore the stages: