My Inception as a Product Manager

A Little Backstory

In my book context is an essential part of a post. Wait, wait I can guess what you guys are thinking. Why do you even need a backstory? Well, cause I said so! Just kidding. Don’t worry, I will be short.

Transition from Software Engineer to Product Manager

Well, I started my job at Brain Station 23 Ltd. as an Associate Software Engineer. But, eventually, my boss saw my potential more like a Product Manager rather than a Software Engineer. And, it’s true cause I kind of suck at development. I mean, I know how to develop but I kind of lose my way. And, here’s a newsflash, before this I used to be a master procrastinator. So, it was hard to stick to doing one thing for days at a time. But now, I get to do loads of things and do what my heart wants to do. Product Design and Management.

So, without further ado, let’s get the elephant in the room out of the way, shall we?

What the heck is Product Management? And how does it differ from Project Management?

It’s very difficult to pinpoint exactly what the product manager does in one word. And look, I don’t think I can define product management better than Atlassian. So, I will quote them directly here. I even linked their video here.

Product management is an organizational function that guides every step of a product’s lifecycle: from development, to positioning and pricing, by focusing on the product and its customers first and foremost. To build the best possible product, product managers advocate for customers within the organization and make sure the voice of the market is heard and heeded. -Atlassian

What is product management? — Agile Coach — YouTube

Now that that’s out of the way, let’s focus on…. Oh, Wait, the difference. I am sorry, yes that would make your understanding of Product Management a bit better. How is it different from Project Management you ask?

Product Manager and Project Manager Venn Diagram

According to an article by Marcel Tit at Paymo, the key role of a Product Manager is to ensure that the product aligns with the user requirements and consistently propagates through the roadmap of the product development process. From gathering requirements, usability testing, creating and tracking product roadmap, identifying problems to prioritizing development order, and so on. On the other hand, Project Managers uphold the Product Manager’s vision, calculate budget constraints, schedules time, monitors resources, manages risk and issues with the scope of the project, and so on.

Oh, I have read something about product owners and business analysts. What’s with those roles? Are they any different?

Quoting KALO YANKULOV’s blog about “Product owner vs. product manager: Who runs the show?”. — “Both the product manager and the product owner work towards a common goal, to build and improve products that create meaningful value for customers and all stakeholders within the company”. But they differ quite a bit. The product manager defines the product life cycle by conducting user research and unveiling critical insights. He creates a cohesive product roadmap and decides what features to build next. On the other hand, a product owner turns customer pains and problems into actionable user stories and arranges user stories in the user backlog. He constructs and prioritizes the production process to ensure that the development team is clear on what to work on next.

Business Analysts on the other hand are somewhat completely different. They are responsible for collecting and analyzing the technical specifications and studying the feasibility of the product. Quoting, Brian de Haaf’s post from Aha!, “If product managers focus on the “why” of a solution, business analysts do the heavy lifting to work with engineering to determine the “how” of a solution from a functional user perspective.” Well, there are true overlaps here and there but, their roles are different. But in reality, the practice in the industry varies from company to company.

Now can a person be in multiple roles at the same time?

That is elaborately explained in this article that I also linked and mentioned above. But the short answer is yes, it’s possible. But, it is very difficult and there are too many stakes here for one person to handle. This is what I faced and read further ahead for my first project experience as a product manager.

Handling my first project as a Product Manager

First things first, Product Management Flow is a workflow of a product manager. As a beginner product manager, following the instructions and standardized structure of our company we decided to manage the project development and task management through GitHub. Wait, What? Isn’t that the task of a business analyst/project manager? Well, typically and for a big team, yes. But, as our company is being reformed and so our Unity SBU is gradually getting bigger and for now, with a short amount of resources at hand, we had to utilize the best among us. Like I said before as a product manager, for my first project, I had to put myself in the shoes of multiple roles at the same time. Now on to the product management flow:

Product Management Work Flow

First of all, I got my hands on the raw basic requirements of the product and prepared a basic SRS from scratch. But here’s the catch, it was already a fully developed product. Because it was an already developed product it was puzzling for me to go through the full-fledged system and reverse analyze the requirements of the product. There were some mishaps. Nevertheless, I did it. And after that, the initial ballpark estimation of the product timeline was created according to the basic requirements. Following the project kickoff meeting with the client, I started gathering the requirement collection, analysis, and confirmation through multiple meetings with the client. I was consistently updating the SRS in parallel. After that, we started UI/UX prototyping, R&D, and customer feedback in parallel with a final estimation of the product timeline. Then after some negotiation and understanding with the client to finish the product in the given time, I assigned the tasks and scheduled the project. I created milestones defined sprints and assigned different tasks to different developers and designers of the project. I had to consistently manage and observe the development process of the project, track the time spent on the project, maintain project backlog and update the customer/client on the progress of the project.

Ugh! That was a mouthful don’t you think? Now, back to some detailed illustration on how I’ve maintained the product and documentation in GitHub?

GitHub is an amazing tool for development collaboration and consistent version control. But, who knew that it has a few other tools and tricks up its sleeve? It also has in-built tools for project management, documentation while all being just in the web browser. You wouldn’t need any other tool or software other than a desktop browser to properly manage the project as a product manager. That’s incredible right?! Well, in my experience I had a few setbacks. And, there are some issues but it’s a good start overall.

Project Management Board in GitHub

First, let’s talk about the project management board. Here, it is an automated Kanban board that consists of four lists, to do(renamed as project backlog), in progress, in review (manually created), and done. We added the ‘in review’ list for the product manager to verify and move the cards to do. You can choose the board to be built from scratch, without automation, and for bug testing as well. You can add cards to the lists and you can convert them into issues. You can assign tasks to a specific member of the team, attach them to a milestone and label different tasks like bug, enhancement, documentation, and so on. In case of the issues, you can add important details like screenshots, descriptions about different tasks.

Creating Milestones in GitHub

Secondly, You can set up different milestones either for each sprint or multiple milestones for one sprint. You can add a description and deadline of the milestone.

Lastly, for the Software Requirement Specification (SRS), it is a bit tricky. Usually, only files with .md extensions or MarkDown file types are the only viewable documents. But there is a bit of a learning curve about its syntax. Mark Down follows a specific syntax which sometimes allows alternative syntaxes to do the same thing which creates confusion.

Now that we are done talking about GitHub, what challenges did I face during the development of this project?

I am going to explain this in two parts. First, let’s talk about the problems I faced when managing the project through GitHub. Wait, What? I thought we are done talking about GitHub. Well, tricked ya! Just bear with me a few lines guys. It won’t be very long. For GitHub, the issues I faced were:

• GitHub project management is not enough customizable and feature enriched like common project management tools such as Trello, Monday.com, Jira, etc. For example, you can’t set deadlines for specific cards, you can’t set up sprints and see charts for tracking project status and progress throughout the development of the project.
• In the case of MarkDown, the screenshots of the projects added to the document were displayed inconsistently. There wasn’t any way to keep that in a specific height and width automatically no matter what size of the image I add to the document.
• The other problem I faced with MarkDown was when I was adding bullet points and sub-points. There were multiple ways to do the same thing but they have mixed up the approaches which create confusing outcomes.

See, I told you it was only a few lines. Now, other challenges that I faced and the mistakes I made during the development of this project are:

• The first and foremost problem while working through the development process was that it was already a developed product. And there were specific client needs to fulfill only. It is complicated and confusing to articulate the winning states of an already developed product that needs to be delivered through building on additional features.
• Being the first product manager in the team, our role as a product manager was unfamiliar to the rest of the team. The other members of the team sometimes underutilized the full potential of the role.
• The overlapping between the different roles as a product manager, project manager, business analyst, or product owner created a sense of confusion. I found it difficult to think from multiple perspectives at the same time. Thinking and deciding about trade-offs in the development of the project, maintaining product backlog and project management board as well as strategically thinking about user experience, feasibility, and business. I had to consistently improvise to keep up with the process.
• Not having trained specifically with a functional workflow in mind, it was my first project where I not had to define the project roadmap, but also consistently monitor its development process as well.
• The timeline of the project is defined in an Excel sheet. But we didn’t get to develop a project roadmap in the actual standard fashion.
• Failing to get the project done in the estimated time. Well, we did deliver the fully functional project successfully in the client’s given time. But, we kind of didn’t get to meet our internal deadlines, so that we can properly test the project before release or deployment.
• Being a product manager at the beginning or infancy of your career creates some complications. It’s because it is a fairly leading role and you have to give proper commands and instructions to even experienced seniors. It might be difficult to convince them sometimes because of their comparatively more time and experience in the industry. I figure it is a culture and it will grow over time.
• Being the medium of communication for every single call was frustrating. Sometimes direct communication between the developer from our end and the client’s end should work closely to mitigate the time that’s lost in conveying misunderstood messages due to a lack of proper understanding of the in-depth structure of the project. For example, our team needed some things from the web team from the client’s side. While direct communication was enough, our tech lead felt the need for me to be present in every single session of minor communication where I didn’t have any decision to make nor to give any input in the development of the project.
• Sometimes, there can be clients who are difficult to understand and might be harder for you to get them on the same page. This was one of the times. But, I still think we had gotten enough time to analyze the client and tailor the situation and their needs to mitigate even more conflicting situations between both parties.
• We couldn’t properly organize, plan and estimate the whole project accurately from the beginning. The estimation we submitted was done and verified by one person, and the development team was not aligned properly through the progress of the development. And cards and issues weren’t being maintained properly due to the lack of complete understanding and collaborative approach of each other’s workflow.
• Maintaining continuous builds and removing dependencies. A building product for testing and verification must be provided to the product manager consecutively before the project is being delivered to the client. This workflow was not defined and maintained properly. And FYI it is true we needed a tester for this but due to lack of resources, we have to partially or at times fill their shoes as well.

I think it would have been better if we had experienced product managers in our SBU before us. Just as like being the first of our kind gives us to set a good standard by analyzing and correcting our mistakes and pave the road for an even better generation, similarly, we are bound to make mistakes and learn from them because of our lack of any mentor in the same role.

Now that we are done with what went wrong, let’s talk about what we did right.

There’s this Venn diagram at the top of this post that the product manager sits at the center of the UX i.e. User Experience, Tech, and Business.

The Role of a Product Manager

It means that as Ben Horowitz said, a product manager is the CEO of a product, and so he has to make these trade-off decisions to drive the product to its true vision. We had to focus on these three things and I tried my best to make these trade-off decisions as much as I can to deliver the project to the client in the given time. So, the things that worked for our team:

• Proper Requirement analysis, UX Research, and Product R&D for the project.
• Setting up teams in parallel with each other such as the design team and development team where workflows have rarely any dependencies.
• Identifying client needs and getting proper feedback from time to time to properly deliver the product through the pipeline.
• Prioritizing tasks and deliverables accordingly to deliver a fully functional product. Adapting with the time and improvising development flow.

Now, how am I envisioning the next product? What would be the product development workflow? Now, that I have understood many of my mistakes and identified many of the issues.

Let’s back it up a little before I show you my current plan for a more workable product management and development flow. According to a Product Manager on YouTube named Chloe from the YouTube channel Colors of Chloe, these are the key responsibilities of a product manager. Those are:

1. Articulating what a winning product looks like.
2. Rallying the entire cross-functional team to build it
3. Iterating it until we get it right

What do I do as a Product Manager? — YouTube

Being the manager of a specific product with a specific team of staff to build a product with a particular product experience at its core is pretty hard to do. She says the different product is based on different types of user experiences or a very specific set of feature list or pages in an application. If your decisions impact other teams besides your core team, then you have to make sure that all teams are on the same page. The hardest decision as a product manager is thinking through and deciding these product trade-offs.

Well, for my plan there are many things to consider here. First of all, we have a relatively small team and while it is slowly getting bigger, it is not going to be as big as a big tech company anytime soon. So, many of the smaller tasks and responsibilities are have to be either single-handedly managed or merged and quickly performed for the sake of simplicity and time constraint of the company’s development structure. And just like Software Development and Product Development Life Cycle, it is an iterative process for the core development of the company to update and upgrade its strategic control interfaces to stay up to date with global industry standards and strategies. So, what’s the gig?

When preparing a process to follow on a project for our SBU, a core software development team, we have to be coherent with Agile SDLC. Between, Product Development life cycle and software development life cycle we have to find a common ground and build on a coherent and consistent cycle that builds both a winning product and complete and functional software. For that part, we need to research and ideate even more and formulate a freshly brewed life cycle concerning all of the issues. And so, after we’re done doing that, I will discuss it in one of my next articles namely, “How can we build a winning product as well as a complete software solution?”