After getting my CSPO, my company made me the Product Owner for a legacy product. I feel like I am just a scribe for the developers. How do I assert my authority as a PO? The CSPO training made it sound like the PO has a lot of control, but in reality, I feel like a glorified assistant. Any advice on changing this dynamic?
Product Owner authority is established by shifting focus from task-level documentation to data-driven strategic outcomes, utilizing objective prioritization frameworks, and aligning technical delivery with measurable business KPIs.
5 answers
The transition from a scribe to a true Product Owner requires a pivot from tactical execution to value stream ownership. Your current situation is typical of legacy product environments where technical debt has eclipsed business innovation. To assert authority, you must shift your focus from output to outcomes.
Adopt these strategies immediately:
- Define Success Metrics: Establish clear, measurable KPIs for every initiative to move the conversation away from feature requests toward measurable impact.
- Engage Stakeholders: Build alliances with business owners to ensure your roadmap reflects company priorities, effectively neutralizing internal pushback from developers.
- Prioritize ruthlessly: Utilize the RICE framework or similar scoring models to validate backlog items objectively, removing the subjectivity that often lets engineers dictate the direction.
You must stop acting as a conduit for tasks and start acting as a filter for business value. If a request does not align with your strategic goals, it does not get prioritized. It is that simple. When you anchor your decisions in empirical data, your authority becomes self-evident rather than something you need to demand.
Welcome to the real world of product management. Your CSPO cert is a piece of paper, not a command line interface for your developers. If you feel like a scribe, it is because you are acting like one. Stop taking orders from the dev team and start bringing them data.
Authority is not granted by a title; it is earned by connecting the engineering work to actual business outcomes. If you are just documenting tickets, you are a secretary. Change the dynamic by owning the roadmap and the P&L impact. If the developers are telling you what to do, you are not managing the product, you are facilitating their whims.
Here is your action plan:
- Stop writing user stories that are just technical tasks.
- Start forcing conversations about the business value of every single item in the backlog.
- Reject tickets that lack a clear customer benefit.
- If they push back, pull in stakeholders from Sales or Finance.
Make them see you as a strategic partner who secures their budget, not a clerk who types their tickets. Get out of the weeds and into the market strategy immediately.
You are conflating authority with compliance. In many legacy systems, the dev team has institutional knowledge that feels like power, while you have the responsibility without the leverage. The data does not lie. Start tracking the return on investment for each sprint cycle. If you can show that their preferred technical tasks are stalling revenue growth, the conversation shifts from 'what' to 'why'.
Stop facilitating the status quo. If you want to stop being a scribe, stop writing down things that do not support the overarching value stream. If you provide no strategic direction, the team will default to the path of least resistance. You are currently the obstacle to them doing whatever they want. Be the catalyst for what they need to accomplish for the business. Use performance metrics to force technical debt discussions into a ROI framework. Data wins every time. If you do not have data, you are just another person with an opinion, and your opinion currently carries the least weight.
Saranya Mugeraya, your point on performance metrics is very helpful. I am currently working on documenting our sprint cycles and will integrate these ROI frameworks into my reporting immediately.
Thank you for the advice, Saranya Mugeraya. It is a bit overwhelming to think about tracking ROI, but I can see how shifting the focus to data might help me find my footing.
Asserting authority in a legacy environment is less about exerting power and more about defining your boundaries. The scribe dynamic exists because you have allowed a vacuum of leadership to persist. Developers are filling that vacuum with their own preferences because you haven't provided a compelling, data-backed vision.
Consider this structured approach:
- Define the 'Why': Before any development starts, force a discussion on the business problem being solved. If you cannot articulate the 'Why', you have no business writing the 'What'.
- Own the Roadmap: You are the curator of the product vision. If you let the developers prioritize, you are effectively abdicating your position.
- Communication Patterns: Stop asking 'what should we build?' and start stating 'this is the problem we are solving next'.
By shifting your language from inquiry to directive based on business objectives, you reclaim your role. You are not there to serve the team; you are there to serve the product, which in turn leads the team. Keep the conversation centered on the user and the business, and you will find the team starts looking to you for direction rather than task lists.
Kripa Dawangave, I appreciate the clarity provided in your response. Distinguishing between the 'Why' and the 'What' is a logical step for refining my current communication patterns within the team.
Everything is feeling quite frantic right now. Kripa Dawangave, I appreciate the structured approach. I will try to stop asking the team what to build and start setting the direction myself.
I am so sorry for asking, but how do I start owning the roadmap when I feel so lost? Kripa Dawangave, your advice about focusing on the problem being solved really resonates with me.
It is important to recognize that this feeling of being an assistant is often a symptom of low-trust environments within legacy systems. When developers have been burned by poor product decisions in the past, they tend to take control to protect the stability of the system. You have to win their trust by showing that your decisions reduce their cognitive load and maximize their impact.
Think about the flow of value through your system. Are you bringing them clear, bite-sized problems that allow them to shine, or are you just dumping unrefined, conflicting requests onto their plate? True authority is quiet; it is the confidence that comes from deep understanding. Spend time understanding the legacy constraints. When you can speak their language regarding technical constraints while balancing it with the business realities of the market, you will find that you no longer have to assert authority. They will begin to defer to your judgment naturally because they recognize that you are making their lives easier and the product more successful. Lead through clear, informed intent.
I apologize if I sound naive, but using an ROI framework to address technical debt is a brilliant idea. I have definitely been letting the team drift far too much lately.