My PM Journey — Developing a new product from scratch
With the beginning of a new calendar year, came instructions from above to reduce the effort dedicated to the platform we’ve been working on, and pivot to productizing an adjacent, manual service which holds potential of being very valuable.
Suddenly, I got the incredible opportunity to be solely responsible for taking a completely manual service and turning it into a product, it was incredible!
A huge upside was that the first part of the deployment was an internal platform to support the analysts that were providing the service. That meant that not only did I have my main customer right there in the same room, I myself had also been in this role just a few months prior. If PM is all about knowing your users, I had one hell of an advantage here.
Lean development is painful
For me, lean development was a given. There’s a consensus in the PM Olympus regarding the fact that experiments need to be designed and shipped out as quickly as possible in order to speed up the learning process. I had no doubt about that.
However, this was the first time I actually truly came face to face with lean development. Let me tell you, it hurts.
Brutal prioritization sounds beautiful in books and in podcasts. In reality, when you’ve planned, updated and got excited about ideas, chopping them with the prioritizing machete feels like ripping out your own body parts.
Even though I knew it was the right thing to do, it was incredibly hard releasing an ugly feature or tab, it was painful keeping that delightful, or even sometimes basic functionality out of the MVP. It really was.
Breaking down the backlog
When I dove into understanding why it has been so difficult for me to give up on tasks and backlog them, I realized that maybe I was using the backlog wrong all along.
Perhaps we started off on the wrong foot because of the heavily negative stereotypes, or maybe due to the immense pressure in my first months on the job, I realized that my backlog became that dreaded black hole where tickets were going to rest in peace eternally. This meant that any item I didn’t immediately place in a cycle, faced the risk of disappearing forever.
Upon realizing this, I understood that I had to act to turn my backlog into a handy tool instead of a feature cemetery.
The breakthrough came in the form of customizing to the awesome project tracking software we use, Linear. Our enormous backlog of important items made it hard to control and understand them all. The generalizing label of “Backlog” didn’t provide enough instant information on each ticket.
To try and gain some more control, I tried breaking down the backlog into sub-categories, which made it much more orderly and understandable . This way, even with hundreds of tickets, I was still able to easily grasp it with a quick review.
This is probably not textbook backlog management, but it absolutely transformed my backlog and empowered me as a PM.
The success of this attempt actually led me to break down other parts of the process into more specific categories as well, as you can see below.
Gladly, staying lean became easier over time. The backlog breakdown eased item de-prioritization, the end goals became clearer and it was easier to distinguish the important stuff from the background noise.
I’m truly enjoying this new format! Writing regarding a specific topic without specific time constraints is quite freeing.
I hope you are as well.
See you next time
For the past several months, I’ve been documenting my first steps as a new PM. If you want to catch the story from the beginning, here are my previous posts:
2. Analyst to PM in three months. How?
4. Surviving my first month as a PM
5. Product Managin’ my way through month #2
6. Wrapping up my first Q as a PM
