From code to roadmap

In many IT companies, former programmers become product managers. This is logical, because they understand the development process “from the inside”. But even they make mistakes due to misunderstanding of processes, lack of management skills and ignorance of tools. This was the case with me for the first time, so today I will tell you about my experience of switching from developers to PMs, pleasant discoveries and jambs, as well as what helped facilitate such a “career transformation”. In order not to solo, I will supplement the story with quotes from my friends and colleagues in the industry.

I’ll warn you right away: the product I’m currently working on is still under the NDA, so I left some names and details “behind the scenes”.

How did I get into PM

To begin with, a little bit about why I changed my role. My name is Arthur, I work (and have worked) at an IoT startup developing a platform and creating industry solutions based on the Internet of Things in the black label format – first as a lead developer, and then as a product manager. The Internet of Things is a new, unstable area, a competitive market is just being formed, potential customers do not really understand what it is and why it is needed, technologies are changing… It is logical that startups are also “feverish”, their structure, personnel and product portfolio change regularly.

It was in this very portfolio of our company that one unfinished product project was lying around. Not the most difficult to implement and understandable to customers (the future love of our salespeople), having a potentially wide application and able to quickly bring a good profit. But the implementation was very, very sluggish (forces were spent on key tasks), the question “when will we do it?” hung in the air for at least six months. After a small internal crisis, we decided to appoint a separate person responsible for this product and allocate resources for it.

Why did the choice fall on me? Firstly, I regularly annoyed managers with the questions “what do we have with project X?” and “when will we do project X?”, which earned me the reputation of “the one who needs the most” (as it turned out later, the most correct reputation for projects and products). Secondly, the product is in a subject area that I understand, and I would still be in the implementation team, but I would not become the main and irreplaceable in it.

In general, developers usually switch to products because they don’t see themselves as programmers in the future, but they don’t want to leave the usual IT industry. The second popular reason is professional burnout, code fatigue.

Why did I decide? It’s not that I’m “burned out” or I’m tired of coding — I love programming, but not so much that it’s painful to experience parting with it. I was immediately told that I would work in test mode and at any moment I could “jump off” back, which means I’m not risking anything and I’m not losing anything. This is one time.

Secondly, IoT is a specific sphere, so by agreeing, I saved myself and colleagues from having to “immerse” a third-party manager in the market for a long time and slow down the project. And third, I had an idea in my head that was not yet fully formed to create my own startup, so I regarded what was happening as a good chance to try myself as a CEO “at the minimum.”

In the early days, it seemed that more information was thrown at me than in all previous years of work (this is even taking into account the developer’s base). But over time, I developed a new working mode and got used to it. Although during these nine months I made a couple of rake walks. And here are the conclusions I made for myself.

It is necessary to accept as a fact that …

1. Plans can and should be adjusted. This is normal

I don’t know why, but the Stalinist “the plan is something unchangeable, carved in stone” still sits in our generation. At my first meeting as PM, I brought a beautiful implementation plan with prescribed deadlines, deadlines, roles for everyone… A month later, this plan was shattered.

The intended contractors have gone underground somewhere. They didn’t give a budget for something. One of the key developers was hospitalized for two weeks, the second one was delaying the deadlines due to the fact that he had to work for two. And I myself spent a week and a half delving into what I thought to figure out in three days. And, by the way, I would have managed in a week if I hadn’t spent a lot of time on self-flagellation due to the fact that I don’t have time for anything.

“ The first impression of the work is that there are unexpectedly many problems with defining deadlines for tasks. Not in the sense that the programmer can’t tell me how long the task will take, usually the estimate is more or less correct. But there are a variety of external factors that are difficult to take into account when trying to estimate the deadline for the project. This is something that has often happened before, but which I, being a developer and

Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Add a Comment

Your email address will not be published. Required fields are marked *