Answer
Start by listing the actual tasks people need to do rather than their job titles, since a developer troubleshooting a performance problem and a developer building a new interface may need very different tooling even though both carry the same title. Query and performance tools for administrators and developers usually assume comfort with SQL, file relationships, and sometimes the RPG or COBOL programs that originally created the data, while reporting tools for analysts and business users assume none of that background.
Buyers should also consider a middle group that often gets overlooked: power users in finance or operations who are comfortable with spreadsheets and want more flexibility than a locked-down report but do not want to learn SQL or navigate raw Db2 for i schemas. That group is frequently underserved by platforms built strictly for one extreme or the other. Piloting the shortlisted tools with a representative from each group, not just the IT team, is the most reliable way to confirm the platform actually fits how each audience will use it day to day.