Product Strategy

Products get built without the word. The trouble starts at the moment of choosing what to build. A request from a large account, a feature the CEO saw in a competitor yesterday, and the most upvoted item on the user forum all look equally reasonable when they sit in the same list. Stack ten reasonable items and a team tries to do ten, and a quarter later nothing has landed while the next list fills up again.

The failure shows up the same way in every meeting. Early at Pagedeck, Grace would ask whether something was hard to build, Mia would say two weeks, and the item went in. The only thing exchanged was an estimate. Nobody asked whether the thing was worth building, because there was no yardstick to hold it against. Six months later Pagedeck had thirty features attached to it, and accounts were renewing because of two of them.

Without a yardstick a team also can't say no. "We're not doing that" sounds like a personal preference, so the more senior the requester, the harder it is to push back. The order of the list ends up being set by volume rather than by direction. The people building get worn down too. When last quarter's careful work is used by twenty people and this quarter's list is assembled the same way, doing the work well starts to feel beside the point.

One more thing breaks in that state: the team stops being able to learn. Thirty scattered features mean thirty half-tested guesses, and none of them ran long enough or reached enough people to say whether it worked. A quarter spent on two bets produces two answers you can act on next quarter.

Product strategy exists to put an answer behind "why aren't we doing that." The load-bearing part of a strategy document isn't the list of things the team will do — anyone can make that list long. It's the list of things the team won't do, which stays empty until somebody decides what to give up.

On the product axis, strategy sits in the group of terms about where to go. A one-sentence picture of the far goal is the product vision, the choice of where to concentrate resources on the way there is the product strategy, and the same choice laid on a calendar is the product roadmap. Strategy can't stand alone, so it comes paired with a target market that narrows which customers are being fought for, and a competitive analysis that lines up rival products by feature and price to find the gap.

Six terms sit under product strategy, all in the components group. Each one names a decision a strategy document has to make, so six answers add up to one strategy. In order, they fall into three parts: what to judge by, where to stand in the market, and how much to do yourself.

1. Product principles — the team's written agreement about which way to lean when a call is close. They are written as one side losing: "we choose reliability over speed." Principles that say both things are good settle nothing in a meeting. Holding that one, Pagedeck takes the work that drops save failures from one in ten thousand to one in a hundred thousand before the work that shaves 0.3 seconds off a save.
2. Positioning — the slot the product occupies in a customer's head. Being remembered as "a document editor" and being remembered as "where our team's meeting notes stop getting lost" are different slots. Aim at the first and you compete on fonts and tables; aim at the second and connecting to the calendar to surface last month's notes comes first. The slot decides who you sell to, not just what you build.
3. Differentiation — a strength competitors can't easily copy, measured in how long copying would take rather than in feature count. If a competitor can match it by adding a button, it isn't differentiation. If it needs two years of usage history behind a recommendation, it is. When a new customer says why they picked you, the answer should come from here.
4. Moat — a structural barrier that gets harder to cross over time. Differentiation is today's edge; a moat is the mechanism that widens that edge on its own. The usual shape is one where each additional user makes catching up harder. Once three years of meeting notes sit in Pagedeck and documents cross-link between teams, a rival can ship identical features and customers still won't move, because moving costs too much.
5. Product portfolio — the roles several products play for one company and how they combine. One is kept free as the door that brings new customers in; another is where the money is collected. Skip the role assignment and two products chase the same customer with the same pitch and eat each other's revenue. A single-product company can leave this one blank.
6. Build-buy-partner — deciding whether to build a capability, purchase it, or wire in someone else's. The call comes up wherever good outside options already exist, like payments or video calls. Building takes six months and leaves you free to change anything; wiring in an outside service takes two weeks and hands you their price increases and their outages. The deciding rule is usually simple: build it if it's on the differentiation list, buy or borrow it if it isn't.

Two of the six are worth separating carefully, because teams use them interchangeably and then wonder why the strategy doesn't hold. Differentiation answers "why us, today." A moat answers "why still us, in three years." A product can have the first without the second — a better editor with a faster engine wins deals this year and loses them the moment a larger competitor copies the engine. The reverse also happens: a product with real switching costs but nothing distinctive keeps existing customers and stops winning new ones.

The six aren't a menu of separate choices. They hold each other up inside a single sentence. You can't say what counts as differentiation until the slot in the customer's head is picked, and you can't decide what to build versus borrow until differentiation is settled. Whatever you decide to borrow has effectively been declared outside your strengths, which is how requests in that area end up on the not-doing list. That's the moment strategy does real work in a meeting.

"That's off-strategy, so it's not happening this quarter."

Not a statement about whether it can be built. The refusal is being anchored to an agreed document rather than to one person's judgment.

"What's our strategy again? I can't call this one."

A request for a yardstick to separate two options that both look fine. Either there is no strategy, or the document exists and never reached the people doing the work.

"That's not a fight we're trying to win."

A declaration that the team won't chase an area where a competitor is strong. It concedes the loss on that item and refuses to spend resources closing it.

Two requests collide in Pagedeck's quarterly planning. The enterprise account Sofia handles wants per-person read permissions on every document, and the most upvoted forum post asks for editing on phones. Building both takes the whole quarter.

With no yardstick, the larger contract wins this room by default. Grace opens the strategy document and reads the target again: Pagedeck is aimed at teams under fifty people, and organizations that need per-person permissions are usually bigger than that. Mia adds numbers. Three accounts asked for permissions, they are the larger ones by contract value, and building it costs the next quarter as well. The room lands on mobile editing, and the permissions request is logged as "deferred, not our current target" rather than as a rejection. When it comes back in six months, the question on the table will be whether to change the target, not whether to add the feature. The distinction matters because the two questions go to different people. Changing a target is a decision Grace makes with the numbers Mia brings; adding a feature is something any loud meeting can do.

Sofia takes that answer to the customer as it is. Instead of saying no, she says which kind of team Pagedeck is building for right now, which lets the customer place themselves. One of the three accounts left on the spot. Two stayed. Strategy doesn't remove losses like that one; it picks in advance which losses you're willing to take. The account that left was a loss the team had already agreed to accept months earlier, in a quiet room, with numbers in front of them — which is a very different thing from losing it by accident in a meeting nobody planned.

The most common mistake is treating strategy as a pleasant declaration. A line like "we give teams the best collaboration experience" sits on page one of most strategy documents, so it looks like the strategy. Nobody objects to it, and agreement takes five minutes. But a sentence nobody objects to is a sentence that chose nothing. Strategy is a choice, so something has to be on the discarded side, and a sentence with no discarded side filters no requests. Leave it there and three months later, when someone asks whether a request is on-strategy, both answers are defensible — and the order goes back to being set by volume.

The other frequent mistake is believing a strategy must never change. Strategy is supposed to be long-range, so turning sounds like admitting failure. In practice a team changes it when evidence piles up that an assumption underneath it was wrong, and that decision has a name: pivot. The trigger is evidence, not mood. Paid conversion among the under-fifty teams sitting at 3 percent for two straight quarters is a signal; one contract falling through this month is not. Teams that can't turn keep staffing a direction they already know is off, and teams that turn every week never hold any direction long enough to see a result. Most teams handle this by fixing one slot per quarter to look at the strategy, check whether the assumptions still hold, and either leave it alone or choose what to give up next.