Forem: Galina Mitricheva

Feature devaluation: issue tracker case

Galina Mitricheva — Fri, 06 May 2022 06:46:59 +0000

This is a story about an internal product for corporate usage — as opposed to free market customer product. This is a story about an issue tracker, much like your favorite Jira, Trello etc, a product for tracking tickets.

We know that a tracker is there not only to write into it, but also to read from it, as a convenient instrument for asynchronous info distribution aka notification. You write an update in your ticket, and everybody can access your comment, take it into consideration or answer the question if there is any.

In order to not constantly monitor all the tickets you’re interested in, you can subscribe to notifications and receive an update every time there’s something new. By default the author of the ticket, the assignee and all those added to watch the ticket are considered interested and subscribed to notifications.

That’s where the problem begins. We’re all so busy these days, so busy that our inboxes are bursting with new emails as well as our messengers are bursting with new personal messages and chats. So some people admit: ‘I cannot read through all the tracker notifications, I filter them all into a separate folder and sometimes try to read but rarely succeed, so I don’t know what’s going on — I’ll ask’

Acknowledging this problem, the product decides to introduce a new feature: you can now ‘call’ a specific persons or persons to a specific comment in your ticket to let them know that this exact comment requires their attention and involvement. Notifications about these ‘calls’ are not filtered out by the basic rule. Okay, so now we have two types of comments: ‘ones I was called to’ and ‘ones I wasn’t called to = ones I have all the right to ignore’.

Time passes by, the busiest people declare publicly: ‘I ignore all the comments but those I am called to’.

Some more time passes by, new people join the company — they’ve never seen what it was like before, and what they see now is ‘people don’t know about comments they were not called to’. For them it’s not two types of comments, they consider comments without calls as something written straight to dev/null.

What do we have now? Every comment now calls somebody, even if it’s a comment like ‘thank you’. As an oldfag I feel overwhelmed and irritated every time, because it’s like somebody came up to me, said ‘hello’ and after I turned to them to start a conversation they instead start to shake me to attract my attention — like not even suspecting that I am already paying attention. If I am watching the ticket, I read all the comments and notifications, and what’s the use to additionally call me to do that?

But that’s the new reality: a feature intended for a high-priority notifications became the new normal level of priority, and the previously normal level is now considered nothing. It’s been devalued.

Why I found it necessary to point out that our product is a corporate instrument? I think that in their non-working life people are already good at unsubscribing, muting, banning and otherwise switching off annoying notifications of all kinds. While at work one cannot publicly say ‘I’m not interested in my tasks’ and unsubscribe (although somehow saying ‘I don’t have enought time to read my tasks’ is legal). So the product tries to find workarounds and will have to indefinitely raise the priority, thus devaluating all the previous way to do things.

All that instead of some self-discipline and sinserity. Pity.

How close should a PM be to the development process?

Galina Mitricheva — Sat, 23 Apr 2022 08:45:24 +0000

Long, long ago there were times when product managers were only thinking about ‘what’ and left the ‘how’ to project managers and tech leads. Well, in some companies a separate role of project manager still exists, but it won’t be too wrong to assume that project management and some part of technical management merged with product management.

What I mean here by ‘project management’ is mostly the responsibility of controlling milestones and deadlines. Ther are other tasks within this role, but now I won’t talk about them.
Old-fashioned product managers introduced a new product idea along with design to the development team and retreated to think about some more new ideas, while the team was struggling to deliver in time. The responsibility of controlling the milestones belonged to the project manager, or sometimes engineering manager, or sometimes technical team lead. But can all these people say that what’s been done by the deadline is exactly what needed to be done? I’d say not, as their main goal is to implement the specs, and they have no previous context, history of research, knowledge of the idea’s evolution.

So, a modern-day PM — are they allowed to shun from close-to-the-ground processes and artifacts in order to stay good PM?
Let’s look at it from this point of view: let’s say the team is coming close to the launch deadline, their product is ready as close to the specs as was possible, but it turns out exactly NOT the product intended from the very beginning. Whose fault is it?
PM’s, of course. Our job is not just to present the idea and leave all the rest to engineers. Part of our job is to keep close to the team and look at every smallest deliverable, be it somewhere at the developer’s stand or testing environment. Part of our job is to validate the result — at the earliest possible moment, and make sure the material result (app, web site, whatever) really is what we want to have.

As I put it: if I wasn’t understood right (by my own opinion), it’s my fault, not the fault of those who tried to decipher what I was trying to tell them. It is my responsibility to control every step — not to demand how the steps are to be made, but to make sure we’re moving in the right direction.

So yes. I say the PM has to be as close to the development process as possible in the environment. Not to sit on top of the engineers’ heads but to help, correct and elaborate what hasn’t been expressed right previously.

Oh, and yes, some product details have to changed right in the process of development, don’t they? Because of the framework limitations, newly discovered discrepancies in the design etc. So stay close. I do.

Want to find flaws in your design? Start writing support docs for the product

Galina Mitricheva — Wed, 20 Apr 2022 06:11:35 +0000

Every new product design seems perfect, while it’s still in the head of it’s author. Everything is clear, consistent and evident.
Even the stage of composing sponsor pitches and marketing content — dedicated to describing the overall idea and why it is good — does not help much to think about the downsides and possible bottlenecks.

Without investing much resources into development and testing you can discover the majority of corner cases and difficult questions by simply writing texts and scripts for the support team or site pages.

Doing this, you’ll have to other way but to think through every single step of the user scenarios, describe every single interface element and what it does, come up with solutions for every possible problem a user might encounter.

Well, alright, that depends on your imagination — whether you’ll find the most intricate ways to break the standard scenario. But at least you’ll start breaking the idea into detailed descriptions and facing possible obstacles.

A useful trick here will be the question ‘What if I can’t do that?’. Take your standard persona and user scenario and describe the ideal session with your app, service or site. Make your description detailed enough, down to the actions like ‘I click the app icon on my iPhone home screen’ or ‘I log in’ or ‘I fill in my card number and CVV’. And for every step of this description ask yourself two questions:

how did I get here? This question is relevant to all entry points for you to remember about app distribution, installation processes etc
what if I can’t do that? What if I can’t log in? Is the signup/signin process simple enough? What if I can’t fill in my card number because I don’t have it with me? What if I can’t proceed with hailing a taxi because my GPS is faulty and the service can’t determine my position? What if I can’t send the confirmation code because my network is suddenly down?

You really don’t have to answer all these questions right there in the support docs (although you maybe should?), but they will help you plan backups, workarounds, discover bottlenecks and potential blockers. Useful stuff, isn’t it? And just this simple.

Internal products are a dead end for product managers?

Galina Mitricheva — Wed, 20 Apr 2022 06:08:32 +0000

There are huge companies in the world. Lots of employees, lots of specific software for internal use only. Do the product managers of such internal products and services gain product management experience, valuable enough for them to later successfully find jobs in the outer world?

Key issues with internal products are as follows:

product people have lots of contact with their users, but their users in most cases do not have free choice between competing products on the market — they are bound to use the company-wide product (usually just one, be it internally created or bought/contracted). Not much market analysis in day-to-day work internal products’ users do not directly pay for sessions or licenses. Mature businesses can somehow assess the ‘cost’ or ‘revenue’ of usage, but product metrics are usually not measured in money units. That creates lack of experience with GMV, revenue, profit and other money-oriented areas, very important for independent products in the wild
some (if not all) products may be fully or partly a commercial know-how under an NDA agreement, so the product manager cannot even talk freely about them at interviews
even if not NDA-covered, internal products and their context are not widely known to potential employers, so it’s difficult even to describe what you did and what was the goal and how success was measured

So, managers of internal products — are they a good potential hire or hopelessly stuck with their current company and it’s choices? Well, that’s a decision for HR and hiring managers to make, but if you are in this position, here’s what you can do to help yourself go un-stuck.

At interviews, when speaking about your products, try to use analogies. Most likely there are commercial products doing the samw thing as your product does.

The same analogies will help you out if your product details are under NDA. You will have to constantly comment on the differences, but otherwise that’s a good way out.

Engage in public events, so that your name gets somehow known, if not the name of your product. Reputation helps to cover blank spots without details.

Try to broaden your experience theoretically if not practically. Join ProductHunt or maybe start your own product analysis of different public solutions and platforms. You can practice the skills not needed for your job as a hobby and present that for interviewers if needed.

The most difficult issue to cover is hands-on experience with live money: you cannot play with unit economics theoretically so that it would produce some experience close enough to reality. Well, if you don’t have a pet product in wild market to play with, then read a lot about money product skills and wait for a chance to apply them. Nothing else to do? Or is there?

How to balance external feature requests with internal product development plan

Galina Mitricheva — Wed, 20 Apr 2022 06:06:35 +0000

When we have a product, and the product has it’s users, and users are engaged — they usually give feedback in form of bug reports and feature requests. There may be other forms of feedback, like comparisons, overviews, discussions etc, but as (if) they don’t add new tasks to your backlog we can ignore them for now.

With bug reports things are quite simple:

check if it’s really a bug and can be reproduced
assess it’s severity in terms of broken users scenarios
assess it’s priority in terms of how many users are affected and how important are these users for you
check if the fix won’t make things universally worse (some minor bugs are better left untouched, when there is no evidently good way to fix them without big changes in all product)

There you are, include the bug into your backlog easily comparable with other bugs. There is no need to argue that bugs are to be fixed, right?

With new features it’s not that easy. If we look at the popular RICE framework, for example, we use Reach, Effort, Impact, Confidence assessments as the base for comparison.

The formula looks like this: (Reach x Impact x Confidendce) / Effort = RICE score.

This framework usually need adjustment to use in real work environment, for instance, it does not include the dependability factor (when your low-RICE feature blocks some other high-priority feature or product part), scheduling (when postponing the feature makes it completely useless, like Christmas specials or such), available workforce (you may not have enough engineers at hand just at the moment) and more. So RICE is just a helping tool, but not a plan-composer.

I would suggest also adding into such frameworks’ formulas an additional factor of ‘source weight’. The feature request may come from:

a prospect with huge contract (noticeable potential revenue but low reach and impact for the majority of other users) an ‘influencer’ able to open some new market niche for the product paying audience (not that big part of the overall user base but ready to pay for the new feature)
investor/stakeholder/manager whose benevolence is important for the future of the team and product itself

These are not as easy to measure in money or people or some other quantifiable unit, so we can adopt the same scale as with ‘Impact’ from RICE formula: Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.

The ‘Source weight’, or we can also name it ‘Opportunity’, coefficient should be applied to the RICE score and will help to balance external feature requests with your own product plans, giving some more weight to incoming ideas. Your own ideas will have Medium source weight, so if you are (like me) inclined to prioritize your own view over infrequent external opinions (after all, who’s the product manager, responsible for strategy and familiar with every detail of product status and plans?), the new coefficient might help to think twice and not miss something useful.

But again, all these scoring techniques only help to compare what’s comparable. Final decisions are always yours.

Why developers should review designs

Galina Mitricheva — Wed, 20 Apr 2022 05:58:26 +0000

We all know about a widespread practice of code review between developers. Are there any companies left without it? Guess not; evidently that’s a must-have.

Most design teams I worked with also have a similar design review practice: before presenting the new UI design to me (the manager) they either must undergo art director/head designer’s review or present and discuss it with the whole design team or group. Or both: public discussion and art director’s review.

Also frequently developer teams show their implemented interfaces to designers before releasing the code to production for last-minute corrections.

What I found very useful is to ask developers to review the designs before those are considered final and moved to development. So the cycle gets complete:

designers review other designers before completing the design stage
(this is the new stage) developers review the designs before beginning implementation
developers review other developers’ code before shipping/merging designers review the new UI (not the code, obviously) before release

Developers’ review of the design will help to ask important questions before investing any resources in code:

is this design at all possible to implement? Discuss the existing legacy, frameworks’ limitations, availability of data designed to fill the interfaces, potential trade-offs like high load, whether other components of the system are compatible with the future features
where may the difficulties appear? Discuss corner cases and how to work with them. This is the moment to check for ‘no network’, ‘download error’, ‘empty list’ screens and the like: progress bars, synchronous or asynchronous page loading, additional prompts how does the new design fit the product? Maybe something similar is already being resolved by other means
what are the success metrics and how exactly the data will be gathered and analyzed? It is also important to discuss at the very beginning as sometimes simple metrics are not so simple to count

As you can see from the list of questions, in fact such review meeting is not just for developers to attend: it requires the whole product team, including QA, product management, DevOps, analytics, copywriters, marketing staff and whoever else will be involved. Full attendance will allow the team to prepare for their part of implementation process beforehand and thus save precious time to market.

I wouldn’t advise to combine this review meeting with the project presentation (where I as the manager present the new product/feature to the team, describe the goals and plans and show mockups/designs), as people usually need some time to look and think before coming up with ideas and doubts. Bot both these meetings (or conferences, or mail threads, or however team communications work in your environment) are the right place to ask questions and share insights.

The main idea here is: the earlier everybody sees what’s ahead, the better they will be prepared.

What’s ‘technical’ in Technical Product Management

Galina Mitricheva — Wed, 20 Apr 2022 05:54:35 +0000

I am currently working as a Technical Product Manager in a huge innovative IT company, and I asked myself: what’s the difference between technical and non-technical product management?

Let’s ask Google who’s a technical product manager. We’ll see quite similar definitions that say: that’s the same product manager but with advanced engineering skills, good technical background, with more focus on technical side of the product and communicating more with technical part of the team (developers mostly). See HubSpot, CareerExplorer, ProductPlan.

So ‘technical’ in fact means an additional set of skills for an ‘ordinary’ product manager. No ‘technicality’ can atone for lack of basic product management skills: data analysis, market analysis, customer research, product growth strategy etc.
If so, how important are these additional skills and why employers look much more frequently for ‘ordinary’ product managers than technical ones? For example, right now I did a quick search on LinkedIn vacancies: 36739 results for ‘product manager’ and 5128 for ‘technical product manager’.

Given that not every employer means the same by this position title, either they don’t see additional value in technical skills or these skills are indeed unnecessarily extra.

Who are technical managers here in Yandex? Technical product managers here are responsible for complicated products for developers: database management, cloud services, distributed computing, resource management tools, you name it. Key detail here is that our products’ users are not just everybody on the street: our users are developers and analytics, so in order to understand the demand and communicate effectively with them, product managers themselves must be on a close level of technical proficiency.

We don’t write production code, but we have to know how it is written, what patterns and technologies exist, what are the basic scenarios and requirements. Managers are not high-level abstract order-issuing entities: we work closely with the team, we contribute to technical design decisions, we communicate details to multiple stakeholders and partner services — who are again all developer-oriented.

Why would a company need a technical product manager instead of an ‘ordinary’ one? If it’s a product for common people, like fintech, ride hailing, deliveries and subscriptions of any kind? I’d say that with similar product skills a technical manager will be more efficient in team communications, product design, will understand in detail not only ‘what it does and why’ but also ‘how it works’. In my opinion that’s important, but then I am not an employer =)

Does the market know better or does it just not realize potential usefulness of technical background in product managers?

Social impact and Product reaction to unrelated events: part 2

Galina Mitricheva — Wed, 20 Apr 2022 05:52:38 +0000

Now to the more recent events. Everybody knows about the war in Ukraine. Unacceptable, unbelievable outrage, that will definitely take a special pace in history books. Also in history books of business and product approach.

It is not the first case, by the way. We all remember World War II, whence several businesses still carry an imprint on their reputation: Siemens, Hugo Boss, Mayer, BMW, Audi, Volkswagen etc.
These days the only type of reaction to the war we see is suspension of operations. I’m not talking about government-issued sanctions and restrictions, I’m only talking about voluntary business decisions. The alternatives are obvious: loss of revenue vs loss of reputation.

What’s interesting for me here: some offline businesses, mainly pharmaceutical manufacturers, admit the fact that their production is important enough (for customers) to keep the importing operations, though maybe with limited assortment of drugs. Most online businesses, therefore, admit their services are not that important for customers?

There is also an interesting case of Mastercard and Visa (joined later by JCB), who voluntarily stopped their service for russian-issued cards, and that was not about reputation loss. In my opinion their services are somewhere at the life-supporting level of drugs, but their market penetration (or rather life penetration) allows them to regard and use their product as a mighty war weapon.

Now back to the subject. As product managers we have to answer some questions:

does the product have an impact significant enough to actually harm it’s users in some situations: by recalling licences and accesses or by continuing the operations? Is it acceptable to use the product (or loss of it) as a weapon of war or blackmail? what are the metrics to set as goal here; how to calculate the reputation loss and compare it with market share loss?
is there a way to pivot in order to help — help in what way can be seen best?

I’m surprised that no online product chose an active role. No product embedded, for example, additional commission rates for russians; nobody demanded obligatory charity donations along with regular payments (like donate to supporters of Ukraine while you pay for your Netflix account). The only way to reprimand russians is to deny them service at all?

What I did notice:

airbnb launched a separate free accomodation category for refugees
Google created a new attribute in business profiles for hotels to let people know whether they have refugee accomodation options Google also created a new Air Strike Alert app for Android users and concentrates on information reliability analysis
of course, a lot of charities and volunteers joined the movement of helping refugees, but it’s their core business and there’s no product change here

What would I have done as a product manager, if I were in a position to act? I would choose to act, not simply retract from a spoiled area. Every crisis is an opportunity for growth, they say. Not only for those who are in crisis, but also for those who are able to help.

Lose revenue or reputation? No. Gain both revenue and reputation: earn more and share extra money with the injured party. Am I too naive?

Let’s make it an excercise in product vision: how to utilize such an unfortunate opportunity to make your product stronger? I’ll take a look at the products I use daily and suggest what could be changed or expanded in order to save reputation, help ukrainians and keep russian customers. The most obvious way is to raise the prices for russians, but I’ll try to come up with more ideas.

as a runner I use Garmin watch and Garmin Connect to track my runs. I already bought the watch, and the app and web site are free; but they could close the service (or parts of it) under subscription payment or promote charity payments to dedicated funds; they have regular ‘challenges’ with preset distance — new ones could be created, again with charity goals or wider communication of information about war and it’s victims. They could sponsor ukrainian runners, pay for their registration to future runs out of these funds etc. Same goes for Strava, who just closed the access to their app/site for users in Russia (based on their geoposition)
booking left russian market. I would design a new feature: pay for accommodation for other people (not necessarily ukrainians, it could work always for any people in need of accomodation). Let a user set some fixed commission, added to their own reservations, that would go to pay for somebody else’s accommodation. Or maybe let them make an ‘accommodation sospeso’ (after caffee sospeso): pay for a day or several in a predefined hostel for the first refugee to come and ask
the same ‘sospeso’ idea works for any kind of retail: clothes, drugs, furniture, hygiene stuff, pet food, fuel, electronics, even arts. Of course, the stuff will not be ‘suspended’ exactly where paid for, it will have to be transported to the regions in distress
grocery delivery services. Their core function is effective distribution of the tasks between contractors. So they could pivot to distributing the tasks between volunteers: tasks from people in distress, needing some delivery or help at home or hospital, or organizations needing people to help rebuild or reconstruct homes and utilities, or funds and communities needing volunteers to help in hospices, hospitals, schools, zoos, animal shelters etc
GitHub and other CVSs. GitHub withdrew all the licenses and refuses to prolong contracts. What it could do: make all code contributors licence their code as free to use in Ukraine (or by ukrainian developers). It will then become a choice for customers: share their code and product with the injured party or leave the platform. This feature needs exhaustive research about how to control who uses whose code, but that can be done and controlled with enough precision
Slack recalled some commercial licenses (I’m nor sure by which principle). I would simply degrade the commercial users to a free license with a very limited assortment of features and block the possibility to buy a full one, or demand additional payment to prechosen charity funds helping Ukraine
Cargo services (never used one on commercial scale, but anyway). Maersk and others just suspended their deliveries. They could for example demand that a fixed part of any kind of cargo goes to Ukraine regardless of where it was intended for. Or they could demand an additional payment along with an ordinary contract payment for deliveries to Ukraine
Bank and money services. Well, they only operate the money, so only money can be affected: raise the commissions for everything but charity donations
e-learning platforms. Add an additional course ‘How to detect and resist propaganda’, make it obligatory for russian users Any ideas to add to my list?

Wasted lives cannot be remedied by money or any kind of business opportunity. But I do strongly believe that simple retraction may be the easiest, but not the best way to react.

Social impact and Product reaction to unrelated events: part 1

Galina Mitricheva — Wed, 20 Apr 2022 05:45:39 +0000

This text is not some ground truth by me or even my firm opinion; rather I’m using this opportunity to reflect on the odds and possibilities.

In my not so long life among IT products I closely encountered two events that affected greatly the products they were not directly related to.

Let’s start with the first one: disasters and state mournings. This story is more about risk management, though the risk there was highly improbable. So, I was working in Yandex Ether — a video broadcasting service that also had its own content production. The service no longer exists now, so I can’t provide any links and you’ll have to simply believe my story.

We had our own exclusive New Year show with jokes, songs and other kinds of simple and light entertainment to accompany celebration. It’s also important to know that my country has 11 time zones, so technically we had 11 overlapping shows starting one after another with 1 hour delay.

All went well until on 31st of December around lunch time we heard the news about a big explosion in one of the eastern cities, right in an apartment building, where people died, some survived but became homeless. A big tragedy. Country-wide news (heated by terrorist act suspicions, you know our era). Talks about state mourning (if announced, all entertainment programs must be cancelled). The risk I, as a manager of this broadcast, had never anticipated and planned for.

So what we had at the moment:

the show had already started in some regions by the moment we heard the news
the show’s script appeared to contain a joke about an explosion (OUCH)
we might have to switch the previously received recording of the presidential address to an updated one

Should we stop the running shows and cancel those that wait for their start hour? Should we continue with the eastern regions and cancel the later ones? What’s with the commitments about the ads in the show? What to do with previously published promos?
What to do with the presidential address? It has to be played exactly at the local midnight, it contains the countdown to midnight, so there’s no delaying or placing it later in the show. Do we erase it completely? Do we play the old version in earlier time zones until we receive an updated one (we weren’t even sure whether an updated version will be recorded and distributed)?
How would you approach this crisis?

Trying to rise up a little above the concrete technical issues of replacing parts of the recording and rescheduling everything, I ask myself the following question: is the product obliged to react to external events or not?

On the one hand, everybody except those who had directly suffered the impact will continue celebrating, and that’s our audience. We have our ad commitments. We have our business to support. And we don’t have much resource to make drastic changes quickly, remember, it’s new year’s night.

On the other hand, that’s social responsibility — to support the victims if only by silence, to respect the mourning, to not wear a mask of fake normalcy.

What would you do?
Well, that’s what we did:

we played whatever had already started playing and switched to an updated address version as soon as we had it (in time for the most part of the country to see the new one)
we hacked our own show recording to mute the very seconds with the unfortunate joke, so the audience thought their internet connection flapped and they heard nothing for 2-3 seconds we got ready to turn everything off the moment the mourning is announced (in fact it wasn’t until after a couple of days)

So the product didn’t change it’s course but slightly adapted the content. Did we have to do more?
Next time I’ll write about a more current tragedy and how products react to that.

Управление продуктом, или новое название для “я тут за всё отвечаю”

Galina Mitricheva — Wed, 20 Apr 2022 05:43:27 +0000

Задумалась тут недавно над огромным количеством людей в роли Менеджеров Продуктов. Откуда они все взялись? Теоретически это люди, которые отвечают за направление развития продукта, стратегию, видение, перспективу, и чтобы это всё как можно лучше соответствовало запросу рынка и потребителя.

Больше всего моё любопытство вызывает тенденция к отпочкованию «продуктового развития» от «бизнеса» как дела целиком, состоящего как из идеи продукта, так и из воплощения с операционкой. Если раньше (не спрашивайте меня, что такое «раньше» и когда именно это было) бизнесы создавали люди, горящие идеей какого-то продукта или сервиса, и нашедшие деньги на обеспечение операционки под этот продукт, то сейчас (последние лет 10–15, на самом деле, не больше) носители идей тоже являются наёмными сотрудниками, и зачастую вынашивают и развивают идеи не собственного авторства.

Источником бизнеса сейчас становятся чистые, не замутнённые идеалами капиталы. «У меня есть деньги, и я готов их вкладывать в тех, кто умеет продумывать и развивать произвольные идеи и направления. Мне, как инвестору, всё равно, что это за идеи, если они обещают по факту реализации дать хороший ROI» Больнее всего, почему-то, за обратную сторону, которая «мне, как продакту, всё равно, что за идеи развивать и что за продукты создавать, если на них готовы давать деньги».

Я сейчас, конечно, смешиваю тех, кто привлекает инвестиции на свои собственные оригинальные продукты и сервисы, и действует как вполне классический бизнесмен, и тех, кто осознанно идёт в наём продуктовым менеджером, продавая свои абстрактные навыки работы с идеями и данными, не особо заботясь, какими (и чьими) будут эти идеи.

Что интересно, и, на мой взгляд, не совсем рационально, так это размывание роли проектного менеджера в пользу продуктового менеджера и лида разработки. Если посмотреть на рынок IT вакансий сейчас, вы на 10 позиций продуктового менеджера найдёте хорошо, если одну позицию проектного, хотя и та, и другая роль по-прежнему остаются актуальными в процессах разработки, и требуют порой кардинально различных навыков и склонностей.

Причём продуктовый менеджер начал поглощать проектного, не устаканившись ещё в чётко определённом списке задач и области ответственности. Свидетельством тому может быть, например, официальный сертификат «Agile Certified Product Manager» — ведь Agile это чисто про процессы и проекты, и сложно прикладывается к задачам про исследование рынка, маркетингу, проработке стратегий и так далее. Некоторые определения также относят к задачам продуктового менеджера работу с персоналом (HR), продажи, поддержку и внедрение. Такой мастер на все руки получается.
Удивительно, как всё мельче бьются по технологиям и прикладным областям специальности в разработке, и как укрупняются специализации управления, что продуктом, что разработкой. Про разработку я тут не подробно не говорю, но рынок сейчас требует активной вовлечённости лидов в управление процессами, как минимум, а то и в работу над продуктом.

Возможно, во мне говорит педант, но говорит он такое: если ты нанял руководителя разработки, лучше всего он будет — сюрприз! — руководить разработкой и разрабатывать. Если заставлять его выполнять ещё другие роли, он (скорее всего) станет меньше успевать по своей основной роли, а в дополнительных будет просто плох. Конечно, по-прежнему актуально соображение про корову, которую можно просто больше доить, но это ли путь к успеху?
Возможно, это нормальный природный цикл, который постоянно мечется от уточнения специализаций к их объединению в «на все руки мастерах», а потом опять качнётся в сторону «давайте каждый будет делать то, что у него лучше всего получается, и не всё подряд». И это точно нормально стремление владельцев денег к максимально быстрому и дешёвому профиту… Но в этом бизнесе нет души. Я скучаю по делу, в которое верят, а не делают за зарплату.

Почитайте ещё интересную статью про историю зарождения роли Продуктовых Менеджеров: https://scrumtrek.ru/blog/product-management/7082/product-management-history/
7