Today I am speaking with Jeremy Glassenberg, a Platform leader and original PM for the Box platform.
What are the channels used to capture user feedback?
For user feedback post-revenue, B2B can seem very straightforward because customers will clearly communicate what they need. Everyone who interacts with those customers is a channel of feedback to the product, especially Sales and Customer Success. Of course, good Product Managers know that you shouldn’t just build what customers request — you need to understand their problems, their pain points, and work with them to find a great solution.
A key channel of feedback is coming from the sales team, which your potential and existing customers are directly giving them.
Remember you don’t want to be reactive to what the customer is asking for.
There is a term “sales-driven,” which your company should avoid. Enterprise companies have a bad habit of eventually letting that happen and can lose track of the long-term vision for short-term revenue. You also need other data points besides customer feedback, such as market research, competitive analysis, and encouraging a culture of creativity.
How did you structure feedback from the sales team?
The Sales team consolidated their requests, showed patterns in customer requests and helped us understand what people seemed to want. We were lucky to have a team that coordinated and communicated well with Product. They didn’t over-promise features or delivery dates to customers. They also understood that a company shouldn’t be 100% sales-driven, and considered long-term positioning along with near-term revenue opportunities. They knew at times that even if a great deal came along, if the demands were too one-off or not a fit with our business model, it was OK to move on.
One of the most important pieces to Box’s growth strategy was the establishment of a Sales Engineering team, who could help interface between product and sales.
Among the many responsibilities of Sales Engineers is is talking to customers, getting feedback and then identifying patterns and trends to surface to the product managers. Good Sales Engineers know how to identify customer problems and evaluate solutions, just as is needed in Product Managers.
In Box’s early days, when there was a Sales team of less than 10, team members could talk to Product Managers and engineers directly. We needed to add structure as the company grew, requiring Sales to talk to Product rather than directly talking to Engineering, so that we could prioritize requirements and reduce distraction during development. Over time, the requests from individual sales members couldn’t keep up with the PM’s job, but Sales Engineering stepped in to help organize and prioritize the needs of Box’s customers.
I commonly see companies interested in having a feature request form, so that anyone in the company can easily submit ideas to the Product team. While seemingly a good idea, in practice, I haven’t seen it used. People need to interact with co-workers more directly, so the process of sharing and listening to problems and ideas can’t be supplemented well with a form.
How did you set guidelines for sales people on how to handle product requests from customers?
We made some ground rules regarding this which were very important for the success of the company and product. These are issues that can cause friction between Sales and Product, as Sales aggressively pursues revenue, while Product is making sure the company is well positioned for the long-term. At Box, we were lucky to have a great Sales team and leadership that supported these principles.
Two of the rules we had were:
- Don’t over promise — Don’t tell the customer that you can build anything to get the deal closed. Know what we have, know what we don’t have.
- Don’t immediately say no — On the other hand, when a customer is asking for a feature we aren’t yet ready to provide something we don’t have, the answer isn’t necessarily “no.” Rather, it was more common to say “let me get back to you on that,” check with the Product team, and see what we can do near-term and down-the road.
In Box we had utilized the platform as a flexible solution to customers. So when a customer asked for something we haven’t officially built , we could make something work really well through the flexibility of our platform. Sometimes, in a matter of hours or days, we could come back with plans and a working prototype. Then, the customer could build, modify, maintain and update the custom solution with their own engineers.This way, we didn’t have to put all the work on our own engineering team for every customer need.
How did you structure feedback from the customer support team?
At different companies I’ve seen different responsibilities for the Sales team, Sales Engineering team, Support team, etc, but usually Sales bring knowledge of users who want to use your service, while customer service brings the knowledge of individual users as they work with your service.
Experienced customer service reps can organize requests, and identify patterns and trends in customer requests.So I would actively reach out to the team for feedback, and as we got more organized, created a system where customer service could organize feedback and relay trends in customer needs.
Product managers should always have access to Zendesk or whichever tool your support team uses so they can send you a ticket to review.
How did you structure your communication with other teams?
Communication is very important for product managers. How you structure communication depends on the size of the company. Once a company size crosses 20 employees, teams formalize and communication channels between these teams really need to be in place.
When we had 1–3 sales engineers we could set up meetings casually. When it became a team we established a consistent meeting time to get their feedback and to evaluate the latest questions that were coming in from customers to discuss possible solutions. We would block 1–2 hours for that meeting.
It’s very common for product managers to give out a vibe that they are not listening to people, often unknowingly and unintentionally. Invest as necessary to absolutely make sure this doesn’t happen. I’ve sometimes seen Product Managers actually avoid contact with Sales to protect the company from becoming sales-driven, or to prevent oneself from getting distracted. Instead, you should work with Sales to set guidelines on how to work with customers and with Product.
During the day you are getting thrown around and sometimes you have to say, “Sorry, I can’t take that right now” to get some work done, but make sure it’s not in any way interpreted to discourage feedback. At the same time, you have to have channels in place to be responsive and give off positive messages that you are seriously listening to people and responding to requests in a positive manner. It’s very important to be responsive as a product manager.
How do you prioritize all the feedback you get?
For prioritization we used a cost value matrix similar to this:
You have to understand how different teams set value. With sales teams it’s very straightforward — bring in revenue — while it isn’t as simple for business development. Sales, Marketing, Business development, Engineering — you want to make sure everyone sees it and then you can understand what they have in relation to everyone else.
Teams sometimes try to lobby for themselves and in some companies, people pull a lot of stunts to get more attention. This is one reason why it’s so important to keep strong communication lines across teams. It’s also important to really understand the internal dynamics of your company, and to keep a strong focus on high-level goals. Applying these will reduce friction and the distractions that come with friction.
As a PM make sure 1. Everyone has provided feedback 2. Everyone has had a chance to talk amongst themselves. Otherwise, when the roadmap is announced it can be unnecessarily chaotic.
The best way to handle feedback internally is transparency. Make sure everyone feels comfortable speaking up, and speaking directly with you. For roadmapping in particular, some companies have representatives from each team come together for one large meeting. Other companies discourage this and keep roadmap planning entirely within 1:1 meetings between PMs and stakeholders. Either way, those 1:1 meetings are far more important than that one cross-team meeting.
For more articles please goto Flowcap.