A Positioning Statement You Can't Use to Reject a Feature Isn't One

Most positioning statements die the day they get approved. Someone puts them on a slide, everyone nods, and the slide goes into a folder nobody opens again until the next rebrand.

That's not a failure of writing. It's a failure of purpose. The statement was never meant to be read. It was meant to be used, specifically to reject things. And here's the part that gets missed: it has to survive being written on a calm afternoon, then hold up in a moment that isn't calm at all.

Here's the confusion I keep running into with teams: they treat a positioning statement as a description. It isn't one. A description tells you what the product is. A positioning statement tells you what the product isn't allowed to become. Those sound similar. They're not the same job.

The Slide That Nobody Argues With

I've sat through this exact slide more times than I can count: "We're building the best requirements engineering software in the world."

Nobody in the room disagrees with that sentence. That's the problem. A sentence nobody can disagree with can't help you make a decision either. It has no edges. It doesn't name who the product is for, what it refuses to be, or which problem it solves instead of the ten adjacent ones it could also plausibly solve.

That sentence is a mission, not a positioning statement, and the two get confused constantly because both sound like "big purpose" language. The test that separates them: a mission describes what you're doing right now, present tense, always true. A positioning statement makes a specific bet about a specific group of people and a specific gap in what already exists for them. One is aspiration. The other is a claim you can be wrong about, which is exactly what makes it useful.

Five Slots, One Sentence That Has to Hold

Geoffrey Moore's positioning template forces that claim into the open. Five slots, one sentence:

FOR [target group] WHO [problem/need], [product] IS A [category] THAT [core benefit]. UNLIKE [alternative], we [differentiation].

Both sentences fill every slot correctly. Only one of them can reject a feature request.

Every word in the weak version is true. None of it is falsifiable. It could describe forty different products, including several that don't exist yet.

The sharp version names a real person, a real symptom, and a real category boundary. It also rules things out. If someone proposes a feature for solo developers with no team review process, this sentence answers immediately: that's not who we're for. Not because the feature is bad. Because it belongs to a different sentence.

The Room Gets Bigger, the Sentence Gets Softer

Here's a pattern I've watched play out the same way more times than I'd like: someone drafts a rough positioning statement, shows it to three more stakeholders before it's solid, and each one asks for a small adjustment to make it "more accurate." By round four, the sentence describes everyone a little and nobody exactly.

Vision-by-committee doesn't fail because people disagree. It fails because agreement is the wrong goal at that stage. A positioning statement everyone can live with is precise enough to help nobody. The softening isn't a compromise. It's the erosion of the one thing the sentence was supposed to do.

The fix isn't skipping stakeholders. It's sequencing them. Someone writes a sharp, defensible rough draft alone, or in a very small group first, sharp enough that it might be wrong. Only then does it go wider, for challenge, not for softening.

Why You Write It Before You Need It

Here's the part that took me a while to name properly, and it changes how I think about the whole exercise.

There's an old story about Odysseus and the Sirens. He wants to hear their song, and everyone who hears it wants to steer toward the rocks, and everyone who steers toward the rocks dies. So before he's anywhere near them, while his judgment is still his own, he has his crew tie him to the mast and orders them, in advance, to ignore anything he says once the song starts. He doesn't trust future-him to make the call. He builds the constraint now, for the version of himself that won't be able to.

A positioning statement does the same job, and it's worth being honest about why it has to.

You don't write it because you're weak-willed or bad at saying no. You write it because the version of you who'll be asked to reject a feature isn't the version of you sitting here now. That future you will be looking at a Slack message from a paying customer who's given you two years of loyalty and referred you three more clients, asking for something that sounds entirely reasonable. The emotional pull in that moment is real. Feeling it isn't a failure of discipline. Saying yes will feel like keeping the relationship. Saying no will cost you something you can't easily get back, and it will feel like that in the moment too.

That's precisely the moment a positioning statement exists for. Not the calm Tuesday when you write it, but the Thursday six months later, when someone you like is asking you for something that isn't yours to build.

This is why "just write it more precisely" undersells the exercise. Precision matters, but it isn't the whole job. The sentence also has to be written early, before the customer, the request, and the weight of that particular conversation exist yet. Write it after the fact, in the middle of the ask, and you're not consulting a positioning statement anymore. You're negotiating with yourself in real time, with a person on the other end of the message watching you do it. You'll lose that negotiation more often than you'd like to admit, for the same reason Odysseus would have steered straight for the rocks if nobody had tied him down first.

The Test

So here's the test, and it isn't about how the sentence reads on the slide.

Hand it to a developer with a feature request in front of them, from someone they don't want to disappoint. Can they use it to say: that's not what we're building? Hand it to a product owner staring at a request from the account that's kept the lights on this quarter. Can she point at the sentence and say this is why we're not doing that, and mean it, even though she likes the person asking?

If yes, you tied yourself to the mast in time. If the answer is a shrug, and everyone falls back on gut feeling anyway once the pressure shows up for real, what you wrote was a slogan with good production values. It never had to survive contact with a Thursday like that one.

The uncomfortable part: most teams find this out only when it's tested for real. They write the sentence, feel pleased with it, and it sits quietly for months, right up until a customer they genuinely don't want to lose asks for something outside the lines.

That's when you learn whether you built a mast or just a nice sentence about one.

If you want to turn a rough product idea into a statement like this, precise enough and early enough to survive contact with a real feature request, that's exactly what Speclr's Discovery phase is built to produce out of a structured conversation, not a template filled in alone. It's the first thing an AI-driven requirements engineering tool should get right, before a single requirement gets written. If you'd rather write yours first, our companion how-to piece walks through the process step by step.

Further Reading

Requirements Engineering for modern Software-Teams

A different framework, same underlying job: Module 02 of our RE course shows how Pichler builds that same filter across five fields instead of one sentence.

View the course