Whatever framework the product team works on, in the end it works for the market. Signals from the market can come directly from the results of measurements of key metrics. Signals can come indirectly: from marketers and analysts. Signals can come in a roundabout way, from the head of a product manager or stakeholders, from their ideas about what will be in demand tomorrow. Be that as it may, the product team is engaged in creating an adequate response to the challenges of the market.
These signals can be contradictory: the market itself is very dynamic and constantly changing, and subjective ideas about what will happen to the market tomorrow change radically almost every day. Therefore, in the product approach, it is impossible to fix anything “on the shore”. Moreover, it is often necessary to keep stakeholders from throwing in too many conflicting tasks, breaking down work into fixed iterations, not accepting new tasks before the ones already set are completed.
At the same time, the iterations themselves cannot be long: the result is needed as soon as possible. The faster the “thrown” idea is implemented and released to the market, the sooner it will be clear whether it is worth developing it further, or whether another one should be taken. Therefore, the iterations themselves usually range from one week to one month, and most often teams choose a “golden mean” of two weeks.
At the same time, at the end of EACH iteration, the command produces a working result. Something that can be felt, let customers feel, put on the network, advertise, see the pros and cons, adjust further development. Well, at least flexible approaches declare that the result will be ready after each iteration. Reality, sometimes, makes its own adjustments.
As for the timing, cost and functionality, they often fix only the timing. The timing of the release of a new version of the product, a new feature, or the MVP of a new product. The fact is that the timing can be tied to the requirements of the outside world – advertising campaigns, seasonal fluctuations, exhibitions, etc.
At the same time, budgets are tied to the cost of the development team per unit of time and the implementation period. The longer the team works, the more budget it “eats”.
The functionality is often fixed or very weak – a new product may have a key killer feature, for example. Or it is not fixed at all and is adjusted in the course of work on the product.
Product system specifics
It is clear that to ensure such work, the product team must be organized in a specific way, as well as the processes of its work.
First, the cycle “collection of requirements – formalization – development – testing – implementation” is compressed to the limits of one or two iterations. Often, while the team is implementing the previous requirements, the product owner (or product manager, depending on the framework and situation) is figuring out, prioritizing, and refining the requirements for the next iteration. So that previously formalized requirements are not lost, everything is added to the so-called backlog, strictly sorted by priorities. At the end of the iteration, the team simply takes the highest priority backlog items – as much as they can fit – and proceeds to implement them. If at the same time it turns out that fresh requirements are less priority than those already existing in the backlog, then older, but more important ones will be implemented. In fact, the “freshness” of requirements does not play any role here: only priority matters. At the same time, the requirements may well become outdated, which will reduce their value to the business and, in turn, reduce the priority for implementation.
We will not dwell on how these priorities are built – this is a separate big topic. We only note that it is the value for business that plays a very important role.
Secondly, the team already, in fact, cannot and should not start tasks in stages. They took one element into work – they implemented it, they took the next one – they implemented it. We came to the end of the iteration – rolled out an increment, that is, a working result. Went to plan the next iteration.
Inevitably, the roles within the team are smoothed out, they cease to be as brightly highlighted as in the project approach. A developer can in one day write the server code, and the code of the front, and make up, and test. Splitting already small tasks into separate blocks and distributing them to people with different competencies becomes too expensive. Therefore, the requirements are sharply increasing not for specialization, but for the cross-functionality of team members, the value of full-stack developers is growing.
At the same time, implementation can be – and often is – carried out in parallel with development. This can be done either by the same development team, or by the implementation and support team, working at its own pace.