How we work with user requests to develop Pyrus

Pyrus is a software that allows analysts, managers, and experts in various fields to automate their business processes, without having to program. Pyrus is also a business manager that most of its users use every day. We know that means our product must be functional, reliable, flexible, and user-friendly.

Feedback from our clients helps us develop our software every day. Our team examines every suggestion and request we receive, along with the company founder, Max Nalsky. Like any software company, our backlog of development goals exceeds production capability by dozens of times, so, unfortunately, we cannot make absolutely everything happen.

How we work with requests

First, we read them. All of them.

Then, we analyze and sort them. If we receive a request multiple times, we make it a priority. Sometimes, the answer is to develop a new functionality in Pyrus. We have to take into account the contradictions that requests often present, and build the new feature into the existing architecture and logic of the product. This is no simple task. We are hard at work on this every single week, doing our best to make Pyrus convenient, easily navigable, expressive, and chock full of capabilities.

The second step is to compile a user story: a Pyrus user’s described experience with our software. Even if the request has already been submitted as a specific technical task, we don’t start working on it until we fully understand the actual way it will be used. This principle is extremely important. Our case stories are highly detailed, and written in a very personalized format. For example,

John Smith is an assembler at a furniture manufacturing company. He uses Pyrus to register damaged parts, and, when the damage is above a certain level, he wants to be able to communicate with a counterpart department. He has set Pyrus to automatically connect the people he wants to his process when this happens, but he does not yet have the capability to receive notifications when his colleagues don’t respond within a certain time. If we solve this problem, John will be able to leave work 15 minutes earlier every day, and the damage level of his parts will drop an estimated 20%.

You — our users — can help us most effectively if you know how we work. If there’s something you would like to see added to the system, please describe the use scenario, and the problem you are looking to solve, in as much detail as possible (but not the solution you would like to propose, even if it seems obvious). We often contact the authors of requests to acquire additional information, and we are very grateful to them for their time. If we receive similar or overlapping requests from different sources, we make these developments a priority.

The next step is design. Our UX designers sketch out the elements of the interface and the mobile app, in the web version. Then, we discuss and finetune the design. We go through between 3 and 5 iterations. Then, in order of priority, and depending on our programmers’ workload, the task goes into development. Then, testing. Next, it is described in a memo, and goes out as part of our release. The release comes out every morning, or even several times a day, to get the features into production as soon as they are ready. Pyrus does not have a release schedule; new versions come out every day. We release some of the functions to a limited group of people at first (ourselves, and those who requested it), and only then does it become available to all users.

Finally, we inform the users of updates as they come out, in a monthly newsletter, and on Facebook. The most notable features are announced in System Announcements — to open, click on the bell in the upper right corner.

We have to admit that we will never be able to fulfill 100% of user requests. We have created Pyrus, and are developing it, as a software; this is the task on which our resources, which are not limitless, are focused. We have gone the application route for business development, and we are not offering our clients a custom-made software. However, our trusty partners are. We recently created the Professional Pyrus Users Group, where ways of solving highly specialized problems and software customization through extensions, scripts, API, and other tools, are being discussed.

Your daily experience using Pyrus is what we use to develop our product. Tell us more about yourselves, so we can make Pyrus work better for you. And thank you for being with us.