Journey on managing a product and lessons learned

· 919 words · 5 minute read

I had a very weird dream yesterday. Inside the dream I was still in bed trying to sleep, but there were some numbers and charts flying around and screaming to me. It sounds more of a nightmare, I know. It reminds of the book, “The Phoenix Project” by Gene, Kevin and George. However, it was not like they were mad at me, but they were asking for more attention. For a moment I could understand them and put them in order for the new realm to reflect itself as a picture. At that moment I was in peace. Then out of nowhere it felt like there is an earthquake, the scene was shaking non-stop and the numbers and charts were gone. I woke up and realised it was my wristband alarm that was on. Every morning at 5:30 it triggers me to crawl out of bed and start the day with morning routines.

If given enough tools and resources, they can definitely move the organisation to the next level on being data-driven.

I have been developing a data platform for our organisation since more than a year now. It’s been an interesting ride and I still see quite a long distance in front of us. Interestingly, I started as a data scientist and tried couple of Proof of Concept projects before realising that we do not have really a proper infrastructure to build data products. The apps and the websites are generating massive data, but we do not have a warehouse to store them for usage. Data analysts were using a siloed third party services to run their reports. I had a feeling that the absence of a better tool stack was limiting their performance and potentials. If given enough tools and resources, they can definitely move the organisation to the next level on being data-driven. Thus, I found a problem to solve and that’s how my journey in managing a product took off and since then I have been learning tremendously, mainly from failures.

Putting a deadline constraint for rollout was what changed it from being a project to a product with defined roadmap and deliverables.

At the beginning I felt like I know what the issue was and I just had to start building a solution. So did I. I spent two quarters on purchasing, setting up and fueling the new infrastructure. Main reason why it took so long was because I was working alone on it and only 50% of my capacity. In the meantime I was also promoting the product to anyone I could to get more attention and more commitment. Thanks to the trust and support of my manager, I got some budget to have another team member to support the development. It was a rough ride, because we were trying to persuade people that we need this platform, so we need more commitment both in budget sense, as well as in demand assignment. I was even kindly getting some analysts on board to test the tech stack early and provide some feedback. I should have documented them properly, I know it now. Putting a deadline constraint for rollout was what changed it from being a project to a product with defined roadmap and deliverables.

Product should make the users feel amazing about themselves when they use it. Analysts should feel great about the report they have created, not about the functionalities of the tool.

Since the data platform got enough traction, professionalization phase started as well. Not having any prior knowledge/experience in product management, I had to rely on what I saw from other PM/POs and trust in my intuitions on how to coordinate the roadmap. Documenting everything started to become a new normal. It was important not just for product logging but also for communication to external stakeholders. I had not realised the power of structured documentation till that period. Having a well-structured requirements log created an even more aligned team culture than just saying it repeatedly in weekly meetings. Moreover, we have a better collaboration with analysts and other data folks when having a written documentation of the processes, roadmaps, plannings or minutes of meetings. A solution we provide is only as good as our perception of problems the users have in the org and writing it it down turns the bullet points into well-formulated stories.

My accountability is not to develop and deliver a product, but rather produce decisions.

We have managed to grab the attention of many, which turned into countless demands landing onto our backlog. Having only two data engineers in the team next to me, it was impossible to get the requests processed within expected date range. All of them seemed important and interesting. That’s when I learned (after failing the first time) on how important prioritization is. Not that I do not do it, but building a framework for prioritization became important. We are using OKRs on high level, which helps a lot. Nonetheless, on micro-level I have to make decision what change or feature is implemented the next. My accountability is not to develop and deliver a product, but rather produce decisions that enable people to deliver a solution. If the team knows what is more important, then they know how to bring it to the desired outcome.

Having a problem to solve, creating and following a vision, receiving constant feedback brought the product to where it is today. A new phase of scaling starts soon. I have a lot more to discover and learn.