[All questions answered!] Event report: New Business PdM vs. BizDev, which is more important? A serious showdown

I am Yanagawa, an executive officer and head of the financial business at BASE, Inc.
My background is Engineer -> PdM -> Business Planning.

I recently participated as a speaker in a new type of debate event, so I am writing a report!
The theme of the meeting was to intentionally engage in position-based arguments!
Decent professionals need a facade! Without a facade, you can't express sharp opinions! The purpose of the meeting was to intentionally break that down.

However, since I am not a decent person, I am the type who can take a stance and speak even without such a setup! So I spoke just as I usually do!

I would like to say that, but it was actually difficult because I had to take a position. I acted to create the maximum possible conflict structure. However, the idea that dividing by job title is nonsense in the first place kept spilling out.
As a professional, I apologize!

Background of participation

I was invited as a debater.
And for some reason, in a BizDev position, which I have never done before.
I accepted the offer thinking, "Well, I can just speak from the perspective of a business owner," but that made it difficult because I felt I might not meet expectations.
What even is BizDev in the first place!

Pre-event article and hashtag series

Pre-event article

I hate to say it myself, but it's a pretty good article, so please take a look.
It's an article about how we should stop talking about PdM or BizDev and start grasping the overall picture of the business.

X hashtag series

I also did an X hashtag series. I think it's reasonably interesting, so please go back and check it out.

https://x.com/hashtag/PdM_vs_BizDev?src=hashtag_click&f=live

Impressions

While I felt again that it is meaningless to divide by job function, people carry some kind of story with them, so from that perspective, I felt that job function is actually quite important.
It's a question of what you rely on to gain trust and get cooperation: is it numbers or user value? The two are not contradictory and both are important, but I felt that where you place the accent changes what is created and also changes the gravitational pull of the organization. I think the fact that the organization's gravitational pull changes is a quite important point.
This is what I was able to verbalize again through this discussion.

Honestly, I wanted to speak on the PdM side!!!
Since my selling point is that I am an engineer and PdM who understands business, it was hard to do!!!

It's a hassle, so I thought everyone should just become a business owner, and I think that will happen sooner or later (prophecy).

Interesting things discussed at the networking event

Opinions on the sentiment of not wanting to become a manager because you don't want to leave the front lines.

I want to say that managers and business owners are totally on the front lines!
You might have an image of a manager as a coordinator, but that's not the case at all. It is important to have the perspective that the team exists to realize what you want to achieve.
I wouldn't want to follow a manager or leader who acts like, "I'm not the main character!"

The discussion that because there is equity investment, we can talk about medium- to long-term value rather than short-term sales.

It's not about whether it's good or bad, but that it is so as a structure.
While betting on medium- to long-term value is a wonderful thing, I also think we should carefully consider the side effects when it fails.
I think equity investment has made the structure of businesses harder to understand, and that is precisely why I think we need to intentionally be conscious of business connections.

Answering your questions!

I received over 40 questions, and I will answer all of them!
Please note that I am not answering as a PdM or a BizDev, but as a business owner, which is my true self.
I may sound a bit blunt, but I am actually the type of person who likes to be supportive.
If you can provide me with the background information of your situation, I can give you realistic advice on what to do based on that, so please DM me.

The more you are actually doing your job, the harder it is to talk about specific details, so in that sense, I am happy to answer your questions.

I don't include them in evaluation metrics, but I do track sales and profits as goals. Evaluation metrics are essentially about whether your salary goes up, so if you include metrics that can be hacked in the short term, it will definitely distort things. It will inevitably happen due to the structure, so I don't include them. Also, it is very difficult to tell if an action leads to numbers, and you don't get numerical results neatly at every evaluation timing, which is another reason why I don't include them in evaluations.
However, I highly value the ability to increase sales. It is the highest evaluation.
Increasing sales is not about sales skills. It is about properly breaking down issues and eliminating bottlenecks. Feature development and sales are just means to eliminate bottlenecks. Identifying where the bottleneck is—that is a job that a PdM, BizDev, designer, or engineer can all do.Don't run away from the numbers.

By the way, I believe that whether you are a PdM or a BizDev, as long as you are involved in business activities in a leadership position, you should be responsible for the P&L.

I think you should just talk to them properly. If you talk, you will find that you are not actually contradicting each other. Please listen to them properly and organize things for them.
Please do not just do user interviews, but also do stakeholder interviews properly.

It is more of a team story than a company story, but my team does not have PdMs or BizDevs. We just have business leaders whom we call domain leaders. Why do we have such a structure? Since products and business numbers are inseparable, we should be responsible for both, so I am particular about not using names that could be misunderstood as only being responsible for one side.

I would ask if the obsession with UI/UX can be explained by ROI.
Also, I would make the team reach a consensus that the release is not the end, but the beginning! The privilege of web services is that you can touch raw data and improve it after release!

Basically, you don't need to split it. If you really want to split it, please bring someone from somewhere who can do the work you want to split better than you.
By the way, BizDev is not sales.

I want you to learn how to move and persuade people.
As a means to that end, there is trying it yourself first, becoming a superior, or explaining with numbers.
I want you to think backwards from the perspective of how to move stakeholders.
Well, if it is a decent team, if you talk specifically about the fact that you think there is a lever to grow the business on the business side, they will listen to you!

I guess it is whether I can make the decision myself.
Honestly, I don't know if it will sell until I make it, so I judge when I can make a decision and take responsibility.
I have thought about this the most, so I made this decision, so don't complain whether it goes well or not. I say that because I will definitely make it go well in the medium term. I do it with a strong feeling.
If you make a decision in a state where anyone can see it will sell, you don't need a PdM, BizDev, or business owner.

I don't know which one will include which, but I think the boundaries will disappear. At the very least, people who say they don't understand the connection between them will be weeded out.
Simply put, I don't think there is anyone who works at a company and doesn't understand business.

I don't have a specific number for the success rate. Please ask an AI.
Exit criteria seem to vary wildly depending on the company. Unless you are extremely short on cash, I think you should let it continue as long as the leader's fire hasn't gone out. I always think, 'Don't measure people by man-months!', but especially when launching a new business, I believe a person's passion is everything. It's about whether you can believe in your hypothesis and whether you can bet everything on it.
To keep betting for a long time, it's better not to make the team unnecessarily large. I think it's fine to have just one person until you see signs of success.
There are tons of career paths after a business exit. You can launch another new business, or join a team that shows signs of growth. Rest assured, someone who has worked with all their might will never find themselves without a next step.
I don't know if a business will definitely succeed. There are many factors involved. However, the experience of trial and error to make a business succeed can be used in any situation. The results of trial and error by someone who was backed into a corner and had no choice but to do it are skills you will keep.

It's not decided just by titles or positions. The opinion that has validity and gets people to follow it wins. Of course, since it's a company, there are work orders, but humans aren't simple enough to just do as they're told. You can't commit to something you don't believe in. It's decided based on a combination of titles, positions, life experience, past achievements, and the validity of the hypothesis—all of it—and then we go with the one we feel like betting on the most.
To those who think their opinion is the most correct! You are probably right, but people won't follow you just because you're right, so aim to be persuasive on top of being right.

What's important in launching a business is passion.
To put it more concretely, it's a story. You cannot launch a business if you cannot tell a story that draws people in.
The question is what you use to reinforce the story: is it numbers, user insights, logical explanation, or charisma?
Anything is fine as long as you can make people want to bet on it.

I don't think people who become jacks-of-all-trades are suited for launching. You should be active in the phase where you are suited.

Judging is tough, isn't it? We couldn't quite create the structure for a showdown.

A bunch of confident, muscle-brained people have gathered. It is a new business launch, after all.
In the end, it's about how to persuade people and get them to follow you, so having confidence is actually quite important.

We don't adopt a sellable hypothesis as a result of thinking until our heads break.
If you proceed with a superficial sellable hypothesis—that is, 'because the user said so'—there might be problems like the organization never developing decision-making power. We are professionals at product creation, so 'because the user said so' is a phrase you must never say. It is only material for decision-making.
We make comprehensive judgments based on various information; that is why we, as product creation professionals, are here. Let's have pride.

You really shouldn't be conscious of roles. There's no time for that.
PdMs also write code, of course. I'm not saying you have to write code.
With limited resources, you shouldn't do anything other than what really needs to be done.
I want you to experience starting from 0→1, and as the business grows, you will get the sense that roles are born out of necessity.

I wonder what's interesting about making a buildable hypothesis. It's interesting because you clear the hurdle of 'it'll sell if you make it, but this is hard to make,' right?
By the way, my area of expertise is convincing engineers who say something is hard to build that 'if you do it this way, you can build it, right?'

I don't think there are that many patterns where both a PdM and a BizDev are present during a new business launch. In reality.
Rather than the perception that opinions split between PdM and BizDev, it becomes the perception that opinions split between So-and-so and So-and-so. The judgment criteria become something like who seems more likely to see it through to the end.
There's almost no chance that you release something and it succeeds just like that, so I bet on the person who seems likely to struggle and make it the right answer even after the release.

This will take a long time if I start talking about it, so read this for now.

I don't think anything of it. Because I am the person responsible for the business.
Both PdMs and BizDevs are exquisitely lacking in their own ways.
People who cannot consistently understand business strategy, product strategy, and talent strategy have no choice but to build what they are told and act as they are told.

You should interact with them honestly. If you think it's a good idea, you should show your support, and if you think otherwise, you should tell them clearly.
Ultimately, the engineer is the one building it, so in the worst case, if you think it's wrong, I think you should just build it with the specifications you believe in. However, you must take responsibility.

People who lack the position or power to make decisions should have a sense of crisis.
You should have a side project where you can make decisions.
Starting an e-commerce shop is recommended. You should experience the moment when money is generated primitively after making decisions for which you cannot make excuses to anyone. The world you see will be different, and your level of courage will change.

Solution-oriented or product-oriented, those are shackles. Shackles of thought.

That is arrogance. It's fine to take a stance, but neither is more important than the other.
The business is important, but BizDev is not important, and PdM is not important either. Seriously, please become someone who is trusted by others and whom people want to follow.

Regardless of your job title, you should do the work of understanding user issues and then mapping out the medium-to-long-term business.

The premise is that you shouldn't separate them. If you do separate them, it should be daily. Please physically work at adjacent desks.

It's about knowing each other. The magic of organizational charts is powerful; when organizations are divided by function, they only talk within those groups. It's sectionalism, isn't it? Even so, grassroots one-on-one mutual understanding is possible, so let's start by setting up 1-on-1s.
After setting up 1-on-1s and deepening understanding, let's think concretely about why it's better not to have a gap. Based on the results of that thinking, you can either persuade the person creating the organizational problem, become a person of authority yourself, or give up and leave. You can choose any of these.

I think there are minimum standards for UI/UX that should be cleared, but I think that's the minimum.
The standard of what is taken for granted is rising every day, though.
I don't think there is such a thing as selling because of UI/UX. I think that's an illusion.
I think there is an optimal UI that can be found through steady funnel improvement. You should see that through to the end.

The axis of the answer might change a bit, but training yourself is extremely important. Building and releasing quickly to get insights is partly about delivering value quickly, but it's also about accumulating experience at high speed within yourself. It is acceptable to commit to training yourself or your team and cycle through PDCA at high speed.

Use generative AI to train yourself.

On the other hand, there is also the perspective of how to consider the damage to the brand value that has been built up, and from that point of view, releasing products is handled with a certain amount of caution.

Main domain?????

I think about it from the business plan and business strategy. It's about questions like, how big is the potential market, and how much can we capture?
Aside from this, it is often misunderstood, but the primary purpose of both ROI and business plans is not to get the numbers right, but to grasp the situation. Since you use them for decision-making after grasping the situation, it is necessary to say that it seems plausible based on current information, but it is impossible to get the numbers exactly right.
The plausibility of a plan changes depending on the phase, so I think there are times when it feels like just drawing pictures. Even so, the whole process of grasping how things went against your hypotheses and making adjustments is what is important.

I think it's revenue. That's the ultimate metric.

I think the way you set goals is the key. If you have quarterly achievement goals, of course you'll think in the short term.
Goals are just tools, so you need to know what the actions you are currently working on are for, and...

Overwhelmingly engineers. Especially engineers who can build structures. Engineers who can properly design databases.
Honestly, I think PdM and Bizdev roles overlap completely with business planning and are inferior versions of it, so I don't think they are necessary at the launch timing. The disadvantages of splitting roles are greater.

I am a person with a strong desire to grasp the overall flow, so I think I would start as an engineer. However, I also think that what an engineer means has changed with the advent of generative AI. Delivery is becoming easier. Among that, I would choose a job role that allows me to be involved in everything from planning to delivery from the very beginning.
In my own actual career, even though I was an engineer, I was doing everything from planning features to building them myself, so I would choose something that allows me to be involved as broadly as possible in that way.
It probably depends not just on the job role, but also on the project, the company, and the business model.

I want to say BizDev! But...
To be honest, I've never met a truly excellent BizDev, so I don't know. I think the job of a BizDev is to create and maintain a business scheme, but it's a contradiction that I've never met anyone who can actually do that. People who can do that much call themselves business managers.
And I am from a PdM background and have been able to do it to some extent. So it would be PdM.
But there are also many PdMs who are completely out of the question.

I think that's true. But BizDev can be important even in toC. A BizDev who can create a business scheme is important everywhere.

It's not necessary. There is no point in separating them. The business manager should just do both.

That's just PdM arrogance. BizDev can also build businesses from a user perspective. Even if it's just posturing, I dislike PdMs because they act like they are the sole spokespeople for the users.

People who don't label themselves as PdM or BizDev, but focus on the task at hand. People who can speak at the same speed and don't need to hold back.

I think the reason a PdM-type person exists is precisely to organize and move forward in such complex situations.
Business schemes should be as simple as possible. But since that's not always the case, isn't that why we have PdMs?

I've forgotten the context for this one.
True customer resolution only increases through the process of releasing and improving.

It's important to have curiosity. To have a pure desire to know and to take action.
Also, it's all about releasing. How many times have you released and seen user reactions? It's all about that accumulation.

That depends on the business model.
I think it's fine to look at KPIs that lead to revenue.
It's rare that you do something and no numbers move at all.

You can never be certain. Not until it sells. So, let's deliver quickly.

It feels like I rotate between business, product, and organization.
Lately, I've been spending time on organizational matters.
For those managing multiple domain teams, let's definitely talk.

Fundamentally, I work three times as hard as the average person. Because it's fun.

For a PdM, it is to organize the complexity of product development that occurs in in-house services that have received equity investment, and to control user value.
For a BizDev, it is to create and protect business schemes and maintain a profitable state.

Answering this many questions was quite a task, as expected. But it gave me an idea for the next event.

I want to do this at the next event!

For things like 'that's a valid point' or 'that would be ideal if it were possible, but reality is tough!',
I thought it would be great to hold an event where we discuss how to move forward, incorporating real-world stories and past struggles!

I want the first installment of that to be on the theme of 'border crossers'!
I hope it becomes a session where people who are actually crossing borders can offer support while maintaining a slightly rigorous tone.
A session that doesn't just end with 'that's tough, isn't it,' but also doesn't just end with a brute-force 'just do it!'

First, we'll warm up the room by discussing prepared topics.
I want to hold a session where we also take questions from the audience, dig deeper into them, and expand horizontally by asking, 'Does anyone else have similar concerns?'
What do you think, Hirose-san?