User deleted post
My Boss wants me to do Service Ownership as a Product Owner? Is this right?
I mean if the Scrum guide says it, tell your manager to bugger off… lol
I didn’t mean not to talk with the customers, I was asking if I have to do Customer Support now too on a daily basis if I am asked. I thinks not. Getting requirements and answering all product related questions are two different things. In other areas we have support people mine is new and we dont habe any (yet). If I say yes to this, I am afraid having support people will put to later ans I burn out.
I think everyone has to. That’s sort of the point.
In all the other areas we have Support level for this.
the worst part is the contact with customers.
I've never seen a PO outright say they actively dislike being in contact with customers. Like, for your existing teams, how do you know what you're building is valuable if you're not in contact with your users?
I mean, "I hate being in contact with my Developers" seems to be absolutely acceptable state of the role in 99% of cases too. I like that we're mixing it up for once! :]
Nooo, englisch is my Third Language. Of course I have customer contact and this is also needed for requirements. Also my Product is B2B2B. My stakeholders are mainly other Themas in my Company we are providing a Platform for. I mean I also would have contact with B2B2C customers on service questions then, this would require a lot more and unfiltered contact, which I don’t hear from other Product Owners have in Software companies. In other areas, they have Support (1st and 2nd Level) people for this. I hope I could made this clear?
u/Strong_Coffee_3813
1. You have a platform team, because the platform you build serves internal customers (teams inside your company). What do they do with your platform (or "product") then? Just "consume" the service, self-serve? Use it as a part of their own products provided to end-users?
2. What is the end-users doing in this mix then? Why the teams you serve are not responsible for handling them?
3. If you need ITSM processes, then you should have a defined, strict process, sponsored (or chosen from exisitng resources) L1, L2 lvls of interactions, but why does your Product Manager wants to make you the first line of end-user service? It's a whole different activity than platform development.
Good questions! Thank you for that.
1. Mine Is the cloud platform and my internal stakeholders have topic for migrate to this platform. I am in contact with them almost daily. this is good and working well.
2. end users are our customers from the company, they have their own business of their own and we want them to use our cloud solution as well. they are handled in all the areas we serve as a ERP System. The contact with them is through support people. The cloud area we are working with has no support system yet. so that would be me. and that's the point. I would do support and answer them on contract conditions (which I didn't have any work with before - that was my delivery lead aka boss and product manager).
3. that seems the thing which is missing here. We don't have one for this new area I am working in yet. So have to do the support stuff also now? I feel also like, it has not really to do with Product ownership anymore.
So to me it’s almost self explanatory that your cloud platform piece should handle end users through support people, similarly as it’s done in other cases, but from my perspective it shouldn’t be you, at least long term. You should figure out with your PM how to process service requests, which can be handled via L1/L2, which one should become as suggestions for platform development.
Service management is often a part of product maintenance / sustain. This is absolutely related to the product, BUT not necessarily to its development. Development is strategic, planned and driven by vision. Service is ad hoc, more rapid, process driven and is about product adoption or product maintenance. Why not copy the operating model for this piece from another team?
If it's purely a platform team, where none of your stakeholders and users are external and only internal teams... Well you could argue that your product is what other teams use.
I've seen that with teams building ORMs, internal coding languages and layers only used internally.
But it usually makes sense to reduce that to a minimum. It sound to me like your product is actually used by customers and that you should have interaction with them. The less layers beteen dev teams and customers the better. So to me and the other you should likely enjoy the hell out of being close to them. I hade a demo to customers today as PO with my team (I code too though) - and that's literally the best part of the job.
Thank you for your contribution. Yes, we do both. That's why it is a lot to do for me as the only PO here. I just started 5 months ago in this department. I don't mind interaction of course. But answering them for contract information seems a thing for support for me (we don't have this yet in this department, in others we do). that's why I should take this part over too - in the pinion of my boss. I would like to hire somebody for this and interact with this person. Maybe I'll do that but for a limited time- there will be at least 100 more customers every year.
At 100 extra customers per year, and if they require interaction to sign deals... That's definitely a new role. It all depends. If its only a few a year, but requiring a lot of interaction... Then I'd say it works well. But if it's constant dialog on contracts ... Well there might be an argument for a second role.
Regardless of what the playbook says, or anyone for that matter. The fact is that you have responsibilities that increases your chance of not being fully present at task at hand and that also increases the chance of doing multi tasking which means you probably be very busy doing all the stuff that is in your job description and beyond. You are or will be seen as “busy” but the quality of your tasks will suffer and there are high chances that you may get behind on majority of those tasks.
Bottom line, if I were you I would connect with the boss person and share all the things that are on your plate currently and add the new responsibilities on top. And work together to identify priorities which works for you and the boss.
The end results: full transparency of work, prioritized list of things, shared and common goals. Communicate often means solving problems as a team and not as an individual.
thank you, this is a really good advise. At the end, I am doing between 85-105% currently and I don't know how to handle this task additionally. that's why I am asking for arguments, why I don't can be fully on this new responsibility too.
Within Scrum, you are allowed to delegate backlog management and even stakeholder management to team members. If you hire someone new for service management, consider a UX'er.
Also, SLA's can act as guard rails for quality, which is especially important when you and your team are being overloaded. Be aware that this is only good for "external" quality (good service), but not for "internal" quality (maintainability).
Good luck!
https://scrumguides.org/scrum-guide.html#product-owner
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
There's certainly room to question if you have enough bandwidth to support two teams, but being able to describe, market, and discuss your products with customers is absolutely the product owner's responsibility. If you can show your company that you can't keep up with the workload, then perhaps suggest they get a dedicated product owner for each team.
That doesn’t say I Need to do Support? If they have a question to a contract, do I have to have the contact or support/service?
It's your product. There may be other ways to address your customer's confusion than direct conversations every time, but it's ultimately still your problem to solve.
Yes, the problems itself I can work with. But do I have to be the first contact - that's what I have to find out.
It's your product, you're the owner.
Some questions though.
How large is this customer base you're expected to support, 100s, 1000s?
Is your product making enough profit to have its own support team dealing with customer queries? If so, as the product owner, perhaps it's time for you to plan your products long term support needs and start putting budget towards implementing that.
It’s the Main Focus Go the Company right now and it will grow from 40 currently to hopefully several Thousands in the Next 5 years.
If majority of your effort is on what’s being delivered and what’s being delivered next then you are a project manager.
Project manager tasks are only one aspect of a product owners responsibility.
Your the product owner, the Swiss Army knife that does what needs to be done. Learn it, own it and then delegate it.
You have to do what your company tells you to do, or you can quit. No amount of “but the scrum guide says…” is going to save you from this.
I had a call with the product manager yesterday about this. He is with me and also says that other people from documentation should do this.
You thinking other people should do it is irrelevant. Your boss assigned it to you. Make your case but at the end of the day if your boss doesn’t budge then it’s do it or leave.
I mean we will have a Call and start a process so they will so it. But yeah, at the end you right, if this will happen in the future.
You may be right that another team should handle it, but again, that's irrelevant. We all get assigned things we don't want to do or think another team should handle.
If you are already at your limit of work you can handle AND provide quality, your best course of action is to discuss with your boss what you currently have on your plate and ask them what they want you to deprioritize to take on this new task.
Simple answer is: if you don’t have bandwidth, you should be saying that to your boss. Period. So, hey boss, if I take this on I have to drop something.
You’re the product owner this is literally your job function. Perhaps the cargo cult “Agile” that is just a Waterfall pig with Agile lipstick that manifests itself in very big bureaucratic companies has given you the wrong impression of what being a product owner entails.
The clue is in the name. Product Owner. You own the product.
Much of extended Agile theory agrees the best way to deliver calue to the customer often and early is to minimise the customer distance, that is, the less layers of management between the customer and the team the better. That is why the PO is often tasked with customer interaction, and as an employer, it is mine and my executive peers in other companies’ expectations too.
This is from the official scrum guide:
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.