Learnings From Managing B2B VS B2C Products

Rahel Maharani at UXDX Community: SE Asia. Video: https://youtu.be/TPU6UX5Jn24

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why this topic, and who I am

[00:00:00] Hi guys, thanks for coming. I chose this particular topic because I would have loved to hear about product metrics and adoption know-hows early on in my career. Hopefully through this sharing I can save at least one PM from a lot of trouble. Before we get started, let me introduce myself.

[00:00:20] I'm currently a senior product manager at Glints. Glints is a tech enabled recruitment and remote hiring company. We have in-house productivity tools to help increase our recruiter efficiency, and consumer-facing career development platforms to support demand and supply acquisition. I've been responsible for the development of Glints' B2B and B2C products in Southeast Asia from Series A to the present. This is a picture of me working on top of a washing machine when we didn't have enough meeting rooms. Fun times.

[00:00:54] Today we will talk about my failures. Hopefully I don't get a bad rap after this.

B2B: choosing the wrong north star

[00:01:01] Let's start with my B2B learnings. When I was the B2B PM for Glints, my objective was to increase the worker efficiency by helping our in-house recruiters make better decisions and priorities in finding suitable candidates for paying employers. Some of the things we built were a recruiter applicant tracking system, a job prioritization dashboard that could help recruiters figure out which jobs would convert to placements the fastest, employer notifications and so on.

[00:01:32] The first story goes: the team is not performing because the metric is not moving. We made a bad decision when we chose the business north star as our team's north star. The assumption was that the business north star should be the business product's north star, because the team's job is to build a tool that would help the company make more money. The reality is the business north star is usually a lagging metric that requires a lot of moving parts to move for it to change. The learning for me was to stress test whether the metric my team is trying to move is a leading indicator to the north star.

[00:02:07] In fact, before we could even build optimization tools to support the business north star, we had to build a unified data collection tool to provide accurate and real-time data points, so we could analyze how to move the business north star. Once we have this data we can come up with a few assumptions on metrics to focus on, based on their correlation to the north star. We may also be able to see which part of the funnel is leaky, which part of the flywheel is problematic, and which of the levers are leading indicators.

B2B: internal users still have to be won over

[00:02:39] We set out to build this tool, and thought to ourselves, the users work for the company, they'll have no choice but to adopt this tool. The assumption here is that business users will adopt the tool because it's better than their existing solution, plus we'll get the business lead to enforce adoption. The reality is the business lead doesn't have as much authority or influence compared to their direct managers. Habits and anxieties beat better solutions, because back then they were using Google Docs, Google Sheets, and having this habit made it very hard for them to switch to our tool.

[00:03:15] The learning for me here was that validating the problem and solution is not enough. I needed to get buy-in from stakeholders with authority and influence, and map out the existing workflow from beginning to end, including those beyond the tool usage in all business units. Because, turns out, after you collect the data we need to build tools for data visualization. We built that next.

[00:03:41] We have to gradually limit access to old tools, ensure that relevant data are accessible on the new tool, and incentivize transition by understanding what motivates them. For example, the recruiters were motivated by commissions, so we said, okay, if you transition to this new tool and all of your data was visible on this tool, then you'd get more commission. We also provided training and created exciting launch campaigns.

[00:04:12] If you have to remember anything from this story, it's that internal users are still users with needs, pain points and feelings. Not only do we need to validate the problem and make sure that the new solution is better, we also have to understand that the users' anxieties and habits are there blocking them from switching to the new solution. Having an operational counterpart is also important to help you push for internal adoption like you would an external launch.

B2C: replicating what users already do

[00:04:39] Now, on to my B2C days. The objective for me as a B2C PM was to identify and increase engagement and retention metrics in the job marketplace. Some of the things we built included an employer applicant tracking system, fraud prevention features, candidate job recommendations, you get the gist.

[00:05:01] The story goes: let's just replicate what the user is already doing and it will surely work, right? We saw that users are voluntarily sharing jobs and are willing to share the resume of their peers with recruiters. When we built a feature around referrals to increase candidate acquisition, we failed to hit product market fit, because the recipient of the benefit is the peer who is getting referred, and not the referrer, the target users. The user value here was totally missed and we saw a decline in retention.

[00:05:33] The assumption here was that replicating what a user does in real life will always result in great outcomes, when the reality is that just because people are doing the action doesn't mean it will guarantee product market fit. It also doesn't guarantee the scalability of the solution. The learning for me was to stress test why a past action happened, and in what circumstances that past action would occur. In this particular story, users need to receive the benefit themselves for the solution to find product market fit. We should have better designed the feature to have a reward and investment flow, to increase the likelihood of users returning. Thanks Marielle for this beautiful hook model.

B2C: silence is not satisfaction

[00:06:15] Our last story of the day is: there's nothing on the recurring surveys about this, everything must be great. We wanted to increase the number of active jobs to increase the candidate satisfaction score, and we found that jobs were closing at alarming rates. Our investigation found our algorithm was automatically closing jobs that hadn't received any applicants, because it thought that employers were not taking care of the job posting. The algorithm was flawed, but it was so easy to create a new job that users didn't bother to complain.

[00:06:48] In this story the assumption was that if the users are not complaining, things must be working properly, when the reality is users don't always complain when they are confused or frustrated. We had to track and analyze our drop-offs as much as our gains. We not only improved the algorithm, but we also improved the user journey, so that users are aware of closing jobs and why they are closing.

[00:07:13] Through these mistakes I learned to ask myself: am I working to move the right metric? What are the habits and anxieties attached to the user journey? Who is benefiting from the solution, and how? Am I tracking and analyzing the drop-offs as much as I am tracking and analyzing my gains? I have so many more mistakes to share, but for the time being I hope these ones were insightful. If you have any feedback, please don't hesitate to reach out to me.