Product Management In A Nutshell
Link the needs to be met by its product, its development capacities, the feasibility and the cost of development, and sequence the development of new functionalities in such a way as to satisfy its customers while allowing it to conquer new markets. To remain competitive and to innovate, any editor asks himself how to manage the available content of his product and optimize the utility of the development according to all these parameters by reconciling long-term and short-term.
This is the whole purpose of the Product Management activity. At the crossroads between strategy, marketing, customer feedback, sales feedback, and the constraints and possibilities of R&D, Product Management is responsible for defining what must be developed and integrated to develop the product harmoniously. Based on all this data. But as much as the objective seems obvious, the way to achieve it is often complicated. In the rest of this article, we will see some ways to achieve this.
The Hierarchy Of Scales
From vision to operations, managing the content of product development activity is necessary. But it is difficult to treat a request for improvement, a bug, a request for a new module, or a technical debt reduction project similarly. Agility erected as a panacea often promises to solve this difficulty. But there is a long way from theory to reality.
Too often, during audits, we find that agile methods mechanically manage all of this more or less without the editor’s management having a hand, which can ultimately lead to a strategic failure. Faced with this trap, we suggest identifying the different levels of product planning and providing different responses at each level. We can schematically distinguish the following levels, which correspond to different time scales: vision (≈5-8 years), strategy (≈2 years), macro-iterations (≈3-4 months), and sprint (2-3 weeks).
The Level Of Vision
By vision, we mean the expression based on medium-long-term anticipation of the market and offers of ambition for the publisher’s position. It is desirable to document it. And to update it regularly (every year, for example).
The Strategic Level
To achieve the long-term objective described by the vision, you must choose a path and stages. One cannot go in too many directions simultaneously. It is, therefore, necessary to draw a path that gradually leads toward the vision. This is called strategy, a way of converging toward the vision in several stages or positions. For example, a 4-step strategy for a publisher wishing to migrate its “On-Premise” offer to the “Cloud” and faced with a rapid extension of its market to very small customers, captured by competing “cloud” offers, could be :
- Preserve the lead on the historical market and develop an additional offer on the cloud for very small customers to take a substantial market share quickly.
- Gradually migrate the functionality for small and medium customers to the cloud product and encourage small customers to migrate.
- Gradually migrate the function for large customers to the cloud product and encourage small and medium customers to migrate.
- Abandon the historic “On-Premise” product by offering commercial and technical support to large customers.
It is necessary to set up a level of Product Management, which we will call “strategic,” corresponding to this level of visibility. At this level, the functionalities are seen from very high, without details. They correspond to real market challenges. They are divided into phases (trying to constitute, for each phase, a coherent functional content capable of creating Value for customers).
Each functional block thus obtained is roughly weighed in terms of R&D efforts so that the strategic roadmap they are positioned is compatible with the planned resources. To sum up, we maintain a high-level strategic roadmap and a provisional resource plan at this level. Of course, this must be reviewed regularly, at least once a year.
The Operational Level
At the operational level, we focus on a vision of around 18 months (which may vary depending on the company and its market). We are talking about versions here; the available content is detailed while remaining easily understandable. The idea is to identify about ten themes in which we will affect the identified needs and to compose functionalities that meet these needs. The result of this activity must be a roadmap at 18 months (+ or -) with, on this roadmap, the needs met by the theme.
I insist here on the fact that the roadmap must contain not features (features) but needs to be satisfied, which makes it operational for marketing and sales. The timing on this roadmap consists of successive versions, succeeding each other approximately every 3 or 4 months (depending on the context, this may be a little different). Here, “version” means a stable and consistent product state that can be identified from a marketing point of view and therefore promoted and sold.
Each version is then developed as a “new” product, divided into sprints, and managed agilely. To plan feasible versions, the Product Manager must ask the corresponding development manager to make estimated macro-costings of the blocks to be planned and to check with him the consistency of the roadmap with the resources, even if it means reviewing the content of the roadmap in function.
Structured Into Themes
Whether at the strategic or operational level, we have seen that identifying themes is very important to reduce the number of objects on which to reflect in terms of planning (the human mind is such that it manages a table of 10 rows is better than 100). But also, by linking these themes to needs, it avoids considering the product as a set of features as the ultimate goal of development.
On the contrary, this structuring allows you to stay focused in your reflection on your needs. How many publishers have I audited who, imagining their product directly without going through this structuring of needs, only discovered at the time of sale that the functionalities developed were incomplete and ultimately brought nothing to customers? Let’s say it again. We can never repeat it enough. The satisfaction of real needs is the objective of Product development!
Need And Value
Needs must be analyzed in terms of benefits, depending on whether they benefit the purchasing customer (for example, the benefit of a tool intended for operators can be savings in inventory management), the user customer, the seller, or whatever. To make it simple and quick, I recommend that the identification of needs answer a certain number of questions, inspired by the famous 6 Ws method: for which market, for which market players, for which types of operations, who uses what if not, for what benefits, in competition with whom.
Behind this notion of benefits is that of Value. We must be interested in the Value represented by the satisfaction of a need because it is not equal to satisfying a critical need and an accessory need! And even if we must not refrain from pleasing users (see next paragraph), the bulk of R&D investment must be devoted to what will create value for customers and, thus, indirectly, add value to the product being sold.
In selling enterprise software, value-based selling methodologies are widely used. These methodologies allow salespeople to focus on customer needs, particularly those of greatest importance (or Value), where the product can bring the most Value. This Value can be measured, for example, by return on investment (ROI). Here, for example, we find some arguments favoring these methods. Need and Value are common concepts in management, sales, marketing, and product. They are excellent justices of peace for aligning the different players in the software publishing company!
Budget
Before concluding, I would like to mention a very suitable method for managing product content, in addition to what we have already discussed above budgeting the effort to devote to different needs. Indeed, as we have seen above, if a Product Manager must arbitrate between functionality that satisfies a critical need and small features making it easier to use the product, it should always be the first to win. However, a product cannot ignore non-strategic requests but also satisfy some of them regularly over the versions.
Budgeting the R & D effort as a % of the activity and following this distribution of the time spent is healthy. For example, you can devote 15% of your activity to fixing bugs, 10% to ergonomics and improving usability, 15% to technical debt, 10% to technology watch and training, and 50% to strategic product development. This, therefore, implies that a Product Manager must also break down the objectives of a release into categories: for example, strategic development, quick win features, features to help with sales, etc. By checking with the development manager(s) that the respective load estimates respect the defined percentages.
Conclusion
Through this quick overview, we hope to have given you product management methods, ideas, and ways to manage this activity better.
Also Read: Best Practices For Managing Your PKI System
