A Business Strategy Does Not Decide What to Build

Why this record exists

When building a new product, many things about the business have already been decided.

• Which market to enter
• Which customers to acquire
• Which operational problem to solve
• How to generate revenue

Yet even with these decisions in place, development can begin without alignment on what, exactly, the product should be or how it should work.

Each requirement has a reason behind it, and someone has said that it is necessary. Even so, the use cases do not connect when the product is used as a whole, and it is difficult to explain why a particular feature should be built now. The business strategy exists, but there is no process for turning it into product choices. As a result, no product strategy has taken shape.

They answer different questions

Business strategy answers: Where and how will this business work?

• Which market and customers will we choose?
• What value will we provide?
• How will we capture revenue?
• What will create our competitive advantage?
• Where will we allocate our resources?

Product strategy answers: Which product choices will turn that path to winning into reality?

• Whose problem, in which situation, will we place at the center?
• What state should the user’s work reach after using the product?
• How much of that work will the product take responsibility for?
• What will be standardized, and what will remain in operations or customer-specific handling?
• Which capabilities will we acquire, and in what order?
• What will we not build?

Both appear to decide “what to do,” which makes them look like the same thing. But the concrete shape of a product does not follow uniquely from a business choice.

Deciding to acquire enterprise customers does not tell us whether permissions, auditing, or integration with existing systems should come first. Even among enterprise customers, the product needed will differ depending on who uses it, who buys it, what blocks adoption, and which work must be made possible.

Business strategy gives product strategy its constraints and purpose. It does not determine the shape of the product.

What lies between them is choice, not translation

Sometimes a request from the business side is reworded and passed on as a development requirement.

We want to acquire enterprise customers.
Therefore, we will build administrative features.

We want to reduce churn.
Therefore, we will build notifications that encourage usage.

We want AI to be a competitive advantage.
Therefore, we will add generative AI.

Each can be a valid hypothesis. But the second statement does not automatically follow from the first.

What is preventing those customers from buying? Which unfinished work is causing churn? Whose judgment changes when AI takes over a task, and how? The space between the two statements must be investigated. One possibility must be chosen from several, and the alternatives left behind must be made explicit.

The “conversion” in question is therefore not a matter of translating words.

It is taking a business objective as a constraint, then choosing again how to realize it through the customer’s work and the nature of the product. The coherent set of choices that results is the product strategy.

What happens when the conversion is missing

When work moves directly from business demand to development without passing through product strategy, the product accumulates features that each appear correct on their own.

The requirements are valid, but the use cases do not connect

Every screen and feature has a requester, and its necessity can be explained. Yet when a user tries to complete a piece of work from beginning to end, something is missing along the way.

The product satisfies the requirements feature by feature, but fails to deliver value as a whole.

Priority becomes a function of who speaks loudest

Without shared choices about what the product is trying to achieve, there is no common basis for priority. Individual circumstances—an important customer requested it, a deal depends on it, or a deadline is approaching—then determine the sequence directly.

These circumstances cannot be ignored. But if they are the only basis for every decision, judgment does not accumulate, and every new request rearranges the order.

There is no definition of acceptable UX or quality

If it is unclear whose work the product must make possible, and which work that is, there is no way to define what “usable” means. A team can confirm that a screen exists, can be operated, and behaves according to specification without confirming whether the user can complete the work.

Poor quality is not caused by product strategy alone. Reviews, validation, acceptance criteria, and the development process can also be at fault. Even so, without a strategy, it is difficult to establish a standard for what quality the product must protect.

Engineering becomes a recipient of requirements

When product choices have not been shared, engineers have little option but to take the requirements they receive as given and think about how to implement them. This does not happen because the discipline lacks influence. It happens because there is no shared basis from which to challenge the question itself.

Engineers can present technical options. But if the customer value to prioritize has not been chosen, those options are unlikely to become proposals that change the requirement itself.

What an initial product strategy decides

At the beginning of a project, it is impossible to decide every future specification. Under uncertainty, what is needed is not a detailed picture of the finished product, but a hypothesis that aligns present decisions.

At minimum, the following questions need answers.

1. Who is the central user, and what is the central work?
   Not merely the customer organization, but which person, in which situation, must be able to complete which work.

2. What state should that work reach?
   Not the state in which features have been delivered, but how the user’s decisions, actions, and outcomes will change.

3. How far will the product take responsibility?
   Separate what the product will handle, what will remain in human operations, and what will not be addressed initially.

4. In what order will capabilities be acquired?
   Decide not only when features ship, but which use case becomes viable first and where the product will deepen next.

5. What will we not do?
   Make explicit the customers, work, and approaches that are outside the current strategy—not merely postponed.

6. What would show that the hypothesis was correct?
   Define observable conditions demonstrating that the target work has become possible, rather than looking only at revenue.

These answers are not fixed truths. They are updated as the team learns about real work, observes usage, and finds counterexamples. But accepting that they may change is not the same as refusing to choose anything at the outset.

The boundary with roadmaps and specifications

If everything is written into the product strategy, it becomes an enormous plan that cannot be updated. Strategy determines the choices that align many decisions in the same direction, not every screen or interaction.

• Product strategy decides whose work will change, what value will change it, and what responsibility the product will take
• The roadmap lays out the order in which the required capabilities will be acquired
• Product requirements specify the use cases and conditions that must become viable at each stage
• Design and implementation determine the experience and system through which those requirements will be realized

These boundaries are not absolute. Learning what is technically possible may change the strategy, and observing users may send the roadmap back for revision. What matters is not handing work downward once, but keeping the different questions distinct.

Tests for whether it is a product strategy

Three questions help reveal whether a business objective or feature list is merely being called a product strategy.

1. The product-change test — After reading the strategy, can you explain how the user’s work and the product will change?
2. The rejection test — Can you reject a new request with the same reasoning and say, “We will not build this now”?
3. The sequence test — Can you explain why feature A comes before feature B for a reason other than the deadline or the requester?

“Grow revenue” and “acquire enterprise customers” cannot answer the first. A feature list cannot answer the second. A delivery schedule cannot answer the third.

If all three can be answered, the conversion from a business objective to product choices has at least begun.

Who decides

Separating business strategy from product strategy does not mean dividing the organization.

People responsible for the business hold knowledge about markets, customers, commercial structures, revenue, and contractual constraints. Designers make user behavior and experience concrete. Engineers reveal the choices technology makes possible and their continuing cost. The Product Manager receives these inputs and brings them together as coherent product choices.

No single person thinks up the correct answer alone; everyone contributes the facts and counterexamples they hold. But adding every request together unchanged does not make a strategy. Collaboration and ambiguity over responsibility for choosing are also different things.

Business strategy is an input to product strategy, while learning from the product is an input that updates business strategy. The relationship is not a hierarchy but a loop.

In short

• Business strategy and product strategy work toward the same purpose while answering different questions
• Business strategy gives the product its purpose and constraints, but does not determine its shape
• What the two require between them is not translation, but choices made through an understanding of the customer’s work
• Without those choices, business demands flow directly into development, producing features that are individually valid but do not connect as a whole
• An initial product strategy defines the target work, intended change, scope of responsibility, sequence of capabilities, exclusions, and conditions for validation
• The relationship between business and product is not a hierarchy but a loop; even so, someone must remain responsible for making product choices