I am an assistant product manager at a DME who is creating a digital health business. For the first few months, my job’s duties were pretty vague, but now that I’m being asked by my boss to take over as the scrum team’s Product Owner, I’m not sure how I feel about it. Is it typical for an Assistant Product Manager to assume all of a Product Owner’s duties?
Yes, when you first begin working as a product manager, you typically start with execution and gap-filling tasks before moving on to strategy and product definition tasks, which are traditionally referred to as “core PM” tasks even if the role is frequently ill-defined.
Even an experienced PM may begin by focusing mostly on execution when they join a new team because this is thought to be good work for learning the specifics of the product, client, or engineering.
I believe that as an APM, you should make every effort to excel at the job that is assigned to you and take advantage of your strong work to proactively request more difficult work (strategy or definition). Remember that you will require mentorship for this (also known as corporate resources), thus you must first show value in implementation.
@WhitneyChard, I feel better about my APM role as a result of this. In order to cover holes in our sales app, which I help manage, I am now working on a project. By filling in the gaps, I mean including some new and current tangible things that the business provides to the customer. In the eight months I spent doing that, I learnt a lot.
How long should I continue performing this kind of job before I start to feel more secure about my expanding roles and responsibilities?
There isn’t a set timetable, in my opinion. Work that challenges you should still be given to you.
I would advise you to talk to more PMs both inside and outside the organization to get more about how they ramped up, spent their first six to twelve months, and how they currently use their time (duties & time allocation).
Feeling a little bewildered or even underused in roles with ambiguity is common (and perfectly okay!). However, by speaking with people who have gone through comparable experiences, you can receive insightful information and consolation that will support you as you deal with your own uncertain responsibilities and difficulties.
To me, the only time it makes sense to have a PM focused on execution level responsibilities is at the APM level. After reaching that stage, I encourage my PMs to encourage their teams, EMs, and tech leaders to self-organize and spend more time speaking with clients before reporting back to the team. APM and PO are interchangeable terms.
As a junior (PO), if you’re not organizing backlogs, writing tickets, sorting test cases, performing retros and other tasks, escalating as necessary, etc., and you’re not doing strategy (too new to Product), what are you doing?
It’s quite common.
If this is your first product role, I would suggest that you embrace it. Experience that is pretty valuable.
Teams with both APMs and POs are something I have never seen. It is either or. Best wishes.
While it may not be considered “typical” in all scenarios, it is not uncommon for professionals with backgrounds similar to yours to take on expanded or hybrid roles that involve aspects of both an Assistant Product Manager and a Product Owner. Let’s explore this transition in more detail:
- Adaptability in Evolving Environments: The digital health industry is at the forefront of technological innovation, and it is not unusual for roles to evolve and adapt to changing circumstances. As a visionary leader with a passion for technology, AI, and ML, you are well-equipped to navigate the complexities of this evolving landscape.
- Overlapping Skill Sets: Assistant Product Managers and Product Owners share certain skill sets, such as a deep understanding of user needs, the ability to prioritize features, and effective communication with cross-functional teams. Your experience as an APM provides you with a strong foundation that can be leveraged as you take on PO responsibilities.
- Collaborative Approach: Agile methodologies, including Scrum, emphasize collaboration and flexibility. As a result, individuals with different backgrounds and expertise can contribute effectively to various roles within an Agile team. Your transition from APM to PO could facilitate enhanced collaboration and alignment between the development team and stakeholders.
- Maximizing Value Delivery: The core objective of both an APM and a PO is to drive the development and delivery of valuable products that meet user needs. Your willingness to embrace the responsibilities of a PO suggests your dedication to ensuring the successful execution of the digital health business.
- Learning and Growth: Taking on the role of a Product Owner presents an opportunity for professional growth. You will gain practical experience in backlog management, user story refinement, and stakeholder engagement—skills that can contribute significantly to your personal and career development.
- Effective Communication: Clear and open communication is essential in any role transition. Engaging in meaningful conversations with your boss, Scrum Master, and team members will help set expectations, address concerns, and foster a supportive environment.
- Balancing Responsibilities: It’s important to strike a balance between your existing APM responsibilities and your new PO duties. Time management, delegation, and effective prioritization will be key to maintaining productivity and ensuring the success of both roles.
- Long-Term Vision: Consider how your transition aligns with your long-term career goals. Your aspiration to create awareness about AI and machine learning could align well with the strategic decisions and user-focused approaches that are integral to the PO role.
While it might not be the norm for every APM to take on all of a PO’s duties, it is certainly a plausible and strategic move in dynamic industries like digital health. Your willingness to embrace this transition reflects your commitment to driving innovation and delivering value to your organization and its stakeholders.
As you contemplate this shift, I encourage you to view it as an opportunity for growth and a chance to make a lasting impact on the digital health business. Embrace the challenges, seek support from mentors and colleagues, and continue your journey with the same passion and determination that have guided you thus far.
Product managers’ duties aren’t actually set in stone; they just vary from company to company.
Sorry, but what you’re going through is quite typical.
If you didn’t have any PO obligations, what had you been doing? Is there meant to be a distinction between the two? If you weren’t performing PO work, it would be even stranger or more worrisome. Is this your first position in a product, OP? really enquiring. I’m simply interested whether you have any prior experience working in the product job. I’d like to know more about your background and how you came to be in this position.
No, I don’t have any experience in product management. The position is new to me. I’m eager to learn and gain experience.
Cool! I like your honesty. I would say that working as a PO has nothing to fear and everything to gain. APM, PO, and similar titles are only labels for less senior roles; they don’t actually matter and shouldn’t have an impact on your career path. Additionally, you gain first-hand knowledge of all the minute aspects, practical experience with sprint execution, and possibly even the need to make calls or recommendations regarding prioritizing. Later on, you’ll need those skills, which strikes me as a fantastic position to be in for your first product career.
I have seen senior product managers doing PO work, it just depends on the company. I mean, do you expect to be making decisions that have multi-million dollar consequences as an APM? Because that’s what the other half of product management is about: making high-stakes decisions with multi-million dollar consequences. It requires careful analysis, strategic thinking, and a deep understanding of market dynamics.
Sincerely, this is what occurred to me, and I experienced stress. I’m crossing that off because I’m a recent graduate working at my first corporate position, and I have no prior experience with product outside of internships. I was learning how to source requirements, develop stories, run user acceptance tests on stories, and lead grooming, planning, and reviews. I’m also expected to be an authority on the subject, which, after about six months, is plainly not the case. I believe I have acquired the skills necessary to perform the fundamental duties of the position, but I never quite attained the status of subject matter authority.
Same here. This is merely my opinion. As a new APM, I would prioritize mastering the fundamental duties above becoming the SME (subject matter expert). You’ll have to start over in the SME knowledge every time you switch employers or roles. The expectation is that you will be able to write user stories, prioritize work/backlog/features, meet with stakeholders to define requirements, manage the scrum team, and determine whether or not a story has taken into account all edge cases or potential scenarios as you move forward. All of this will follow you around.
Being thrown into the deep end is indeed terrifying. I completely understand. With the exception of one APM, every APM I spoke with at my last F500 business was brand-new to PM. While they were learning on the job, they were only bullshitting their way through it. You’ll arrive. The imposter syndrome affects us all. Ask questions if you don’t understand anything or if you’re unsure of it. Ask a stakeholder, your lead SWE, a senior PM, or your engineering manager. Simply inquire and admit that you don’t know. They’ll understand.
Agree. Also in a lot of companies, APM is synonymous with Product Owner responsibilities. Simply put, it indicates that you do not control the broad plan. PMs, senior PMs, lead PMs, and directors typically own the high-level roadmap. Both POs and PMs appear to be used by many businesses. Some people use APMs and PMs. Simply indicates you’re working at a scrum team level, concentrating on the daily execution and tasks.