An Overview of Profitable Product-Led Businesses from a Finance Perspective for PdMs Becoming Business Leaders

I am Yanagawa, an executive officer at BASE, Inc. I serve as the business leader for our financial services division.
My career path has taken me from engineer to PdM to business leader.
Currently, I serve as a business leader, holding responsibility for business strategy, product strategy, and organizational strategy.
Based on that experience, I have written about the "big picture of a profitable product-led business."

The inspiration for this article was an article posted recently by Mr. Yokomichi. It is a must-read for anyone involved in product development, so please take a look.

After reading that article,

• it seemed it would be easier to understand if there were a context of product management within the business as a guide

• why have all these things surrounding product management become so complicated?

and other such thoughts led me to pick up my pen. Perhaps we are overcomplicating things. If we return to the business, shouldn't it be simple by nature? This article includes such arguments.
I aimed for this title, but I want not only product managers but everyone involved in product development to read it.

This article is a spiritual sequel to the following article.

Notes

The goal is to represent the flow of a profitable product-led business as simply as possible, without focusing solely on the product development perspective.
Therefore, there may be fine details that might be concerning when viewed from each respective field of expertise. Please forgive me.

I have written this entirely from my own experience. Please forgive me if it differs from what is written in that book, or conversely, if it is accused of being a rip-off.

Overview of Traditional Manufacturing

For comparison, I will dare to write out the flow of the manufacturing industry.

Overview of a Profitable Product-Led Business

The changes are the addition of product strategy, and changing capital investment and manufacturing to product development.
It is important that business strategy and product strategy are deeply connected and inseparable.

Web-based products are easy to change after release.
Although I said they are easy, designing a strategy based on change is highly difficult.That is why the job of product manager was created, and it became necessary to establish a product strategy at the same time as establishing a business strategy.
If there is no strategy to improve after release, the benefits of a web service will diminish drastically, and you will lose to your rivals.

Of course, there was an improvement cycle in the traditional manufacturing industry as well. However, being able to quickly and finely improve shipped products based on actual feedback is a revolution.
While it is a revolution, there is a big difference between organizations in how well they can use those benefits. Each organization and business model has its own unique methods, and one must improve the product while responding to those.
I believe this is why product management becomes complicated.

You can use information obtained in any situation for product improvement at any time. It is a wonderful thing, but it is very difficult.

Therefore, experts in product management emerge, but...
Why can't the person responsible for business strategy and the person responsible for product strategy be the same person?This is the theme that flows at the root of this article, and it is also the theme of my product development life.

Explanation of Each Phase of the Overview

First, let me explain the details of each phase.
What is important is to grasp the flow of business strategy, product development, and business growth.
This phase explanation is long, so it is okay to skip it for now and come back to it. I think the next chapter on PDCA has higher importance and is easier to read.

Strategic Organization Formation (Business Strategy)

Form an organization responsible for business strategy.
This is the organization that creates the strategy for finance.
Strictly speaking, some might argue that finance comes even before this.
It includes the following functions.

• Business Owner

• (PdM)

• (BizDev)

Business Strategy Formulation / Product Strategy Formulation

Formulate the strategy for finance.
Business strategy and product strategy are two sides of the same coin.
I believe it is best if the business owner can formulate this alone, but in some cases, it is done in cooperation with PdMs and BizDevs.
The following keywords are relevant.

• Market Research

• Business Vision

• Business Plan Formulation

• Product Vision

• Product Discovery (Macro)

Finance

This is fundraising.
Without raising funds, you cannot run a business or build a product.
You might think that fundraising is only an action for starting a company and has nothing to do with employees. That is a huge mistake.
Finance is involved not only when launching a new business but also when creating new features. The very act of spending money to do something is finance.

Development Organization Formation

Form an organization to develop the product.
This is possible because of finance.
It includes the following functions.

• Planning (PdM?)

• Engineer

• Designer

Product Development

This is product development. Many product management methodologies are used in this phase.
Keywords such as the following are relevant.

• Product Development

• Product Discovery (Small)

• Product Improvement

• Requirements Definition

• Product Delivery

If I start explaining this here, it will become incredibly long, so please check out Yokomichi-san's article.
(If I have time, I would also like to write an article explaining the relationships between PdMs, engineers, designers, etc., based on their interactions.)

Operational Organization Formation (Business Growth)

This is the organization responsible for business growth.
User acquisition is also part of product operations, and I organize it such that the product includes marketing and sales as well.
The product includes the process until it is actually used. Let's design it comprehensively.
The following functions are included.

• Marketing

• Sales

• Customer Support

Release

This is product delivery.
In product development, the release is just the beginning.
Therefore, determining the state of the first release is where technology manifests, and that is precisely what product strategy is about.

Acquisition and Operations

This refers to user acquisition and operations.
Marketing, sales, and customer support fall under this category.
The PDCA cycle for acquisition and operations themselves is important, and the information obtained here is also utilized for product development.

Accounting

This is the aggregation of results such as revenue and KPIs generated by the product.
It is an important phase for both product improvement and subsequent finance.
Let's check the respective figures on a daily, weekly, and monthly basis.
To check them, it is important to create business plans.
It makes sense only when managerial accounting perspectives and financial accounting perspectives are intertwined.
There are many PdMs who do not check this or take it seriously as their own responsibility. (According to Yanagawa's research)
I'll concede that you don't necessarily have to hold P&L responsibility, but you should look at the numbers. Drill down into the numbers that concern you. Since you get results every month, you should look at them properly and put them to use. But in the end, if you don't have P&L responsibility, you won't look at them seriously—because you're human.

PDCA Before Release

The overall view of a profitable product business is, naturally, not a one-way street.
PDCA cycles are happening in every situation.
I am writing this with the belief that explaining each of these will help in understanding the overall flow.

Creating a Strategy That Can Be Financed

Creating a strategy that can be financed is a difficult task. Whether it is external finance or internal finance, it requires strategic planning and persuading stakeholders.Since a business cannot start without money, it is necessary to create a strategy that justifies the investment.
To achieve this, you need to explain how much money is required and how much that money will return. No one will provide money without a reason, and a company cannot make a decision either.
But this explanation is difficult. It is already hard, and it becomes even more difficult when the uncertainty unique to product development is involved.
It is a repetition of writing business plans, writing product visions, conducting business discovery, and conducting product discovery.

To reduce the cost of this consideration phase, it is important to have a deep understanding of the product development phase and for the product development phase to be robust.
If you are overly afraid of the uncertainty of product development, this phase will become infinitely heavy.

Product Development Turned Out Differently Than Expected

Even after financing and developing a product, it is possible that you run out of money or find that a change in strategy is necessary while developing. It is better if it doesn't happen, but it can happen, so PDCA cycles can occur here as well.

Product Development

PDCA cycles are constantly occurring within product development.
Various things happen, such as whether you can actually build what you want to build, whether you can provide value with what you have built, or whether it feels different once you have built it.
It is best to think of this as a smaller version of the PDCA cycles that occur throughout the entire phase of the overall view of a profitable product business.is a good way to think about it.

PDCA After Release

PDCA cycles continue to rotate even after release. This is a characteristic of the overall view of a profitable product business.

Acquisition, Operation, and Improvement

How to deliver the finished product to users, sales and marketing are truly a series of PDCA cycles. Also, we make improvements while handling user inquiries and daily operations, which are mainly handled by customer support.
The results of the PDCA cycles that progressed here are often reflected in the product.
The point is to look at the consolidated numbers in the accounting process properly and use that as a starting point to run the PDCA cycles. Since you have released it, face the results properly!

Product Improvement

We improve the issues that emerged from the improvement results in acquisition and operation, or from product discovery (small) by the product development team, using the means of product changes.
This part of the PDCA is the part that differs most from the overall view of traditional manufacturing, and it is also the root cause of the complexity of product management as a whole.
Because improvements can be made after release, the cost of prior consideration is reduced, and if you master this characteristic, the perfection of the product will also improve. Conversely, if you cannot do this well, you might just end up creating something of low quality.
The diagram is drawn in the following way to show that product improvement is not done only within the scope of the product development team.

Brushing Up at the Strategy Change Level

There are times when brushing up at the strategy change level or new financing is required.
What is important at this time is,how to utilize the raw information obtained from the accumulation of actual product operationsis something that exists.
If you can prove that you can properly run PDCA cycles up to this level, you can significantly skip the explanations for financing and the accompanying verbalization or numerical explanations.

If You Work for a Company, Know the Business Cycle

Raising funds, converting them into management resources, and delivering value,this is business activity.
The overall view of a profitable product business mentioned above is also organized based on the content of these business activities.
Since the occurrence of the above cycle is unavoidable in a joint-stock company, it is necessary to grasp it accurately.

The important thing is how to utilize the ideas of Agile and product management to skip this explanation cost after grasping this premise.Only when you can do that can you say that product management is truly functioning.
If you don't grasp it, you can't skip it, and there is 'trust' that can be gained precisely because you grasp it. 'Trust' is also an important factor for skipping.
I will write about such things from here on down.This is where the real work begins.

Is a Product Manager a Strategic Organization or a Development Organization?

Since there are various schools of thought, I will take a deliberate stance. Regarding the overall view of a business that earns through products, I believe that product managers should absolutely belong to a strategic organization.Only by achieving that can they differentiate themselves from mere planning roles, and I believe one should not call themselves a product manager if they have not reached that level.

However, in the current world, in many situations, they belong to development organizations, don't they? But I suspect that makes it impossible to drive business by leveraging the characteristics of product development.

Having taken that stance, what I want to say is that there is a high possibility that product managers belonging to development organizations can also gradually transition into strategic organizations is what I mean.
In product development, small-scale strategy formulation and execution are repeated. By taking initiative in these repeated cycles of small-scale strategy formulation and execution, you will definitely gain decision-making power.
I believe that while gaining experience in running PDCA cycles within the scope of product development, you can gradually seep into the strategic organization. I believe that being a product manager is a shortcut to becoming a product leader.

Who decides each strategy?

There are various thoughts on this as well, so I will take a deliberate stance.
In my personal opinion, there should be a time when the same person bears the responsibility for each strategy at the same time is what I believe. If different people are responsible for each strategy, it is difficult to understand the connections.
Having the same person bear the responsibility for each strategy at the same time is quite a heavy burden. Therefore, I cannot easily recommend it, but as an individual, I feel it was good to try it.
I think it is good to be able to attempt to take full responsibility while also borrowing the strength of the team.

Organizational charts narrow and focus the scope of each role. And I do not deny that this is necessary to achieve results.
However, the power of an organizational chart is truly strong, so there are many times when the organizational chart becomes a shackle and you cannot cross boundaries when you should. There are many tricks to cross them, but I think the best approach is to prepare so that each person can function even if they swap their areas of responsibility, and on top of that, to divide the scope to focus.
Honestly, I am still experimenting with this myself.

Business Strategy -> P&L Responsibility

While a COO might sometimes take this on, in a startup-phase organization, the business leader should be responsible. What kind of business, and with what kind of plan, can it be scaled? The scope includes both planning and taking responsibility for actual numerical results.

• Business Strategy Formulation

• Business Plan Formulation

• Fundraising (Finance)

• Budget vs. Actual Management (Accounting)

Product Strategy -> Product Responsibility

While a CPO or CTO might sometimes take this on, in a startup-phase organization, the business leader should be responsible. The scope includes what should be built, how it should be built, how it can be delivered, and how it can be operated stably.

• Product Strategy Formulation

• Product Management

• Engineering

• Design

Organizational Strategy -> Organizational Responsibility

While a CHRO might sometimes take this on, in a startup-phase organization, the business leader should be responsible. The scope is what kind of organization should be built to execute the business strategy and product strategy. Needless to say, it is deeply connected to both business strategy and product strategy.

• Organizational Strategy Formulation

• Recruitment

• Evaluation

• Development

• Organizational Operations

Don't just run PDCA cycles within product development

In a product-led business, the product development team contains, albeit on a small scale, the entire flow: strategy, implementation, and execution. Gaining experience in running PDCA cycles quickly here is important for product talent to become product leaders who run businesses.
However, that does not mean you should only run PDCA cycles within the product development team. It will end up being a small PDCA.

I am writing this article because I think it would be great if product managers could look at the entire product-led business and run PDCA cycles.
Product managers, please make good use of this advantage.

Product management is at the center

In a product-led business, product management is indispensable.The soundness of business strategy is important. In addition to that, the soundness of product strategy and the ability to execute that product strategy are also crucial. It is because these are intricately intertwined that value reaches the user as quickly and reliably as possible.
To intricately intertwine these connections, a leader who understands product management is necessary.
This is the backbone of my frequent assertion that product managers should become business owners and engineers should become business owners.

The importance of providing a backbone

A business is operated by multiple people.
And it is vital that each person plays an active role by leveraging their own areas of expertise.
But that only exerts its power when someone provides a backbone.
After grasping the overall flow of the business, the business owner provides the backbone.
When that is done, each member can naturally demonstrate value while being conscious of the connections between the overall phases.
A state where no one understands the holistic view is very frightening. A state where leadership is absent is very frightening.

Product development is resistance to complexity

Product development is a battle against complexity. Agile thinking and practices support this. The presence of a product leader who understands product management leads and supports this.
I believe that the entirety of the holistic view of a product-led business can be advanced in an agile manner. Let's apply the skills we have honed in product management to resist complexity to the entire business cycle.

This will be a slightly philosophical discussion.
I think that what can be explained, what can be verbalized, and even more so what can be expressed in numbers, is limited.
I think the feeling of "I can't explain it, but it's just so" is very important. I'm sure many of you have experienced that in the process of explaining things so that many people can agree, important things are stripped away and it becomes a mediocre plan.
I consider agile thinking and product management methods to be, in a sense, methods for "skipping explanations." Therefore, I want to make agile work not just in product development in a narrow sense, but in the entire business activity. To make this work well, you also need to understand the structure of the business. What is needed to skip explanations is, in the end, "trust." How do you gain "trust"? It is the accumulation of track records and explanations.

To skip explanation costs, you need to understand the structure and try to verbalize it. As a result, you need to gain "trust." Can you grasp this seemingly contradictory feeling?

People who originally couldn't understand each other come together through the common denominator of money. That was one correct answer in its own right. With such an answer existing, as a next step, I want to bet on "trust." I want to bet on agile and product management as one philosophy that supports "trust."
This philosophy is influenced by digital democracy.

Explanations, verbalization, and numbers are all products of compromise. (This is a radical thought.)

Summary

I wrote this article while being as conscious as possible of the overall connections. It became long, but how was it?

The argument is simple: both product development and business development share the importance of
why you are doing it,
what you are doing,
how you build it,
and how you operate it.
It is important, and if I may say so, that is all there is to it.

Although I said that is all there is to it, it is difficult, isn't it? If you don't grasp the holistic view, you can't break it down. And since no one will break it down neatly for you, it is ultimately faster to go and learn the holistic view yourself. I hope you will remember this article when that time comes.

I am currently involved in all phases of a product-led business. Therefore, I think I can talk from a stance of being broad and shallow, but valuing connections, so please feel free to reach out if you have any consultations.

I would like to write articles that delve deeper into each phase in the future. Please be sure to like this article and follow me while you wait.
Introductions on social media are also very welcome! If you mention me, I will comment, so please do!

Editor's Note

The background for writing this article stems from my feeling that 'J-curves and equity investments are strange.' While they are necessary methods, I believe it is important to recognize that they are not the default state.
I wanted to raise the issue that we should recognize that the context of 'user value above all else, regardless of what happens elsewhere' is significantly influenced by J-curves and equity investment.

• It is natural for decision-making criteria to change depending on the phase

• It is natural for solutions to change depending on the business model

In short, in the early stages of receiving equity investment, even if the P&L is hard to see, we should look at it properly. You are looking at the B/S without even realizing it. Everyone working at a startup is. You might think you don't understand the B/S, but you are structurally bound by it. You are only looking at the top line and the B/S.

I want to make this common knowledge so that we can have intense, substantive discussions and drive progress.
That is what this article is about.