Content strategy requirements: real or fake?
Content strategy is no stranger to change. A strategy must be ever-evolving to meet new business requirements. But how do you determine whether a requirement is real or fake?
Real and fake requirements
Everything changes and nothing stands still. — Heraclitus
When addressing new requirements, it’s important to determine whether they are real or fake.
“Real” requirements are grounded in core business or operational needs. They support growth, maturity, and extensibility. Real requirements are carefully planned and communicated, often with ample lead time.
Examples of real requirements include:
- increased language support
- new or broadened systems interoperability
- new target markets or new product offerings
- new publishing targets
“Fake” requirements usually appear abruptly and are not tied to business goals. While they may be posited as a requirement, they most often stem from operational or infrastructure problems.
Fake requirements stem from:
- personal wants
- one-off delivery requests
- unplanned systems changes
- sudden workflow changes
Personal wants are the most common sources of fake requirements. A team or department may want to do things “their way.” Someone’s pet project may enter the equation. Another group may insist on owning (and changing) a portion of the strategy. And, if the person demanding the “fake” requirement is senior enough, you may need to treat the requirement as real.
Prioritize appropriately
Content strategy is no different from other business or organizational strategies. Requirements feeding into the strategy must be grounded in core business needs or goals. They must be real.
Requirements that lack an explanation, are reacting to temporary problems, or stem from personal wants can derail a content strategy. Stay true to the business goals driving the strategy. Sometimes you can mold fake requirements into real ones; other times you may need to push back.
If your strategy is constantly changing, stop and take stock of your requirements. Are you prioritizing the real ones?
Larry Kunz
Great post, Bill. Can we add one more to the “fake requirements” list?
– Any requirement that relies on a specific tool’s workflow or feature set
Bill Swallow
Good addition. But, it can become “real” if there’s enough reason or demand for that tool to remain in the workflow (example: some other high level stakeholder’s domain).