My name is Maxim, and for the last eight years I have been working in large companies as a business analyst and product owner. Today I would like to share with you my thoughts on product development, organized with the use of a large number of dev teams.
Those who are interested and willing to talk about this topic - welcome under cat.
Let's start with the big companies. By large companies, I mean companies with thousands of developers, testers, analysts, devops engineers, product owners, and other people managers. These are dozens of divisions, hundreds of teams, complex hierarchies, endless dependencies and areas of responsibility.
Getting into such a company, at first it is difficult to navigate. But time passes, and now you can quite imagine your "island". As a rule, these are:
- Some understandable system or component that is involved in a very large and complex business process;
- The product owner is a person who undoubtedly knows where to develop this system;
- A set of documentation in varying degrees of relevance;
- A suite of tests, automated and not very.
Sound familiar?
This is what a typical and not the worst software development system looks like. Usually development departments of companies with successful products come to this form in 10-15 years. Successful products bring in money, money is invested in development. Development is growing by leaps and bounds, it is scaled linearly and comes to a situation where project managers can no longer keep all the dependencies in their heads, many teams begin to pull the "blanket" over themselves, and, sometimes, harm the product rather than develop it. In such a situation, it is quite normal for one team to strive for its own success, no longer worrying that their colleagues are experiencing some problems, and their common feature will not be delivered because of this. It’s in the nature of things to develop the functionality that endless stakeholders ask the loudest, and not the one that users need.Development "on the table" is not uncommon. The process is going on - the requirements come, are implemented, tested, delivered. It is easy to hide the main thing behind a screen of hustle and bustle - product development is not nearly as effective as it used to be.
To understand this loss in efficiency, let's turn to the classics of product management. Now there are enough online schools or universities that can teach you this science for some money.
My small list if you didn't know them
So, according to the "classics", a product is what people buy. The tasks of a product manager are to find the target audience, determine the message of value, select suitable sales channels, reduce the economy, find growth points, sort out all suitable hypotheses. If necessary, change the idea, target audience, channels, message, business model, market. Or even kill the product if it is clear that it has no foreseeable prospects.
Doesn't sound like the story above, right?
The point is, when you are a small startup, all product development processes are pretty transparent and straightforward. It's very easy to spot the problem and fix it. It's easy to understand the idea of the product. It's easy to understand and develop the required functionality. Users - here they are, at hand. Prod - here it is, with all the metrics.
However, time passes, the product successfully gains market share, develops into a product line, more and more developers are hired, and before you know it, your company turns into a huge jumble of structures, interests and responsibilities.
- Custom product users? Now your product owners do not remember them, they rush from one stakeholder to another, trying to figure out which requirements to grab at first;
- Was the unit economics clear and transparent? Now the owners of the product do not even consider PnL (Profit and Loss), loading the entire team on the sprint floor with sides with dubious benefits;
- Were there a job story, customer journey map and other persons? Now the store is writing “As a product owner, I want this to be done because the Operation and Maintanence department needs it”;
- Was there an understanding of responsibility for the result and terms? Now each team is for itself, your features will be delivered to production for a release or two later.
The complexity of managing development for large-scale products is growing exponentially. What to do?
The first thing that comes to mind for top management is that we need a magic framework that will make this whole complex system work like a Swiss watch. There is demand - there is supply. I know several such frameworks that, in theory, can cope with the task at hand.
Are they a "silver bullet"?
I have gone through several business transformations in which golden coaches were hired, the most modern management and communication processes were introduced. Thousands of people changed their positions overnight and moved into a new structure, a new team, new processes, new projects.
And I can say the following:
- it is expensive;
- it's not fast;
- it is very risky;
- the ultimate success is highly dependent on the culture of the company. If people understand and believe, success is likely.
Is this approach the only correct one? Let's see what else you can do.
I believe there are other ways to scale product development. Unfortunately, I do not have step-by-step instructions for you, but here are my ideas that might help you with this:
Product . The product must add value. Consider the zoo of your systems and components in terms of value. Highlight all value streams for end customers, counterparties or third parties and divide the system map by such streams. Each product owner must have a complete chain of value systems under control. Give him a couple of analysts if the scope of responsibility is too great.
Metrics... To manage, you first need to learn how to measure. Each product owner must identify metrics for his product, on the basis of which he will conduct the development of this product.
Users . Let's put aside the stakeholders. Only users can give a correct idea of the value of a product. The product owner should be guided by the results of the interviews and the analysis of support tickets in their hypotheses.
Hypotheses . No more blind implementations of the functionality. Every epic or feature should have expectations for the impact on metrics. When implementing features and testing them with A / B tests, product owners must understand whether the hypothesis was successful or not.
Coordination... Of course, the work of multiple products needs to be coordinated according to the framework you choose. However, you shouldn't turn this coordination into a collective responsibility board of product managers.
I believe that only by maintaining the conditions described above can you successfully scale product management, and by and large it does not matter which framework you choose for this scaling.