Product feedback is everywhere (but it shouldn’t be)

Note: As of 01/02/2019, this is the updated URL for the client-facing tweak sheet.

---

As a software company, one of our main tenets is to move swiftly. To be able to develop new features that meet our customers needs and to quickly fix bugs that come down the pipe, whether as a side effect or an overlooked detail. Early on, Rick has done a good job of documenting aspects of our Product Management cycle. For those of you who haven’t paged back that far in our Infused post history, I certainly recommend familiarizing yourself with posts about why our product management rocks, what it means to be an agile dev shop, and even the pitfalls that are all too easy to hit in product management.

It’s a main theme from that last article I want to harp on here: Feedback. I will always maintain that we as a tech team are welcoming of feedback, and I certainly hope our actions support that statement. The rub is just because we are open to it doesn’t necessarily mean it’s always a cinch to incorporate. For those of you who’ve been around long enough, I’m sure this isn’t news.

Having our new Director of Client Engagement onboard prompted to think even more deliberately about feedback. So I’ve put together a document called Simplifya’s Feedback Gameplan. Its purpose is to formally lay out the path that feedback should take through our company. And its benefit is two-fold: 1) Having everything go through the right channels prevents us from losing track of feedback and 2) When things don’t go through the right channels, it’s frustrating (and at times stressful) for everyone involved.

When writing this document, I wanted to highlight the following underlying ideals:

Bugs versus Suggestions

The one definitive line we draw when it comes to handling feedback is whether it’s a bug or a suggestion. In the vain of over-explaining, a bug is when something within the site that should be working, isn’t. Unlike bugs, suggestions can be taken at face value. A client (or team member) says they’d like to be able to do something that isn’t currently in the system. Maybe we leave it at that, maybe we vet it out a little more.

A bug, on the other hand, always requires more information. The truth is, if our tech team (or the devs) can’t replicate an issue a client is having, it’s not a bug. I don’t mean that in a “let’s gaslight the client” kind of way, but rather if we can’t replicate it, it’s just as likely to be something that doesn’t have to do with our app as something that does. That’s why we should always be getting as much diagnostic info as possible, as soon as possible.  The idea is to minimize the back and forth on OS, browser, time of day, action being performed, error messages, and therein save everyone valuable time.

Feedback is for everyone

Feedback isn’t relegated to just sales and client teams. It’s a part of the process that everyone throughout Simplifya is welcomed into. It’s worth mentioning that our rule of thumb is to prioritize ideas brought by clients first, but that’s not a hard and fast rule and it ultimately depends on the feedback itself. Anything that goes into our product should be weighed against our company vision and the impact it has on how we can better enable our clients with their regulatory compliance.

Setting expectations

It’s easy to “talk” about point number 2 above, but it’s another thing to walk the walk. The truth is that some bits of feedback might never see the light of day, while others might take months (referring largely to ‘suggestions’). The nature of feedback is it’s prioritized against all of the other feedback we’ve ever gotten AND new features (that’s how you get a “tweak sheet” of 100+ items). It’s a constant process, unwieldy as it may seem at times. And for our part, we want to do the best possible job of setting expectations.

So how do we make the most of our Gameplan?

For bugs, it should be pretty straight forward (see the diagram in the google doc), where it gets gray is with suggestions. As someone with suggestions:

• Start by searching our existing feedback sheet, it’s possible somebody might have already added it. If your suggestion has already been added and it comes from a client, you can add that client’s name to the “Source” column. If it hasn’t been added, please add it, making sure to follow the “Sheet rules”.
• If you’re wondering about feedback you’ve already put in, check the feedback sheet as well. If your feedback has been incorporated and released, you’ll find it in the sheet marked ‘resolved’. If not, you’ll at least likely see a rough prioritization of it. Secondarily, be sure to check out our internal and external release notes or hop into the New Feature Demos.

One last overarching point when it comes to product suggestions: It’s unrealistic for us as the tech team to constantly report back on suggestions that were made (hence the teaching everyone to fish). The one exception I’ll make to this rule is within the “Client & Prospect Feedback” meeting.

It’s no easy thing maintaining our product vision. Taking all the inputs from various places and departments, and turning around a software that is a picture of usability. And it might seem simple, but it’s just as easy to map out a feature set that misaligns with a (our) company vision as it is to map out one that is. Ultimately, we’re only as good as the features (and feedback) we take back in.