Product Strategy Is a Set of Choices

A product team can be busy for an entire year without becoming much clearer about what it is trying to achieve. Features ship. Customers receive updates. The roadmap gets refreshed every quarter. There is visible progress everywhere, yet the product remains difficult to explain and the business remains difficult to steer.

The problem is often not a shortage of ideas. It is a shortage of decisions that hold those ideas together.

Product strategy gives a team a reason to choose one opportunity over another. It connects a particular customer’s problem to a way the company can win, then makes the consequences of that choice concrete. A useful strategy changes what people build, what they measure, what they sell, and what they politely decline.

This essay uses a fictional software company, Fieldnote, to explore how those choices develop. Fieldnote builds a tool for teams that coordinate work across several client projects. The details are invented, but the tensions are deliberately ordinary: a growing backlog, different customer needs, limited engineering capacity, and pressure to make the next quarter count.

Start With the Situation

Fieldnote’s leadership team begins with a familiar ambition: become the best place to manage client work. It sounds reasonable. It also leaves nearly every important question unanswered.

An independent designer managing three clients has a different problem from an agency operations director managing forty projects. A consulting firm billing by the hour has different incentives from a studio selling fixed-price engagements. All of them might describe their work as project management, but that shared label does not make them one coherent market.

Before choosing a direction, the team needs to describe its situation accurately. Where does the product already create value? Who returns without reminders? Which accounts require extensive support? What alternatives do customers use, and why do those alternatives remain attractive?

The first useful document is therefore a diagnosis. Fieldnote discovers that its happiest customers are small agencies with repeatable delivery processes. They do not need another place to store tasks. They need to spot commitments that are drifting before those commitments become uncomfortable conversations with clients.

Meanwhile, individual freelancers tend to leave after a short trial. They find the setup excessive for their needs. Larger agencies like the concept but ask for permissions, reporting, and procurement requirements that Fieldnote cannot support well.

These observations create a sharper starting point. The company has a foothold with a specific kind of team and a specific recurring problem. It also has boundaries. Strategy becomes possible when those boundaries are acknowledged rather than hidden inside a broad ambition.

Choose a Customer You Can Understand

Choosing a customer segment means accepting that some plausible users will receive less attention. That can feel uncomfortable, especially when the company is young and every new account appears valuable.

But a product designed around incompatible needs accumulates complexity quickly. Each feature may be defensible on its own, while the experience as a whole becomes harder to learn and maintain. The team starts spending more time explaining configuration than improving the underlying workflow.

Fieldnote chooses agencies with ten to fifty people that deliver recurring client services. This is not a claim that other customers have no value. It is a decision about where the next stage of product development will concentrate.

The segment definition still needs texture. The team interviews operations leads, project managers, and account directors. They ask about the last missed deadline, the last margin surprise, and the last time someone had to reconstruct a project’s status from chat messages. They examine artifacts: spreadsheets, status reports, meeting notes, and the messages sent when a project turned red.

Patterns emerge. Work is tracked in one system, staffing in another, and promises to the client in a third. Nobody has a dependable view of whether the next two weeks are still realistic. Managers compensate by holding meetings and relying on people who remember the history.

The opportunity is more precise than “better project management.” Fieldnote can help an agency compare its promises with its available capacity while there is still time to act.

That sentence contains a user, a problem, and a moment of value. It gives research a focus and design a test. If a proposed feature does not help that comparison become easier or more reliable, the team needs another compelling reason to pursue it.

Describe the Change in the Customer’s World

Teams often describe products through their components: dashboards, integrations, templates, automation, and reports. Those components matter, but they do not explain why a customer should reorganize work around a new tool.

A better description starts with the change the customer wants to experience.

For Fieldnote, the desired change is that an operations lead can enter the weekly planning meeting knowing which commitments need attention. Instead of collecting status updates from everyone, they can discuss a small number of concrete decisions. Move a deadline. Change the scope. Reassign someone. Speak to a client early.

This gives the product a practical standard of success. A beautiful dashboard that produces no better decisions is insufficient. A plain view that exposes the right conflict at the right time may be valuable immediately.

The team writes down the whole sequence. A project lead records an upcoming commitment. The system connects it to the people responsible. Someone updates the estimate when new information arrives. The operations lead sees a conflict. The team resolves it before the deadline becomes a crisis.

Each step reveals assumptions. Will people maintain estimates? Does the agency trust the capacity data? Who has permission to change a commitment? If the product identifies too many risks, will anyone read them?

These questions turn an attractive idea into something that can be investigated. They also prevent the team from confusing a feature being available with a customer receiving value.

Decide How the Product Will Win

A painful problem is necessary, but it does not automatically create a good business. Customers may already have acceptable ways to cope. A competitor may solve the problem well. The cost of switching may exceed the benefit of improvement.

Fieldnote’s main competitor is not another startup. It is an experienced operations lead with a spreadsheet and a weekly meeting. That arrangement is flexible, familiar, and already paid for. Replacing it requires more than a tidy interface.

The team chooses to compete on speed to a trustworthy planning view. An agency should be able to connect its existing work tracker, confirm a few commitments, and discover a useful conflict without migrating all its projects.

This choice has consequences. Integrations become central to the product. Setup must be forgiving. The product needs to show where information came from and when it was last updated. It should work alongside existing tools before asking to replace them.

It also limits other ambitions. Fieldnote will not spend the next quarter building a full document editor or a sophisticated internal chat system. Those features might increase time spent in the product, but they do little to improve its chosen advantage.

A strategy becomes useful when it makes a reasonable request easier to refuse.

This is where differentiation becomes operational. It stops being a phrase in a presentation and becomes a pattern in resource allocation. The team spends more effort on reliable imports than on elaborate customization because its success depends on customers trusting a planning view quickly.

Make the Tradeoffs Explicit

Every strategy has costs. Hiding them creates confusion later, when the team discovers that a decision everyone supported in principle is difficult to accept in practice.

Fieldnote’s chosen direction means some enterprise requests will wait. It means the product will depend on external systems that occasionally change their APIs. It means the sales team needs to qualify agencies carefully rather than treating every project-based business as a perfect prospect.

It also means the company must resist a tempting metric: total activity. A successful customer might spend less time in Fieldnote as the product gets better. The operations lead arrives, identifies three issues, makes decisions, and leaves. Measuring success through session length could encourage the team to make that workflow slower.

The leadership team records a few explicit commitments:

• Prioritize repeatable agency workflows over general-purpose flexibility.
• Support existing sources of work data before building replacement tools.
• Make uncertainty visible rather than presenting fragile estimates as facts.
• Prefer fewer actionable alerts to a comprehensive stream of warnings.
• Delay large-account requirements until the core planning workflow is dependable.

These commitments are useful only if they survive contact with actual decisions. When a prospective customer offers a large contract in exchange for a custom reporting module, the team has to consider the real opportunity cost. The answer may still be yes, but the exception should be deliberate and its consequences visible.

Turn Direction Into a Sequence

A strategy is not a detailed roadmap, yet it should produce a believable sequence of work. Without that sequence, the gap between ambition and execution remains too large.

Fieldnote identifies three uncertainties. First, can it build a sufficiently accurate view from the tools agencies already use? Second, will managers act on the conflicts it surfaces? Third, will that improved planning become valuable enough to support a paid subscription?

The team does not need to resolve all three by building the complete product. It starts with a small number of partner agencies and manually helps assemble their weekly planning views. This is slow, but it reveals whether the information is useful before the team invests in automating every connection.

Next, it builds the import path for the most common work tracker among those agencies. It includes a simple way to correct imported data. The goal is to learn where trust breaks, not to demonstrate an impressive integration catalog.

Only after managers repeatedly use the view does the team invest in alerts and broader self-service onboarding. This ordering preserves options. If the planning view proves unhelpful, Fieldnote can change direction without carrying a large collection of features built around an unsupported assumption.

The sequence is guided by evidence, but it is not directionless. Each step tests a part of the same underlying argument: agencies will pay for an earlier, more dependable view of delivery risk.

Measure Value at Several Levels

One metric rarely captures the whole argument. A business outcome can tell the team whether it is succeeding while offering little guidance about what to improve tomorrow. A local product metric can be actionable while missing whether the business is becoming healthier.

Fieldnote separates its measures into three levels.

Level	Question	Example signal
Customer value	Is the planning workflow helping?	Managers identify and resolve a commitment conflict before it becomes urgent.
Product behavior	Is the necessary workflow happening?	Agencies maintain upcoming commitments and revisit the planning view each week.
Business result	Does the value support a durable business?	Suitable agencies renew, expand usage, and require manageable support.

None of these signals should be interpreted alone. Weekly visits could mean the product is useful, or that users are repeatedly trying to fix bad data. Renewals could reflect strong value, or simply an annual contract that has not reached its decision point.

The team combines counts with conversations. It asks a manager to walk through an actual decision made with the product. It examines accounts that stopped returning. It checks whether the same small group of unusually motivated customers accounts for nearly all the positive feedback.

Measurement is most helpful when it changes a decision. If a dashboard grows while the team continues doing exactly what it had already planned, the dashboard may be reporting activity rather than supporting learning.

Keep the Strategy Close to Everyday Work

Strategy often disappears after planning because it lives in a document people rarely open. Daily work is governed by tickets, requests, incidents, and whichever deadline is nearest.

Fieldnote introduces a short product review every two weeks. The team looks at a customer decision, a piece of recent evidence, and one disputed priority. The purpose is to check whether its current work still follows the argument it agreed to pursue.

An engineer can point out that imported estimates are frequently stale. A designer can show that managers misread the difference between a risk and a confirmed delay. A salesperson can explain that otherwise suitable agencies hesitate because their client data is sensitive. Each observation may change what the team does next without requiring a new strategy.

The distinction matters. Changing an implementation approach is different from changing the customer or the reason the product will win. Teams need room to adapt methods while retaining enough continuity to learn whether their direction works.

A useful strategy document is therefore brief enough to revisit. It states the situation, the chosen customer, the desired change, the advantage being developed, and the major tradeoffs. Supporting research can be extensive, but the decisions themselves should be understandable without a guided presentation.

Know When to Change Your Mind

Persistence and stubbornness can look similar from inside a team. Both involve continuing when the result is uncertain. The difference is how honestly the team treats evidence against its assumptions.

Fieldnote decides in advance what would cause it to reconsider. If suitable agencies cannot maintain the minimum data required, the workflow may be too demanding. If managers see risks but lack the authority to act, the company may have misunderstood the buyer and user. If the product improves planning but agencies consistently decline to pay, the value may not support the intended business model.

These are different failures and deserve different responses. Poor onboarding might call for a better import flow. A mismatch between user and buyer might call for a different sales conversation. A problem that is real but economically weak may call for a more substantial change in direction.

Setting review conditions ahead of time helps the team avoid explaining away every disappointing result. It also protects promising work from being abandoned after one difficult week. Evidence needs context, and a learning process needs enough time to produce a meaningful pattern.

The team keeps a record of what it believed, what it tried, and what changed. Over time, this becomes more valuable than a polished story that makes every decision appear inevitable.

The Quality of the Choices

After six months, Fieldnote still has plenty of unanswered questions. Its integrations are imperfect. Some agencies do not fit. Its roadmap contains fewer ambitious features than it once did.

Yet the company is easier to steer. Engineers understand why data reliability deserves attention. Designers can explain which decisions the interface should support. Salespeople recognize a suitable customer earlier. Leadership can discuss a new opportunity in terms of the direction already chosen.

The strategy has not removed uncertainty. It has given uncertainty a structure. The team knows which assumptions matter, which evidence to seek, and which opportunities would require a conscious change of course.

That is a practical standard for product strategy. It should make the next decision clearer while preserving the ability to learn. It should connect the customer’s situation to the company’s economics. And it should remain specific enough that two people facing the same tradeoff are likely to reach compatible conclusions.

The final test happens on an ordinary afternoon. A customer requests a feature. An engineer spots a weakness. A competitor announces something new. The team has limited time and several plausible options.

Can it explain what deserves attention next, and why?

When the answer is grounded in a shared set of choices, strategy is doing its work.