Bonus points when you build him a excel exporter for github issues.
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.
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.
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 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.
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.
Or just look at it on occasion?
Do you work in 1983?
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.
Let the PM have their spreadsheet, you can do everything where you want, but they can still track everything in a spreadsheet.
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.
Excel based bug tracking certainly has its place. So does Jira and similar.
Which did not go well with guys who proposed it
Basically get confidence of team members before opposing or otherwise.
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.
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.
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.
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 them some good reasons why it’s a bad idea, and the best solution you see that fixes those problems.
