On starting a new role
Changing organizations in the world of product is not as simple as it sounds.
In the last couple of months I’ve been a bit away from writing, mostly newsletters not PRDs thought :), because I had the pleasure to join eduki as a product manager for search, navigation, and personalization experience.
Last week marked 60 days since I’ve joined my new gig, and I wanted to reflect on two things, starting a new role AND doing it on an industry and a domain that is completely new.
There are a bunch of useful resources on how to start a new role, two of my favourites are:
’s recent article on How to Start a New Role and older one from - A Simple Guide to Preparing for a New Role, helped me a lot to frame goals and milestones using a three times horizon; 30d, 60d, and 90d. I must say that this was extremely useful when I had my first call with my manager, especially to adjust on the expectations. Below my 30/60/90 list:Keep in mind that the list can vary depending on the size of the org and the scope you manage. In my case, being an IC with a team of 6 people and a quite flat organisation is more than enough.
Disclaimer: I’m a person that has a bias for action. Within the first 30d, we were pushing some bug fixes into production, and it was ok. There was not much context needed to know that those bugs were affecting the customer experience. If you find yourself pushing something bigger in scope and impact, please make sure you can handle the effect of it.
Changing markets, biz model, scope…
I came from 5yrs working for B2B companies that were selling SaaS to large enterprises. You can imagine that is has nothing to do with marketplaces and much less with the are I’m part of (search, personalisation, etc).
Here are the things to pay attention when starting a new role on a product with a different market, GTM motion, business model, and area of expertise:
Biz model: Most SaaS (specially B2B) are playing the productivity game with a subscription business. Marketplace (specially B2C) most of the times you are playing the transaction game, therefore you get a % of what you sell. For the former, if you help the user to do things they were not able to before your product and by doing so you streamline some part of their workflow, it’s likely you are going to win. For the latter, the more diverse, high--quality, and useful materials authors upload (in the case of eduki), the more buyers spending dollars, therefore the more materials are updated, and more buyers are coming (flywheel spinning).
GTM motion: In terms of GTM, depending on the size of the customers you are serving, a sales-led and marketing-led approach could be a great way to grow your product, as well as a great ecosystem of partners, systems integrators, and technology alliances to close deals and expand its footprint. In a two side marketplace, customers often find the platform via inbound marketing (SEO, content) and convert through a seamless online purchasing process. The previous come with free trials to entice users to join the marketplace before converting to paid services.
Market Variety: One of the things I noticed when I was at a large B2B SaaS company is that regardless of the country, the L1 Service Desk IT guy had more or less the same problems, having to juggle with multiple issues and technical jargon, they are bombarded with many requests and problems, they lack experience on how to fix and escalate issues. In Marketplaces is something similar, that’s the reason you segment your users, but it could be more nuance, since you have to cater for two different sides, but within each of them you may have a wide variety of behaviors. For instance, in a marketplace, you might be dealing with individual sellers sharing materials that cannot make a living out of it, all the way up to large businesses, and their needs are totally different. On the buyer side, you’ve got everyone from casual shoppers to people buying for their companies, each with their own expectations and purchasing behaviors. So while you still have to segment your users, the variety on both sides makes it more complex. It’s not as straightforward as in B2B SaaS, where roles and pain points are generally the same no matter the market.,
User Behavior: It is true that not all users are equal and they may have different motivation when using your product. Nonetheless, I’ve seen that for the B2B SaaS, since they are already paying (more in large enterprise than SMB) you have the chance to either increase usage or sometimes understand why they are not using and revert that situation before they churn. Sometimes the latter it is inevitable. On marketplaces happens something different but similar at the same time. Different because if they don’t find what they are looking, the will find it somewhere else, mostly using other sources. The similarity is that, the value a marketplace provide with the flywheel, makes it hard for a user to find exactly the same. Different dynamics, but they overlap at some extent.
Product Organization: although the way teams are organized could vary around your product strategy, it was true that for a B2B SaaS, we were very organized based on the use case / job-to-be-done we were addressing. In a marketplace, we clearly have structure ourselves around buyer (app and desktop) and author experience. In the latter case it’s interesting how the things you do on one side of the marketplace could affect the other.
There are more aspects that you must consider such as market size (millions vs thousands), testing and validation (easier to talk to customers vs type of test you can use), technical aspects (very complex solution and architecture vs something simpler), and more.
Why have I mentioned the previous items? Well, it's clear that in the plan you have defined along your boss to get onboarded, especially if the product is completely different to the one you were used to, you must consider these aspects to see how they work.
I expect to to resume the AI Tools for Product Teams series soon.