Understanding the Software Feature Request

When you ship a print job, it’s a final product. If the customer wants a change, it’s called a “redo.” If you made a mistake; it’s called a “redo on your dime.”

When you ship a software product and the customer wants a change, it’s a called a “feature request.” If software has a mistake “bug” it’s called a “bug fix,” and if it’s your custom software, you pay to fix it. If the bug is in commercial software, you report it, and it may or may not get fixed in a timely fashion—or ever at all.

Software is nothing like print.

The software feature request is a fascinating thing that I’ve spent way too long thinking about.

As printers utilize both commercial software and build custom software throughout their businesses to differentiate their offerings by solving customer challenges, or automate labor intensive steps in their workflows, the printer is both an entity that makes software feature requests to their vendors and receives feature requests from their clients.

If you’re constantly accepting feature requests, is software ever done? No.

Commercial software that you are either paying maintenance on or a monthly subscription fee on is never done because the business model you signed up for requires a continuing stream of value-exchange. You pay your monthly subscription and they keep improving the software. You pay your annual maintenance, they keep improving the software. Software doesn’t really have a choice but to keep moving. Any modern software has to keep doing some minimal adjustments to stay compatible with the technical environment it runs in. Web browsers keep updating, security is in constant flux, and the business process the software performs in is not static. How many printers out there have held onto software packages until the bitter end, when you couldn’t even find old enough computers on eBay to run ancient operating systems?

The Printer as the Feature Requestor

The commercial software running your print business (Print MIS, web-to-print, pre-press automation) has a business behind it which employs a group of people to look after that software. There is support and sales, but behind the scenes are people who are planning the next releases, fixing the bugs and prioritizing the feature requests. 

I always like to say that buying software is like buying a train ticket where you believe in the direction and speed of its travel. As the software train moves, it solves additional challenges. That’s how I think printers should think about feature requests—they should be re-named “solve this challenge request.” 

Software is a powerful tool that can be used to solve problems. The software end-user isn’t typically the best person to decide how to solve something (suggest a feature); they are usually in a position to describe the challenge they are having (solve this challenge request). 

Here are five things that will make you a better “solve this challenge” requestor:

Clearly describe the problem you are having. Include who is having it (humans), what they are trying to accomplish and what obstacles they are encountering.

If this challenge is solved today using labor-intensive, offline methods, describe how its done today (without software).

Don’t suggest a solution. (I know it’s really hard because you think you know exactly how you want it solved.) Example: “We need a drag and drop solution to X.” Please don’t say that to anyone. I’m not saying to forget that idea. I’m saying don’t include it, because the people who built the software might just come up with a better way to solve it. Why is this a good idea? Their idea might be a configuration change, your idea might require professional services, customer development and cold hard cash out of your pocket.

Include a “why” in your description of the challenge. What results do you want to experience when this challenge is solved? 

Tell the vendor that you are willing to adjust your workflow if necessary to solve the challenge. People workflows are a lot cheaper to adjust than software. Too many printers waste precious cash resources on software customization because they erroneously assume they have to keep their people processes intact. Large companies have gone into bankruptcy because their SAP implementation went off the customization rails. Ask two question about your workflow: Does it create unique differentiation for your clients? Does it save tremendous amounts of time and labor that greatly decreases your costs? If the answer is no to both of these, then change the people processes to fit the software. It’s cheaper.

What happens when the tables are turned and you as the printer are now receiving feature requests for a software product you provide to your clients?

The Printer as the Feature Request Receiver

When printers buy software or build customer software, they often think about it in terms of print. “I purchased a software product that is done.” Then they deploy that software product to their clients who ask for feature requests. This makes many print sales people nervous because they aren’t comfortable with software. When people who aren’t comfortable with software get feature requests, they make a lot of expensive mistakes.

They say yes to every feature request—erroneously assuming the customer is right. They react as if a feature request or even a bug report is a failure like a misprinted job that needs to be redone at no cost. Software isn’t like print. Every software product has hundreds of known bugs. Larger ones have thousands of known bugs. Just because your customer asks doesn’t mean you have to do it. There are real costs to changing software.

They note the feature request without understanding what it’s trying to solve . We worked with a printer whose customer was demanding 20+ very detailed custom reports from the Print MIS. When we asked what problem they were trying to solve, we recommended one custom query into the database that could be updated dynamically. This took about two hours to configure and exceeded their expectations. The 20+ reports would have cost the printer thousands of dollars in consultation fees. It is almost impossible for an end user of a software product to know enough about the challenge to select the optimal solution to a challenge. (It does happen but it’s the exception).

The printer is constantly frustrated because software feels like a moving target that never has a “done” stage. This is only getting worse. With multi-tenant applications, cloud hosting, software companies now have the infrastructure to constantly change their software. This is setting the expectation of all consumers that software changes are as easy as editing a white board. If you’ve paid for custom software, you know that isn’t true. Good software is expensive to build because it takes a team of highly qualified individuals to work in coordination. Think about it: good software is like hiring a team of doctors to collaborate on how to best solve your challenge. It’s getting easier due to the components you can license so you don’t have to start anything from scratch, but it still takes that premium labor to make it happen.

Don’t treat software like print. It is a train ride, not a destination. Software is never done.