Journey, the first 90 days of 2016.

This story might seem outdated since I wrote the first version here. Basically, it was December 2015 and I just became the product head of STORM.

I don’t want to get into too much detail but here’s a brief summary of my learnings in 2016. This might be helpful for someone who needs to figure out what to do with a product in the first 90 days. Note that this largely depends on the type of organization this is, since as a product head, I was also product manager, scrum master, part time QA, and all of these hats combined. The startup guys surely understand this.

I’d like to borrow from my HR background with this model from Bruce Tuckman called Forming, Storming, Norming, Performing.

1st 30 days: Understand the process and prioritize (Forming)

It was helpful that coming back to STORM felt more like a reunion rather than a transition into a new job. However, since I was gone for 2 years, I needed to understand the process again, which meant having one on one’s with people in the team. The first issue I found out was a disjoint between the sales group and the tech guys. Naturally, since there wasn’t someone acting as a gatekeeper between the sales guys and the tech guys, it became some sort of an urgency contest — meaning whoever was more vocal about issues got their bug fixes done.

The one on one’s were helpful because I got to understand each developer and their concerns. This allowed me to understand their capacity and be able to get a sense of how much time they needed to be given in order to develop. Thinking about it now, it would have been more helpful if got a basic understanding of our system then. I admit that I did not know the difference between backend and frontend development then. But having the one on one’s just helped me get a sense of familiarity with the developers and what they needed.

The next steps I then took were to create a workflow between the sales and tech guys. I also had my share of one on one’s with the sales guys but to explain that they could not promise timelines without consultation. In their haste to land clients, they gave certain timelines which developers said yes to, but could not deliver on them. I gave each sales guy a quick introduction of our software development process and worked with them in order to have a clearer timeline for the client. I also accompanied them in each of their visits with key clients in order for me to also get a glimpse of how the product was sold. This also allowed me to foster deeper relationships with the clients as I eased into the role. This also allowed me to see where I could help the sales guys with their work — we needed to work closer together as they assumed a lot of things and weren’t familiar with the system.

Note: If the people going to clients aren’t familiar with how the system works, it’s product’s fault. There’s just no other way around it.

The next 30 days: Balancing workflow creation and bug fixing (Storming)

Coming from the experience with the sales team, I really needed to be hands on and conduct internal testing with them in order to make sure that all the features and requirements for their clients were working. This necessitated creating templates for requirements and an overall process before launching.

I then worked with the developers to be able to prioritize bug fixes. January was our peak season with all our clients launching just weeks from each other. This meant that no new development would be done because it was about implementation. I had a daily meeting (I didn’t know they were called standups then) with them and basically prioritized which bugs needed fixing. That sounds archaic and I am sure there are better processes now in order to do this, but at that time, we were deep in bug fixing mode since implementation with multiple clients usually bring out the bugs which cannot be caught by testing. The daily standups became an avenue to really see what bugs were happening and with what client, which allowed me to see the bigger picture and decide who would get prioritized first. If you notice, I was now making the decisions on what we would fix first. This also meant conversing with the sales guys and having multiple back and forth discussions with them in order to explain why we had to do this.

The last 30 days: Following Through (Norming)

It wasn’t a perfect implementation, but I spent most of March still continuing both processes I mentioned above in order to ensure that it becomes a regular habit. There was now a more regular cadence between teams which resulted in a better implementation, but of course, there was still a lot to be done.

The last step is performing, which I am not sure was ever achieved. Thinking about it now, I should have used the time to be more strategic. I should have tried to understand the needs of our users more and tried to craft better solutions. But my admission is I was too inexperienced and too overwhelmed by the operational side of the job to be able to contribute in a strategic way.

So yes, product management is difficult and someone that gets thrust into this role must be prepared with the environment for the product to prosper. It takes a certain culture for a company to really call itself a product company. Most startups never get here, mainly because it never gets to validate product market fit in a meaningful way.

2016 was a rollercoaster, and I’m just talking about my product management journey. Was 2017 better? In some ways, probably yes. That’s for another entry.