Print Software Feature Requests: You’re a Priority, Just Not the Only Priority
Feature requests are popular. The default response to new software to ask for it to be changed to fit the way you specifically think it should fit into your specific environment. “Change your processes to optimize your use of the software” is the one statement that would save the print industry millions of dollars.
Our mission is to provide cogent commentary and analysis about trends, technologies, operations, and events in all the markets that comprise today’s printing industry. Support our mission and read articles like this with a Premium Membership.
Jennifer Matt is the managing editor of WhatTheyThink’s Print Software section as well as President of Web2Print Experts, Inc. a technology-independent print software consulting firm helping printers with web-to-print and print MIS solutions.
Thanks Jennifer, this is true for all software, not limited to web-to-print or job tracking. The most useful thing a customer can do is to describe exactly what they are trying to achieve, what they’ve tried and what happened when they did … and then answer the additional questions that the vendor will ask as clearly and concisely as possible. Do that and the support team and developers will love you. They may be able to tell you how to use some other existing feature of the product to achieve what you want. And if they can’t they’re much more likely to add or tweak a feature for you, because they can figure out precisely what they need to do!
Jennifer, I suspect that few printers adopt a formal user requirements specification process when selecting software - is this your experience? I'm talking about identifying and documenting high-level 'epics' and user 'stories' (e.g. "as a CSR, I need the new system to display job numbers and specs sorted by due date..."), with a priority assigned to each of them by, for example, the MoSCoW method. (Must have, Should have, Could have, Won't have.) This kind of formality avoids some of the problems you are describing, and forces the buyer - as Martin implies - to specify in detail WHAT they want to achieve and not HOW it should be achieved.
Discussion
By Martin Bailey on Jan 20, 2021
Thanks Jennifer, this is true for all software, not limited to web-to-print or job tracking. The most useful thing a customer can do is to describe exactly what they are trying to achieve, what they’ve tried and what happened when they did … and then answer the additional questions that the vendor will ask as clearly and concisely as possible. Do that and the support team and developers will love you. They may be able to tell you how to use some other existing feature of the product to achieve what you want. And if they can’t they’re much more likely to add or tweak a feature for you, because they can figure out precisely what they need to do!
By Chris Lynn on Jan 22, 2021
Jennifer, I suspect that few printers adopt a formal user requirements specification process when selecting software - is this your experience?
I'm talking about identifying and documenting high-level 'epics' and user 'stories' (e.g. "as a CSR, I need the new system to display job numbers and specs sorted by due date..."), with a priority assigned to each of them by, for example, the MoSCoW method. (Must have, Should have, Could have, Won't have.)
This kind of formality avoids some of the problems you are describing, and forces the buyer - as Martin implies - to specify in detail WHAT they want to achieve and not HOW it should be achieved.