How we incorporate product feedback at PeopleDoc
Est. Read Time: 3 min.
Here at PeopleDoc, I’m responsible for our Employee File Management and eSignature applications. Along with my colleagues on the Product team, who are in charge of other applications, we receive a lot of feedback about how to make our HR SaaS product better.
Receiving feedback and feature requests is very valuable for us. We’re a relatively young company, still with a startup mindset, providing something new, an "HR Service Delivery Platform," and as a result our roadmap is strongly based on the conversations we have with our clients. However, for the person who submits the request, it can seem as though it’s not worth the effort if it doesn't lead to a change in the product.
In this post, I will explain how we deal with feature requests or product feedback at PeopleDoc and how we make sure your feedback is heard. I hope it encourages you to continue to share your ideas with us.
How we collect feature requests
At PeopleDoc, we collect feedback from a lot of different sources and channels, which include:
- Client / User feedback
- Internal feedback
- Voice of the market feedback
And we have different channels to receive and respond to this information:
- Internal ticketing tool
- Support Portal
- Face to face communication
We collect a lot of feedback from our clients and our users. Being in a B2B context, it’s more accurate to say that we collect a lot of feedback from our buyers and a little less from our users. Our buyers are the people at a company who decide to buy our solution and who are responsible for its implementation. Whereas our users are the actual people using it. Sometimes a buyer is a user, but the other way around is more rare.
We collect this feedback either directly when we meet a client or via our support portal (accessible via the Support button on the right hand of the screen for most of our users). The support portal contains a customer community, where we encourage users to share their feature requests and discuss and vote for some requests that are not theirs. The product owners at PeopleDoc interact with the community to challenge some of the ideas and respond to the requests. To engage more with our users, we are considering integrating tools like Hotjar in our product to have a more direct conversation with them.
Alongside our clients, a lot of our own staff will submit requests. Sometimes it’s on behalf of clients. For example, when a project manager meets with a client as part of the implementation phase, they might learn about an interesting use case that we do not cover yet. Sometimes, we ask the project manager to go back and get more information about why this is important to the client. This feedback is collected via a feature request form (basically asking what, who, why, and how). Or, it’s collected face to face, by email or in Slack.
How we reply
PeopleDoc is a Software as a Service (SaaS) platform. This means two things: the product is the same for everyone and it’s accessed via a web browser as the software is hosted on PeopleDoc's servers. Therefore, we can't say yes to every feature request. Instead, we have to weigh feedback from every customer and balance that feedback with our plans already in place to advance the product.
So, how do we reply to a feature request? As a rule of thumb, to agree on adding a new feature, we have to be convinced that it adds value to the product. I’m not in HR, it is true, but if the feature is important enough to be incorporated into the platform, its value proposition should be clear and everyone should be able to understand it.
A second criteria in our SaaS world, is "would this feature benefit our other clients?" As the code behind our platform is the same for everyone, if we invest time and money to bring a feature to life, we need to make sure that the use case is shared by other clients and that our approach to addressing the need is relevant to them as well. Plus, we try to get a sense of the effort required to build what has been asked. If the effort is too big and will require of a lot of development time, maybe it should not be our focus right now. If it’s a relatively small effort, like a sprint, maybe it’s worth it.
With these three criteria (see also the Intercom article on this method), we can answer a feature request with one of three answers.
Our three responses to feature requests
The first is less easy to say but it’s "no." No because the feature requested does not add enough value right now or it’s too specific as of today. I added "right now" or "as of today" as I believe the answer to a request changes according to the maturity level of the product as well as the product/market fit. Obviously, when we say "No" to a feature request, it is tough. But, we need to prioritize features that will have the most impact for all of our customers.
Our second answer is "Yes, we will add it in the next three months." We make a commitment when it’s a quick win or something that we really need to do for our business. The effort it will take us to release this feature is relatively low in comparison to its benefits. Once the feature is released and communicated to our users, we inform the person who submitted the feature that it’s available.
Our last answer is "Yes, later." It’s our most common answer and probably the most fuzzy for the requestor. This means that we believe the request to be a very valuable feature for the platform, but we can’t commit the resources to build it right now based on our other requirements. In this case, the feature is added to our roadmap, as it fits the vision we have for our product, and it will be built into future sprints when we have the capacity to handle the request.
How we process the feedback we receive
When we reply "Yes" or "Yes, later" to a feature request, we synchronize our tools to transfer it to Product Board, a tool we use to gather all these inputs. We summarize the feedback into a use case (e.g., “As an HR user, I want to____because____”). This use case is then grouped to related use cases.
We then have a list of different use cases that we do not cover yet. At this stage, we group them according to where they fit in with our product vision. For example, with the Employee File Management module our product vision is "Provide a global and easy-to-use solution that stores all HR documents and makes them easy to search while being out-of-the-box compliant." This connects with PeopleDoc’s goal to create a product that is compliant, user-friendly, connected, global, and scalable. When I work on the short and mid-term roadmap for Employee File Management, I assess the use cases against these goals and the product vision.
SummaryIf I had to summarize how we deal with feature requests at PeopleDoc, I would say:
- The more we collect, the better
- Challenge the need so our customers get the most value in the end
- Evaluate the impact of the request and the resources required to build it
- Answer "No", "Yes, later," or "Yes"
- Gather and group the requests
- Review them when working on our roadmap
Want to learn more about our approach to building HR technology? Read all about our exciting new innovation lab, PeopleDocNext.
You May Also Be Interested In:
About Julien Herbin
Julien Herbin is a Product Line Manager at PeopleDoc. He manages the technical and functional aspects of PeopleDoc Employee File Management. As part of his role, he works hand-in-hand with R&D, gathers product feedback from the field and communicates internally about new features. Prior to PeopleDoc he worked as a Product Manager at Criteo and Liligo.com. He has a masters degree in Computer Engineering, Computer Science, Project Management and Marketing.