Ask them why they like it, and really listen to their answers. Ask yourself why you hate it, and contrast it with the PMs needs. Then have a discussion together.<p>I tend to agree that Excel doesn't seem like the best tool, but at the same time, Jira is a mess of overkill for many projects, and some dev teams swear by that. I suspect there are simple tools out there that could make everyone happy, but you need to have discussions as a team of what all your needs are and agree on a solution together.
Sometimes a team should just collectively say "No" to a PM. And not in a "you are a moron"-way, but in a "this is not how it is done in the trade"-way.<p>Bonus points when you build him a excel exporter for github issues.
Interesting one. I might approach it by trying to understand it from the PM’s point of view, and see if there is an even better solution than Excel.<p>These are some of the Qs I’ll ask:<p>1. How do you use Excel to track bugs? (Trying to understand his/her workflow.)<p>2. How does Excel solve your problems? (Understand what s/he likes about Excel.)<p>3. What are some of the things you wish Excel can do better? (Understand pain point)<p>Part of this is also building trust, so the PM can see your workflow & use cases as well, and hopefully come to a conclusion that while Excel may work, it’s really not the best tool for the job due to manual data synchronization work, and maybe GH issue or JIRA would work better.<p>I’ve also seen PMs enjoying using Coda as a complement to GH/JIRA to get a better picture to project overview.
Use PowerQuery in excel to pull down issues from GitHub/Jira/Trello via the API.<p>Let the PM have their spreadsheet, you can do everything where you want, but they can still track everything in a spreadsheet.
I've experienced this before; my recommendation would be to pitch an alternative tool to the PM based on <i>how that tool would make the PM's job easier / more effective</i>. It's probably true that almost anything would be better suited to the development workflow than an Excel spreadsheet - but in this particular use-case, Excel is fulfilling your PM's requirements: it's keeping track of issues.<p>What Excel won't do, without significant work (which will almost certainly fall to the developer and not the PM):<p>Track issue history / comments / activity against a repository. Wouldn't it be better for your PM to be able to identify, at a glance, exactly which branch & commit a particular fix or change is in?<p>Integrate with your CI / build system: Wouldn't it be better for your PM if issues were automatically marked as 'ready to test' when the relevant build is completed?<p>Provide a workflow against the list of active issues. Wouldn't it better for your PM to rest assured that any incoming issues are easily triaged & assigned within a well-defined workflow that tracks an issue from first-report to completion & sign-off?<p>Don't fight them - sell to them. Explain why a different solution will be better for them <i>and</i> you.
There are some good suggestions here.<p>But one thing I’m not seeing is any mention of the fact that asking someone else to stop doing something that you know to be stupid but they think works wonders for them, well that’s a path that is fraught with much pain, wailing, gnashing of teeth, and frequently little success.<p>So, before doing anything else, I would encourage you to take a long hard look at your side of the equation, since that’s all you can really control.<p>How much pain is this really causing you?<p>How much potential damage are they likely to do when their Hindenburg does finally run aground?<p>How far are you willing to go to try to help them do their job better?<p>At some point, you’ve got to decide to fish or cut bait. Decide to either go somewhere else, or just live with it — while protecting yourself as much as you can.<p>Figure out where that point is first.<p>Periodically keep coming back to this question and make sure that point is still in the same place, or how it has moved if it has done so.
Arguing won't work. Find a better solution, make it work so that it is easier, etc than Excel and only then suggest it to the PM. If that's too much work, then just grin and bear it. There are more important things in life than arguing with PMs.
Ask them to use google spreadsheets?<p>Kidding but not.<p>Jira doesn’t always make fixing bugs easier, sometimes it’s just another bullshit SaaS login that your PM forgot, so he’s making a nice simple list, in a spreadsheet, like Steve Jobs would do in an Apple II running VisiCalc in 1982.
I mean, shouldn’t the bugs be kept closer to what they’re concerned with? Why not JIRA, Azure DevOps, GitHub Issues, etc.? I assume the code repo has some supplementary bug tracking feature.<p>Their “swears by it” just sounds like laziness or perhaps a poor UX in the existing tool. Either way, working in an Excel just sounds like unnecessary decoupling and a higher barrier to work with.<p>But also, it could just be a garbage PM. I’ve met tons of product folk that are in it just for the money and can’t ACTUALLY manage a team or product.
If you want to change someone’s behavior/strategy, give them an easier and more pleasant one achieving the same result / meeting their needs.<p>Give the PM something that makes it even easier - than excel - for them.<p>What’s easier for data entry, sorting, filtering? Maybe a google spreadsheet providing effortless updates for everyone?<p>Anything with more friction than a spreadsheet will be a tough sell.
You need to understand their workflow and suggest friction free interfaces to migrate to a process that helps you too. This issue can be with any User & software combo not just a PM. If you can't get through UAT/UA (User Acceptance Testing/ User Adoption) then no matter how perfect a solution you make, it's irrelevant.
I have been to similar situation, when a manager asked tech team to prepare a excel sheet to maintain github commits...
Me: "what, WTF. commits can be tracked on github itself, and we do not need to maintain excel sheet"<p>Which did not go well with guys who proposed it<p>Basically get confidence of team members before opposing or otherwise.
If they’re any good they’ll listen to your (reasonable) objections and consult the team for the best way forward.<p>Give them some good reasons why it’s a bad idea, and the best solution you see that fixes those problems.
i got excel plugin created that can be used to sync(both ways) to the bug database. PM's could continue to use excel and we were able to use bug databse. Since their workflow was not affected they did not had much to disagree with me.