Lessons I learned in B2B Product Management: Prioritising Customer Feedback - Product Thoughts #136

Welcome back to the Product Thoughts newsletter after a quick summer break. I hope you had a chance to enjoy some time off with your loved ones and have a great time in general. I'm excited for the second half of this year with incredible projects like the launch of my Product Discovery Online Masterclass in the pipeline, amongst others.

In this (and the next ones to follow) week's edition, I want to share with you my biggest learnings from working on a b2b compared to a b2c product. Today, it's about prioritizing customer requests.

When I worked for the first time on a b2b product, I carried a healthy dose of ignorance with me coming from high-scale b2c products. When one user approached us with a new idea, I thought, "we get back to that for evaluation once more customers ask for this." It took me a while to realize how dangerous this mindset can be. In this context, our business consisted of 6 high-value enterprise customers with maybe 1-4 users per customer account.

At this time, my prioritization mindset was pretty much focussed on quantitative data. That was the reason I wanted to wait for "larger numbers."

But over time, I realized two things: First, there would never be sufficient quantitative data in the context of a few high-value customers. So, I could wait indefinitely for that and thereby put customer satisfaction (and ultimately retention) at risk. And second, I noticed how much one unsatisfied or maybe even angry individual user could jeopardize the entire account.

But of course, we couldn't either jump on every feature request which was just based on the opinion of one customer and add it to our product. This way, we would clutter our UI and unnecessarily increase the complexity of our product. Also, the idea of having individually developed product installations per customer with all individual bells and whistles, which we would have to keep in sync manually, scared us as a product team. This way, we would have probably been fully occupied with maintaining the different variations of our products, compared to additional shipping value for all users.

So, we tried to strike a middle ground. We started to share our strategy and roadmap with our customers to give them enough context to anticipate how their feature requests would match our direction. And we also adopted our quarterly goals to not just focus on new functionality driven by our strategy, but to consider existing user's needs.

For example, we defined a Key Result called: "Every needed implemented feature gets used by the respective client at least once." This way, we would be much more rigorous at drilling into new requests and didn't just ship and forget them but held ourselves accountable to check-in with the customers on the feature usage. Again, something you can rarely do on a quantitative basis, as a direct, in-depth conversation is needed for this.

Did you go through the transition from working in b2c to b2b as well or the other way around? What were your experiences?

Have a great week and take care,

Tim

What I've been reading

58 Must-Read Remote Work Resources

Whether a company is fully distributed (remote), co-located in one office or distributed across multiple offices, the way that work gets done will increasingly look like what we’ve been calling remote work. Remote work will just be called work in the future. To help with the transition of remote work to broad adoption, we found as many great resources as we could about remote work.

It’s not always about making things easier: When to make your sign up flow harder

Behavioral “frictions” generally decrease the likelihood of a user to complete a specific task, and also account for a number of human biases. For example, our propensity to stick with the status quo and with defaults, or avoid making difficult choices, are all classic examples of the power of friction that are well supported by academic research. And companies generally get this — many product teams live and breathe this “universal truth” that friction is a bad thing that should be eliminated.

Proxy Metrics

Using retention as a metric for all projects isn’t feasible, however. It’s a hard metric to move, and proving a retention improvement requires large-scale A/B tests. Lower-level metrics — proxy metrics — are easier and faster to move than a high-level North Star metric. Ideally, moving a proxy will improve the high-level metric (e.g., retention for Netflix) — there is a correlation between the two. Later, you can prove causation via an A/B test.

Helping Product Managers to Let Go 

No one can be a product manager without being an optimist, but “optimistic” feedback loops can expose real product challenges. Sippey references a tweet – “My bank’s iOS app let me know it now offers ‘podcast streaming’ and I really need to talk to the product manager” – and asks if the banking customer is confused, what does it say about the bank’s internal teams? It means the engineers, designers, marketing and executives are equally confused about their product.

Understanding and measuring your Customer Effort Score

Sometimes, online businesses are exactly like that hard-to-reach shelf: something impractical that requires extra effort and make people lose motivation and leave. The good news is that there is a simple way to find out if that’s the case with your business: all you have to do is ask your visitors and customers how much effort they have to put into doing business with you. This is the Customer Effort Score (CES), and measuring it can help you make accurate predictions of future business success or failure. 

Hang in there little Product Manager

Successful PMs (who build great products and healthy teams) do two important things very well — provide focus to their teams — figure out the right things to do within the right amount of time and create alignment within the team and company — who are the right people to talk to? Are these goals the right ones for the company/team? To achieve this, I believe that a PM should possess two categories of skills.

Can Product Work Be Done Remotely?

Product roles touch lots of parts of a company. They rarely work in isolation, frequently collaborating with people in engineering, customer support, marketing, sales, and senior leadership. And of course, with the customer, too. Product isn’t just responsible for figuring out what to build, but also for getting it built and shipped in concert with the rest of the team. And for convincing all the key stakeholders in the company along the way. Doing this remotely isn’t impossible, but it can be challenging. Building and sustaining relationships remotely and communicating seamlessly with the entire company can be difficult as a remote product person.

Mastering the Art of the Outcome: How Guru Turned Customer Success Into a Company Cornerstone

Consequently, Guru’s approach to proving customer outcomes is meticulously quantified, rigorously unambiguous, and integrated into every facet of the company. From defining the market and designing the product, to communicating success metrics to customers and employees alike, Guru has been built on the goal of mastering the art of the outcome. “For us, ‘success’ means being able to tell a customer that Guru’s resulted in a 20% reduction in handle time and a 34% reduction in repeat questions for their sales team,” says Nucci.

Product Thoughts is a weekly newsletter/digest I send out to over a thousand leaders in product, UX, and business every week. To learn more about previous editions and sign up for it, go to herbig.co/newsletter.