A few years ago, back in 2017, together with a friend we decided to take the initiative, use our knowledge, and try to make something on our own.
The story goes like this, we were in a bar at a table in a dark corner waiting to be served. Something that never happened but trigger our discussions that evolved into ideas about how to create a self-service solution for consumers avoiding long waits.
Being a frontend developer myself and my friend a backend developer, helped us to create a nice initial balance that gradually evolved into what ServiteOnline currently is (unfortunately only available in Spanish at the moment, but don't worry we are growing 🚀). An eCommerce SAAS (software as a service) solution that helps stores to go digital in simple steps.
And from day one our main goal was to create something simple, autonomous, and self-service for both parties, including the admins and the consumers.
Since I started working on this, due to the different needs we have gone through, we had the opportunity to wear multiple hats. Taking into account the benefits and disadvantages of it, It helped to discover different areas of the IT world.
It was one afternoon when I was reading a book called Lean Startup that I realized that the hat I like the most was when I was dealing with things related to the product and solution we were building.
The product as in, what are we trying to solve with this? What are our competitors doing? What are the needs of our potential users? Who are our users? Why are some users rejecting our platform? How can we keep our customers happy? Among other questions.
Not only about asking questions but about the processes that we are creating and trying to improve all the time. The prioritization of new functionalities, the search for partnerships, stakeholder's management, deciding about good metrics, just to name a few.
Without realizing it, I was moving towards that direction, and also the books that I was adding to my reading list, the blogs that I was subscribed to were somehow linked to this subject.
So one day, after discussing it with a lot of friends and colleagues, I decided to make this official, and try to figure out how to get a full-time job as a Product Manager (PM), because it felt like I was enjoying it more than programming, and the feedback I received while doing some of the PM tasks were encouraging me to take this step.
Overall, I see this as part of my personal evolution and the fact that I really believe that over time we tend to reinvent ourselves to do what works best for us and where our impact is greatest.
Related to this search for impact, a nice concept that I have recently discovered is Ikigai, which refers to something that gives a person a sense of purpose, in other words, a reason to live. Aside from the historical and cultural implications, I really like what the Ikigai chart represents.
Putting together some ideas I tried to mimic that chart collecting things that I do, enjoy, and I have been told that I am good at, as simple as it may sound the results can be really inspiring.
Of course, it wasn't magic, from the other side of the fence, as a developer, I was losing the spark and the joy of learning new things every day. Having to work for the startup on the weekends or outside my full-time job was really melting me inside, getting close to burnout again.
A combination of two things, the lack of motivation of dealing with something technical and the fact that I wanted to challenge myself from a different perspective, and learn more about other non-technical areas.
Here are the key reasons that in the end convinced to finally take this step:
- As I mentioned before, losing the spark and the joy of learning new things every day technologically speaking was at the top of the list.
- Look for new challenges.
- Working on what suits my skills in a better way, whether it was imposter syndrome or not, I have never felt like I was a good developer.
- Look for higher-level solutions.
- Be closer to customers and needs.
- Keep improving my communication skills, one of my key areas of interest.
- Side projects make me discover the product area and I realized that I can be good at it, that I have more to offer to this world instead of my technical side.
Although sometimes I think we developers are a bit spoiled, the environment it is getting really demanding, causing people to get burnt out at a very young age.
It took me a while to accept that I was leaving something that I have been doing professionally for more than 10 years, plus the university. And we all know that getting out of your comfort zone is never easy.
Since I will still be doing programming for ServiteOnline and contributing at FrontendCafé, I finally decided to go for it. Giving the responsibilities I have outside working hours, I felt like it was the right time to try something new and jump into this new discovery.
It wasn't just me, this is far from being a solo adventure, I consider myself lucky with the managers I have had at my current job in Adevinta. They have supported me from day one and, far from stopping me, they have helped me improve and encouraged me to keep going.
How did it happen
After communicating my wishes and aligning myself with the managers, the first point of my transition was to play, with some other colleagues, as representatives of the different engineering teams during the product-related meetings, focusing on closing the communication gap between those two worlds.
After playing that role for a few months, I realized that I can help the team to be aware of dependencies and priorities. We communicated concerns and limitations at an early stage, and as a result, developers had more time to focus, which means less interruption and fewer context switches.
Once that became more stable and a familiar process for the rest of the team, I slowly started to do a few tryouts (with support) by taking responsibilities from a product point of view and being more exposed to different stakeholders.
The adventure started
After the transition, I have been announced as a new PM now, it could take a few weeks to finish the process, and I would like to help whoever takes my place as a FE developer.
A new challenge begins now. I am lucky enough to have an incredible team to learn from.
Although I a moving out from my full-time position, I will still be in contact with technology with other side projects including this blog as part of them. Plus I hope I can contribute with my technical knowledge even though I will be taking a different role.
An advantage that can turn out against me, as I should focus more on the what and not on the how , and having the mindset of a developer is something that will take time to learn to easily change.
First conclusions
If you ever think of transitioning to a different role, don't expect this new opportunity you want to knock on your door. Express yourself, show interest, and how you think you have the skills and motivation to do so.
Try not to tackle everything at the same time, read about the roles and expectations it has for your company.
Once you have a clear idea, dig deep and find what a PM means to your team, find the weak points and strong points of the role giving the necessities and the environment.
Make your own plan, learn new things but focus on your strengths, whatever people value about you, make sure it remains there.
Try not to eat more than you can chew. Get a list of the top responsibilities and weak points you have, prioritize them based on needs and crop the list to work on something feasible. In other words, avoid feeling overwhelmed.
Accepting and learning from the feedback you receive can potentially become your main driver. As with every new opportunity, the learnings are the most important fuel for your growth. Don't be so hard on yourself, if you are in this position means that the team supports you.
Enjoy the whole journey, reflect on the things you learn over the weeks. Try to learn as much as possible, there's always time to think about the long-term plan.
Top comments (0)