From Software Developer to Product Manager: The Big Leap
It's not a usual career path to jump from software developer to product manager. Maybe because there is not much in common between those jobs, except the willingness to build something greater than yourself. I made this exact transition.
When I first started to write this article, I thought that it would be a fairly short article. But after a while, I realized that there was a lot to cover and that I will probably write more detailed articles in the future about some of those points. Tell me if you have questions or feedback, it'll guide me in the next articles.
Anyway, here are the main differences between the two jobs.
The emergence of a passion
First, a bit of context. In my teens, I spent way too much time on the computer. I was building websites on random subjects and tried to generate some traffic. Later, I got my Master of Computer Sciences at the University of Louvain. I've always been fascinated by the power of computers, software, and the web specifically. Tech is an important part of my life and has always been.
During my master’s thesis, I was part of a student association organizing a significant engineering job fair (with more than a hundred companies). The event organization was chaotic. We called hundreds of companies, sent hundreds of snail-mail messages back and forth, and took notes of everything in big (and messy) Excel sheets shared on Dropbox. It wasn't pretty.
Then it struck me. What if I could build a software to manage all this mess? I already knew a bit of Rails (a server-side web application framework written in Ruby) so, with a roommate, we quickly built a basic web app where companies could subscribe to the event online. It was transformative. Weeks of work shrunk to hours. It made me realized the power of software, and right after this experience I was 100% sure that was what I wanted to do.
Build elegant software from scratch to help people be 10 times more efficient.
My (short) developer career
Before jumping to this new role, I had been a junior software developer for a bit more than three years. I loved those years. Like many of us, in the beginning, it was like being paid to do something I truly loved.
Like most junior developers, I learned a ton in the first months. The difference between the theory we learned at university and the practical applications we used in industry is so huge, it's like you have to learn everything from scratch.
But soon enough, I noticed that I actually cared more about the outcome than the actual development. Don't get me wrong, I love to code. But overall, thinking about the product itself, the design, the user experience, and how to solve problems was even more important for me.
That was even more obvious because I was building software for other people on the side. And on those projects, I had full ownership, from understanding the problems, designing the solution, building it, and, finally, shipping in production.
At my regular job, I was helping our product manager with mockups and wireframes and making the bridge between product and engineering. I then dug deeper into design and UX. There, I found another passion and an infinite number of things to learn.
At the end of my developer career, I was quite confused because I didn't really fit in a box. For sure, I could code. I could design a bit, too. And I liked both equally. What could I do? Companies want you to fit in a nicely scoped box they can put in an org chat. I felt like doing only one or the other would frustrate me.
But then something funny happened.
I applied to a company called Elium for a software developer position. And after the second round of interviews, they offered me the role of... Product Manager. Interesting. To be honest, I didn't know exactly what it meant. But I accepted.
Starting my new role as a product manager
The first months were quite intense. Going from software developer to product manager is a big change. It actually changes every single habit you have. Used to working in big chunks of uninterrupted blocks? Forget it. Talking with rational people? Thing of the past. Working in a kind of predictable environment? Not anymore.
But let's go deeper into each of those differences. Maybe you're wondering if going to product management could be a good move? Or maybe you're just curious about the role?
Build vs Lead
This might be the most significant difference between my previous role as a software developer and now that I'm a product manager. Software developers build and product managers lead.
Building means that you have made something concrete at the end of the day. You can tell immediately if your day was productive or not. You can show to others and play with your new feature. Your contribution to the product is tangible.
On the other side, as a product manager, I'm often doing more abstract work, like interviewing customers, writing documentation or brainstorming new ideas. Sometimes at the end of the day, you can feel like you haven't accomplished anything concretely. It's obviously a false feeling.
For external people it's also more difficult to grasp. They can understand that developers develop and designers design. But what does the product manager do? Well, they manage the product. All this work is necessary to build the right product. Interviewing customers, making sure features brings value, better understand the product positioning on the market are essential tasks.
I struggled a bit at the beginning and I missed from times to times building something I could proudly show to people. Now I've noticed that I'm actually proud of what the team is doing as a whole. I'm genuinely thrilled when I see the product going in the right direction, when developers ship something great or when customers are excited by a release.
Planned vs Self-directed
The second difference I noticed during my very first days is how vast the role is.
It mixes technical knowledge when talking with the engineering team, and design and UX knowledge when talking with designers; but, even more importantly, it utilizes soft skills with communication, planning, prioritizing, interviewing, negotiating, or synthesizing. The subjects also vary a lot between engineering, design, pricing, positioning, onboarding, roadmap, backlog, etc.
It makes days interesting and rich. But it also makes it really hard to concentrate and focus on the most important things at any time. There is no neatly ordered backlog where one could pick the next User Story. At every minute of the day, there are dozens of priorities and it's my responsibility to pick the most important ones.
Once you've picked the most important things to do, your mission is to protect them from the dozens of distractions triggered unevenly during the day by internal people or customers.
Every day, I'm writing down the top three most important tasks I have to do at the beginning of the day on a Post-it or somewhere visible throughout the day. I then keep an eye on this list regularly to make sure I'm not sidetracked to less important but "urgent" tasks during the day.
Maker vs Manager schedule
Related to the previous point, there is also a difference in how your day is organized.
Paul Graham already wrote about this subject in his blog post, maker's schedule, manager's schedule.
As a software developer and maker, you typically organize your day in two big blocks: the morning and the afternoon. You're doing your best to avoid any meeting in the middle of those blocks because it would break your concentration and it takes time to get back to 100% concentration on what you were doing.
As a manager, your day is way more fragmented. You can have multiple meetings throughout the day and most of the time, they don't follow each other in one block. That can scatter your day into small chunks. This can kill your productivity because you have never the time to properly think or make something sizable. There are tools and methodologies to mitigate those issues, but it's a challenge for sure.
Rational vs Emotional
Software developers like to think they are rational people. They aren't. But at least they try. When there is a technical decision to make, they analyze the root problem, search for multiple competing solutions, and pick the one they liked in the first place anyway. But the process itself is quite rational. Software developers are used to making compromises.
On the other hand, customers frustrated by a limitation in the software are a bit more emotional. Same goes for salespeople who just lost a great deal because something was missing in the product, or people from customer support who just had a phone call with an angry customer.
They are pushing you to make decisions you don't want to make because of their current emotional stress. Usually, the discussion centers around a missing feature, which is always critical and urgent for the customer or prospect.
In general, the solution is to dig deeper to find the root issue or challenge the customer is facing, have a conversation with them, and put things in perspective. Most of the time, it's not that urgent. The risk is to jump on solutions, do anything that we think will make them happy based on the wrong hypothesis, only to understand later that what we've implemented is not properly solving the customer's issue (and making other customers angry if you're unlucky).
Correctness vs Fuzziness
This is a big one. A fundamental difference between the role of product manager and software developer is how fuzzy your environment is. Most of the time, you are looking for correctness in software development. You don't want your product to be logically flawed. You also want to make sure that the app will run smoothly in production. You have tools to precisely monitor the performance of the code or the impact of a recent change. Developers carefully review other’s code before it's merged in the master codebase.
In product management, you're dealing with way more uncertainties. They could be about market direction, product positioning, pricing, or the product vision. Again, there are methodologies to mitigate the risk. But, in the end, there is no way to be 100% sure that our choices were the best ones upfront. It usually takes weeks, months, or even years to know if a choice or bet was the right one.
Between the time you have made the decision and the time it is validated (or not), you must convince others that the choice was the right one. Otherwise, there is a risk that it will not happen, not because the choice was the wrong one, but due to lack of execution.
The hard part is that it's easy to target decisions that don't have been validated yet. People will challenge you all the time if you don't have concrete results to show that you're on the right track. It's your job to keep everyone aligned and going in the same direction.
Protected vs Exposed
When I was a software developer, I felt quite protected from the business rollercoaster. Sales don’t close because prospects don't see the value of the product? Clients aren't satisfied with the product direction? Marketing doesn't attract enough prospects? It wasn't my problem, really. Scrum enforces this feeling because as long as you finish your sprints, nobody can blame you. "Here, I did MY work". Obviously, I'm exaggerating a bit, but you see my point. To be honest, I was willing to do something to help, but my scope was limited and it can be hard to concentrate on the product sprint, the engineering challenges, and something impactful in the company at the same time.
Switching to product management made me accountable for all those issues because, by design in a tech company, the product is at the junction of sales, marketing, and support. It basically encompasses everything. At first glance, it can be overwhelming, but it's extremely challenging and rewarding. Problems are complex, subtle, and diverse.
Narrow vs Open
That's all on a more personal level; it would be misguided to generalize this line of thinking to all software developers, but I was honestly underestimating the importance and challenges that other departments are facing day to day. In my opinion, engineering was the most prestigious and worthwhile department of any tech company. This vision was obviously narrow-minded.
The sales and marketing team are critical to help you understand the market because they are at the frontline of your product. They talk to prospects all day long. They are also the ones who get the most impacted when the product is not satisfying. Without them, the company would simply be a purposeless factory without customers.
In most companies, software developers are also too far away from prospects and customers. They don't empathize with clients and prospects because they don't interact enough with them. Worse, when the only way for software developers to interact with clients is through tickets, they actually build a biased opinion on the clients, thinking they are idiots who can't use the product properly. Even more toxic, it can also make them think that the product is bad and feel ashamed, simply because they are mostly exposed to issues and not success stories.
When you have the role of a product manager, you're interacting way more with clients and other departments, hence building the more nuanced vision of the product state and value.
Am I happy with my career change?
Honestly, making the transition from software developer to product manager is one of the best things that I did in my (short) career. It completely opened my mind about how a company works. It made me realize the importance of sales, marketing, and customer support, but also the tricky and subtle art of pricing and positioning.
I love the mix between design, tech, and business. As a problem solver, I still think my job is mostly about finding solutions to problems, only those problems are way broader. But the main topic stays the same; it's all about the product.
It also pushed me out of my comfort zone. From the feedback I got from my peers, I was not a bad software developer. People in the engineering department respected me and I was quite confident in my skills and ability to ship good code.
Making the jump to product management was also an exercise of humility. I was confident as a software developer not only because of my three years in the industry, but also thanks to my education and the years I spent programming in my teens.
Do I miss coding? This is the most common question asked by my former colleagues. The answer is not really. Mostly because I'm actually still doing it on my side projects. Bonus: I don't have any constraints on those side projects, so I can explore new technologies and decide to do whatever I want. And because I'm still heavily exposed to tech in my job. I discuss a lot with the developers and that allows me to stay in touch with the field. Because I understand their choices and constraints, I'm also still learning. Granted, it's on a more abstract level.
My software developer background is also a nice edge when I need to talk with the engineering team. We can understand each other fast. This smooth the communication and make us really productive when we talk about a new feature or a issue with the product
Would I do it again? Yes, because it's worth it to better understand how the business works. It opened my mind and exposed me to a lot of new business areas that I wouldn't have accessed to as a software developer.
In the end, what I've noticed is that I'm genuinely enjoying the process of shipping a feature end-to-end, from the market analysis, customer interviews, and wireframing to the release in production and marketing. It still feels like I’m having fun doing what I love rather than just working.
Is product management a good fit for you?
Maybe you're a maker and you're wondering if product management could be a good move for your next job. Here is what I would pay attention to.
Regardless of the opportunity cost, I would say first and foremost that there is no risk to try. If it doesn't fit you well, you can always go back to your previous craft. At the worst, you'll have an experience outside of your main craft, it'll deepen your understanding of product management, and you'll have something interesting to say to your future colleagues and employer about this experience.
There are three things I would keep in mind, though.
First, if you have a long history in your craft, say you've been a software developer for 10 years, then you'll have a pay cut. You're basically starting a new career and you'll have to take a junior position. If you were a designer or software developer, you'll be able to leverage some of your skills, but it's a completely new job with a broad skill set to learn. As said, you could take this as an experience in your career. If you don't like it, you won't have any regrets.
My second point is especially important if you're a software developer. If you are, then you're used to be in a powerful position regarding the work market. Your skills are in very high demand. You get many solicitations on LinkedIn every day and moving to another job is easy. Sure, getting a great job might be more challenging, but you'll always have a job in the foreseeable future. In product management, you'll have mathematically fewer opportunities. It's common to have a factor of 1:8 between product managers and software developers in companies. That reduces the number of open positions quite significantly.
Third, not all product management positions will be great. I'm lucky at Elium because of the direct impact and freedom I have to shape the product. It's a great responsibility, but it's so rewarding to ship a feature and get immediate feedback from customers. You'll have to find a way to validate your freedom and impact in the company, otherwise you'll be in an execution position from upper management more than really managing the product as a whole.
I hope you got something insightful or found this useful as you contemplate switching to a career in product management. If you want to drop feedback or have any questions don't hesitate to contact me via my Twitter.
Join the Newsletter
Subscribe to get the latest articles by email.
I will never send you spam. Unsubscribe at any time.
Crafted in 🇪🇺 by Julien De Coster