Ask HN: How do I get my PM to stop using Excel to track bugs?
They swear by it, I hate it. Any recommendations?
41 comments
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.
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.
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.
Bonus points when you build him a excel exporter for github issues.
Bonus points when you build him a excel exporter for github issues.
Simply saying "No" and not understanding another's view point is a missed opertunity. Intuition of process or technology "XYZ" is not the same for everyone. Understanding how to guide Users to a more efficent workflow is half the battle.
more like "no, this is making us all suffer except you" kind of way
Words of wisdom!
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.
These are some of the Qs I’ll ask:
1. How do you use Excel to track bugs? (Trying to understand his/her workflow.)
2. How does Excel solve your problems? (Understand what s/he likes about Excel.)
3. What are some of the things you wish Excel can do better? (Understand pain point)
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.
I’ve also seen PMs enjoying using Coda as a complement to GH/JIRA to get a better picture to project overview.
These are some of the Qs I’ll ask:
1. How do you use Excel to track bugs? (Trying to understand his/her workflow.)
2. How does Excel solve your problems? (Understand what s/he likes about Excel.)
3. What are some of the things you wish Excel can do better? (Understand pain point)
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.
I’ve also seen PMs enjoying using Coda as a complement to GH/JIRA to get a better picture to project overview.
Definitely agree: come from a position of empathy for why the PM chose excel.
Spreadsheets offer a lot to PMs that tools like GitHub, JIRA simply can't:
- Bulk editing quickly
- Very high information density for getting a "bird's eye view"
- Excellent keyboard command support for fast navigation
- Formatting capabilities to add metadata (using colors, bolds, etc.)
- Flexibility to easily add columns for ad-hoc analysis
- Control over what information to show (via hidden columns & row filters)
- It's a 'least common denominator' product that can be shared with others across departments without fuss
- Ability to make things "look pretty" to enhance the perception of your work
- Editorial control -- to shift dates & language based on the intended audience
In short, the data governance you get from systems like GitHub and Jira are fantastic for keeping things from getting disorderly. But with all due respect to them (GitHub CEO Nat Friedman is an investor of ours), people working with data in these apps need speed & flexibility that only a spreadsheet can offer.
It was for this reason that my company pivoted. We discovered that users preferred working in spreadsheets, but they tried (and failed) to integrate data from Jira, Salesforce, HubSpot, and others.
We set out to build the world's first spreadsheet that was designed from the ground-up for working with integrated data. We wanted to cut out the third-party integrations & field mapping headaches.
If you'll pardon a little self promotion, check out our product: https://visor.us
Or (newly) here on the Atlassian marketplace: https://marketplace.atlassian.com/apps/1226209/visor-flexibl...
Your data could ultimately live in Jira, but the PM could get the spreadsheet capabilities they need. Feedback and ideas welcome.
Spreadsheets offer a lot to PMs that tools like GitHub, JIRA simply can't:
- Bulk editing quickly
- Very high information density for getting a "bird's eye view"
- Excellent keyboard command support for fast navigation
- Formatting capabilities to add metadata (using colors, bolds, etc.)
- Flexibility to easily add columns for ad-hoc analysis
- Control over what information to show (via hidden columns & row filters)
- It's a 'least common denominator' product that can be shared with others across departments without fuss
- Ability to make things "look pretty" to enhance the perception of your work
- Editorial control -- to shift dates & language based on the intended audience
In short, the data governance you get from systems like GitHub and Jira are fantastic for keeping things from getting disorderly. But with all due respect to them (GitHub CEO Nat Friedman is an investor of ours), people working with data in these apps need speed & flexibility that only a spreadsheet can offer.
It was for this reason that my company pivoted. We discovered that users preferred working in spreadsheets, but they tried (and failed) to integrate data from Jira, Salesforce, HubSpot, and others.
We set out to build the world's first spreadsheet that was designed from the ground-up for working with integrated data. We wanted to cut out the third-party integrations & field mapping headaches.
If you'll pardon a little self promotion, check out our product: https://visor.us
Or (newly) here on the Atlassian marketplace: https://marketplace.atlassian.com/apps/1226209/visor-flexibl...
Your data could ultimately live in Jira, but the PM could get the spreadsheet capabilities they need. Feedback and ideas welcome.
At a glance, Visor looks very nice. Does it let you mark an issue as blocked on more than one issue? I love using spreadsheets to track issues but for me that's the biggest pain point.
Thanks for the compliment!
Yes! You can copy & paste values in bulk and then sync back to Jira. So you could copy the "Blocked" status from one cell and drag it down to the others.
In the interest of trust and transparency, those changes don't get synced out to Jira right away. There's a Sync button you can press to apply those changes all at once.
Cells with pending changes have a little indicator on them. And you can always go back and revert your local (uncommitted) changes.
Yes! You can copy & paste values in bulk and then sync back to Jira. So you could copy the "Blocked" status from one cell and drag it down to the others.
In the interest of trust and transparency, those changes don't get synced out to Jira right away. There's a Sync button you can press to apply those changes all at once.
Cells with pending changes have a little indicator on them. And you can always go back and revert your local (uncommitted) changes.
Use PowerQuery in excel to pull down issues from GitHub/Jira/Trello via the API.
Let the PM have their spreadsheet, you can do everything where you want, but they can still track everything in a spreadsheet.
Let the PM have their spreadsheet, you can do everything where you want, but they can still track everything in a spreadsheet.
Yes, this solution make sense. Find a way for them to get the issues into Excel.
I've experienced this before; my recommendation would be to pitch an alternative tool to the PM based on how that tool would make the PM's job easier / more effective. 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.
What Excel won't do, without significant work (which will almost certainly fall to the developer and not the PM):
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?
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?
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?
Don't fight them - sell to them. Explain why a different solution will be better for them and you.
What Excel won't do, without significant work (which will almost certainly fall to the developer and not the PM):
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?
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?
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?
Don't fight them - sell to them. Explain why a different solution will be better for them and you.
Counterpoint: many of those features are unnecessary, especially on a smaller team and an intentionally simple tracking tool can force simple development processes. It’s neither good nor bad - it’s a question of whether or not the tool fits the environment.
Excel based bug tracking certainly has its place. So does Jira and similar.
Excel based bug tracking certainly has its place. So does Jira and similar.
There are some good suggestions here.
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.
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.
How much pain is this really causing you?
How much potential damage are they likely to do when their Hindenburg does finally run aground?
How far are you willing to go to try to help them do their job better?
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.
Figure out where that point is first.
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.
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.
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.
How much pain is this really causing you?
How much potential damage are they likely to do when their Hindenburg does finally run aground?
How far are you willing to go to try to help them do their job better?
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.
Figure out where that point is first.
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?
Kidding but not.
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.
Kidding but not.
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 used Jira at my last job. It has it's disadvantages as well. I think the main issue I'm having is how my PM is trying to cram all the relevant data into the spreadsheet. It wouldn't be as bad if he spent some time working on formatting, but it's still ponderous when complicated repro steps and screenshots are involved.
JIRA is better than ZOHO pain I had to endure for few months. Still probably worst software out there. A well structured spreadsheet might even be better for a small tightly knit team.
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.
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.
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.
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.
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.
Just do it with enthusiasm. After honeymoon period is over, people will stop updating the Excel sheet proactively and its usage will stop by itself
If you want to change someone’s behavior/strategy, give them an easier and more pleasant one achieving the same result / meeting their needs.
Give the PM something that makes it even easier - than excel - for them.
What’s easier for data entry, sorting, filtering? Maybe a google spreadsheet providing effortless updates for everyone?
Anything with more friction than a spreadsheet will be a tough sell.
Give the PM something that makes it even easier - than excel - for them.
What’s easier for data entry, sorting, filtering? Maybe a google spreadsheet providing effortless updates for everyone?
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"
Which did not go well with guys who proposed it
Basically get confidence of team members before opposing or otherwise.
Which did not go well with guys who proposed it
Basically get confidence of team members before opposing or otherwise.
Good advice. Thanks!
[deleted]
If they’re any good they’ll listen to your (reasonable) objections and consult the team for the best way forward.
Give them some good reasons why it’s a bad idea, and the best solution you see that fixes those problems.
Give them some good reasons why it’s a bad idea, and the best solution you see that fixes those problems.
Talk to them and then talk to the person that pays them. Have a proposed workflow and explain why it’s better/necessary for the business.
Don't unless you want to get yourself a side project that imports Excel spreadsheet to something else.
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.
you hired someone on upwork to build the plugin?
no i convinced IT team to create excel plugin
Act an idiot and break it every few days. Eventually he'll be sick of it.
Negotiation skills. Let’s start off with this: Why do you hate it?
Mainly due to his implementation. He essentially uses it as a enhanced checklist. The specific pain points on my end are mainly focused around needed data on my end. It would be nice to have historical discussion of the issues, more room for repro steps, and don't even get me started on screenshot storage.
I think what I need to do is recognize that the spreadsheet is not for me and just a checklist for the PM. I need to use whatever system I see fit on my end and update the appropriate column in the spreadsheet when necessary.
I think what I need to do is recognize that the spreadsheet is not for me and just a checklist for the PM. I need to use whatever system I see fit on my end and update the appropriate column in the spreadsheet when necessary.
Put the pain on the decision maker.
If you need repro steps or the discussion, then each time they are missing from the spreadsheet, ask the PM to find them for you.
Either the PM changes to another system, or they figure out how to handle your needs in their current system.
If you need repro steps or the discussion, then each time they are missing from the spreadsheet, ask the PM to find them for you.
Either the PM changes to another system, or they figure out how to handle your needs in their current system.
Ha ha I was going to say those exact words - I almost thought this was my comment that I forgot I wrote.
Do you have to use it at all?
Or just look at it on occasion?
Do you work in 1983?
Or just look at it on occasion?
Do you work in 1983?
Yes, I have to use it to track tasks assigned to me.
i'm assuming you hate it just b/c it's ugly and therefore sucks.
i just left a job that loved spreadsheets of all kinds, and i hated them, but it was mostly because they duplicated information held elsewhere, and were used as the system of record for production configuration - with umpteen rows and sheets, and required prolonged and tedious and ongoing manual updates from me, and of course nobody kept them up to date - and i felt like such a back-asswards company deserved a much worse employee than me (if that's possible).
so i get the hate.
but can't say i like jira or any of the others.
i think some business analyst-types - your scrum master - just come from the spreadsheet world so that's where they're comfortable. probably they've never used a bug tracking tool. maybe find a youtube demo and point them to it.
some PMs will copy all the issues out of jira every day or every other day or every week, manually update everything, update things as the meeting progresses, etc. that's just how they roll.
if it's not actually painful for you, i'd say just roll with it.
if it actually requires significant pain, then just talk to them about it. see what the other PMs are using. ask your PM why they are using The Sheets and not specific-use software.
maybe there's a middle ground -- you could use some other monstrosity like notion or smartsheet or airtable.
;-D
just kidding. excel/sheets is not a monstrosity - it's legit useful for some things.
i just left a job that loved spreadsheets of all kinds, and i hated them, but it was mostly because they duplicated information held elsewhere, and were used as the system of record for production configuration - with umpteen rows and sheets, and required prolonged and tedious and ongoing manual updates from me, and of course nobody kept them up to date - and i felt like such a back-asswards company deserved a much worse employee than me (if that's possible).
so i get the hate.
but can't say i like jira or any of the others.
i think some business analyst-types - your scrum master - just come from the spreadsheet world so that's where they're comfortable. probably they've never used a bug tracking tool. maybe find a youtube demo and point them to it.
some PMs will copy all the issues out of jira every day or every other day or every week, manually update everything, update things as the meeting progresses, etc. that's just how they roll.
if it's not actually painful for you, i'd say just roll with it.
if it actually requires significant pain, then just talk to them about it. see what the other PMs are using. ask your PM why they are using The Sheets and not specific-use software.
maybe there's a middle ground -- you could use some other monstrosity like notion or smartsheet or airtable.
;-D
just kidding. excel/sheets is not a monstrosity - it's legit useful for some things.
Ugly has very little to do with my pain points. My issue is that he uses it mainly as an info dump for his personal tracking and it's not very well set up for use from a development perspective. It's essentially just a multi-column checklist. I'm starting to think I may be better off tracking issues assigned to me using whatever system I choose and then just updating the "complete" column on his end when appropriate.