I joined a startup a few months ago. Right from day 2, I was put on to customer calls, product discovery sessions while my so-called training and handover was happening.
Now, into my 18th week ; my to-do list has 10-15 items on daily basis. The more I work to reduce it, the more is pushed onto my bucket.
I resisted to revamp a module since there was no use case and someone wanted to do it since they like it. The old boys team in PM role is supporting this PM and asking me to just do it.
Since I stood my ground and said, I cannot work on one liner requirements , change the complete product module without any context, these folks ganged up in call and started lecturing me on speed of delivery, execution, MVP v/s planned releases etc.
Its completely demotivational and I donât feel like working anymore with this team.
How to handle such situations when old timers in a startup just push something which they never got time to do or want someone new to pick up dirty tasks?
@ChristieDook, No process as such ! The CEO goes out and make fancy statements promising to delivery XYZ epics in A time ⌠the whole team of VP and senior management start daily tracking calls to ensure that deadline is met with minimal delay
so all features related to epics immediately become P0, P1 and there are other items which P0,P1 ⌠in short, this place never used medium, low priority in the past
Yeah, this culture wonât change. Itâs time to start looking for new work unfortunately. I had a CEO that did this and it caused so many mental health related issues for everyone.
Your backlog is meant to be increasing, this is a good thing. It means you arenât working in a silo and your team is open to pitching new ideas your way.
Where things fall apart is if the expectation is set that the backlog is a list of things to do, rather an a list of potential opportunities to look at.
Treat your product backlog as such. These items should all have a problem statement, a hypothesis, and linked to an initiative and objective in order to move forward. Not everything in your backlog will get done and that is totally acceptable.
A few things you can try:
Link projects back to objectives
Outline what, why, and how you will measure success
Use a product problem outline to encourage everyone in your team to think about problems and not solutions
Remember that prioritization happens at multiple levels: on your roadmap, your product backlog, and your development backlog. Itâs not a straight line.
Link feedback from customers/teams to these opportunities so you have an idea of what the audience reception/need/frustrations are around a particular problem. This serves as a way of understanding whether or not a problem could be solved and why,
Thank you for framing it that way. I always felt that, but it never occurred to me to verbally describe it in this way. I started working recently at a place where the backlog kept growing, it was seen as bad, and so they wholesale changed to a process where there is no backlog by design, and crucially, that what to work on next should be reactive based on what customers/internal stakeholders make noise about that brings an idea/issue back to the forefront.
As a person that loves having a backlog as a place to store all such ideas and opportunities, as well as a source for roadmap items, this has been challenging.
@Karan, I donât store vague ideas in my backlog. I triage items that are worth trying and if they pass initial value metrics, only then I add them to my backlog.
@KaranTrivedi, This is a great response. Once stakeholders can see good ideas as potential but just in the backlog, and then see capacity limits are X, they start shifting towards helping you by reasoning, âwell since we only have a certain amount of points/dollars/whatever this cycle, letâs spend it on this experiment.â Once they see they are trying to make something impossible become possible they donât fight you. Sprint reviews are designed to facilitate this (if you use sprints) but the point is to expose the accomplishments, findings, and capacity and line up with strategy here.
In my experience, startups and âflatâ collaborative organizations get this way really fast when the expectations they have are just to check in requests and expect them to be answered in order received, but never get much out of their silos.
When you look at the backlog, what items are in it? Are they only product initiatives or are they things from all places in the organization? (dev, business, finance, support, etc.)
The reason I ask is that when looking at the backlog as a list of potential opportunities, itâs much more difficult to look at issues people have identified as anything other than âwork that we just need to get prioritizedâ. Even if youâre able to make a sound argument about why some support issue (that they think is valuable) is not worth prioritizing, theyâre still real people who will start to resent you for doing your job. Especially if your argument is basically just âwe donât have the time because these other things are more valuableâ, theyâll start to really get frustrated. If youâre only responsible for the product backlog and other people have to take care of other items, then your backlog prioritization is a lot simpler and you donât have to keep having these sad conversations where youâre basically saying âprobably never at this rateâ.
@KaranTrivedi, Hereâs the fun thing about product management⌠there is no standard vocabulary or terminology. I see initiatives as a project, and those belong on your roadmap, not your backlog. Initiatives group several opportunities/ideas together for how you might solve a given problem and enable you to run discovery, and select the right opportunities to move forward with.
The backlog should be open to your team to provide you with potential opportunities. My personal rule is, please write out what the problem is, why this might be of value to the customer, and what the existing hypothesis is. If these cannot be answered, then itâs likely the team member is trying to relay a solution instead. I donât shut down the team though, itâs still relevant feedback. When unable to provide further information, itâs added as feedback (to the feedback backlog.)
The feedback backlog then has its own process. With this process it becomes easier to identify potential solutions in the future, and you can group similar feedback together. That still doesnât mean itâll be done though.
Itâs important to highlight to the entire team that work that is approved to be done has to link back to initiatives on the roadmap, and these initiatives must be linked to objectives. Otherwise youâre in a situation where as you say, people get resentful because their ideas are not being actioned. Itâs not because it isnât a potentially good idea, but it isnât a focus for the company at the moment.
I also am a fan of adding a lot of transparency to the process. Share the roadmap, be open about objectives, and have sprint retros/reviews so that everyone know what is being done and what the progress is against that roadmap and those objectives. That adds more clarity to the process itself.
This goes back to my original question about what goes into the backlog, if itâs only product items or not. Because in a lot of scenarios, problems and solutions will be identified by other team. Some examples:
The admin portal is missing a feature that the support team would find helpful, and theyâve outlined what that feature is and how it should work. You could probably justify this under operational cost reduction (because faster responses from support = less time spent doing support = less staff needed).
The engineering team has identified some technical debt created during the last feature that was designed that they would like to go back and address. The engineering team has identified exactly what it is they want to do and how long it will take. You can justify this under being able to deliver new features faster.
There is some system monitoring piece that the engineering team wants to build so they can respond to system problems faster. Your business might have goals related directly to this, or you might justify it by recognizing customer/client retention is at stake.
At any rate, the point is that these things are led by teams outside of the product team but will inevitably flow into your decision making of âwhat do we do next?â and it has never been clear to me if itâs productâs job to prioritize these or not. Does product just funnel every single item development would work on and pop out the items to do each sprint? Or does product have some percentage allocation of the teamâs time? For example, maybe we decide 50% of work on the team is product work, 25% is engineering work, 25% is from other parts of the org, and then product only has to prioritize amongst the product-led initiatives as opposed to dealing with technical debt or other things of that nature.
@Marco, I see what you mean. I donât think it makes a difference as to what goes in the backlog, rather how is the backlog managed. Thereâs two options:
1, manage this in separate backlogs and link back to objectives/roadmap on a portfolio level (so thereâs visibility of the entire org)
2, use tags to identify different areas, and teams can then filter things out based on what is relevant to them.
Either one would work, as long as thereâs an easy way to identify what belongs to the product team and what belongs to other teams. I think âbacklogâ is a very conflated word and people often treat it as a âlist of things that must get done.â This is why I first separate product backlog from development backlog, and then further filter things down per team so itâs easier to manage.
@Michael, Even if you have separate backlogs, the issue is still who is responsible for it. So if thereâs a product backlog, support backlog, engineering backlog, but product is responsible for setting the teamâs agenda, then itâs basically all your backlog. If youâre prioritizing everyoneâs items then it effectively makes no difference to the rest of the organization. If youâre not responsible for those backlogs then the same should be true that youâre not responsible for prioritizing that work either.
Lots of good stuff in this comment but one thing that stands out to me is the idea that the backlog is meant to grow.
Most agile good practice that Iâm familiar with urges us to maintain small backlogs. For example, Age of Product calls out old tickets and oversized backlogs as an anti-pattern.
@PriyaVarma, Yes and no. I kept that super high level lol. Having a backlog with plenty of opportunities is a good thing, but not all those opportunities need to remain active or have to be done. Thereâs a whole process workflow involved here for reviewing, assessing and discarding. But this is where the opportunity template helps. Is there a problem to be solved or is it a feature? Start there.I for one am a proponent of archiving anything that is older than a year old. If itâs important itâll come up again.
Wow! Great comments and positive way of looking at things ! I think I just sparked a bomb with this thread and its exploding with a lot of positive comments. This definitely has boosted my energy and changed my perspective. Thank you all for your super helpful comments, suggestions and advices. Am really over whelmed and appreciate each oneâs time and effort in contributing to this thread and post. God bless you all!
