--

FLASHBACK TO OCTOBER 2017

I will always remember my first interview at Badi. The Management team told me “We aren’t sure about the difference between a Project Manager and a Product Manager but all we need is a person that helps us get things done.” And this is when I came in.

Badi was at an early stage with a workforce of around 20 people, 10 of them developers, 3 designers, a couple of data scientists and the founders.

Back then, the stakeholders were super involved in the product definition and pushing hard to deliver complete features. Since the functionalities were predefined and designed according to what we thought was “the right thing to do”, there was no “need” to validate them and all company energy was focused on shipping.

THE CONCEPT OF PRODUCT

At that time, the concept of “Product” was understood as an execution and process improvement profile. All of the tech team, including me, spent several months defining and iterating the full development lifecycle, from the branching and releasing strategy to what Agile development meant to us. Those months were all about setting up our playground rules while developing what stakeholders thought were our key features, designing, defining and testing user stories and trying to have more than a couple of days of visibility on what’s coming next.

As crazy as it might sound, the Product Roadmap was a black hole at that time. We were pivoting between what was needed/what was broken with almost no data apart for the number of users that was (amazingly for us) constantly growing. Functionalities were prioritised based on the latest requests and user needs identified and literally taken from user reviews. We didn’t have the time to analyse, research or iterate. We needed to move super fast.

One year later, the development and data team expanded, about 15 people joined the boat. We realised that we couldn’t continue to work all together in the same functionalities, so we decided to transition to a squad structure and this is when we entered in an area of “big evolution”.

With two full autonomous squads, brand new data profiles and PO’s, we were ready to transition from a feature squad to the much wanted “Product squads”.

Although our first 3 months roadmap was still based on stakeholder's requests — the solution of these was no longer predefined. Developers, UI/ UX designers, and data experts now had the last call on the “How”. (spoiler: tracking came into place).

Although the push for a fast development still came up some time, we succeeded in putting the required tracking in place and MVP’s started to sound familiar and well perceived internally. We were no longer blind! After all, the first data visualizations came into place and as PO’s, it became easier to set up priorities. We were backed up by metrics and quantitative insights that allowed us to spread the word on how our users were acting.

Furthermore, this helped us start thinking in terms ROI, impact, effort… thinking about the goals we wanted to achieve rather than the functionalities we used to be requested to ship. This is how the product mindset started spreading around, slow but steady.

LEARNINGS AND IMPLEMENTATION

Six more months had passed but we had defined the 3 KPI’s we wanted to impact, set OKR’s as company goals and even defined our North Star Metric.

We developed a product methodology and started following the so called Product lifecycle.

  1. Prioritize

With the experience of 3 more PO’s coming into stage, a brand new User Research, and clear definition of what we wanted to achieve based on our brand new OKR’s, we were ready to set priorities based on impact analysis. The product team was not only responsible for the deliveries but mainly for the value delivered.

  1. Validate

Product focused on getting valuable insights from our users and stakeholders, validating them with the corresponding data and early and leaner implementations. MVP’s mindset was set as part of our DNA and with the corresponding A/B test setup, we never again considered a hypothesis that has not been proved.

Once we are certain we have understood our users, squads are the owners of the solution.

  1. Iterate

Once the early validation shows us the light, we take the learnings, we iterate on them and we improve the solution further.

And this is how, after two years of adventure, I’ve transitioned from being a Project Manager (getting things done) to a Product Manager (getting the right things done). I can see we are now one step closer to a product-centered organization, with a clearer idea of what product management means and the real value of a Product Manager.

However, each day is still a challenge and as moving fast implies breaking things, Badi and I will keep on trying, breaking, learning and iterating further. I’ll keep you posted!

--

--

Elena Gonzalez
The journey from a Project Manager to a Product Manager

Product Manager passionate about spotting problems and developing its solutions.