Blog Post

Blog post written by our Chief Product Officer - powered by a Large Language Model

I say no to 90% of ideas. That's not a personality flaw — it's the job.

The hardest part of building a product isn't deciding what to build. It's deciding what not to build — and having a system that makes those decisions consistent, defensible, and fast.

At Zontally, we use something we call the Product Strategy Cascade. It's six layers, top to bottom, from vision to delivery. Every feature, every sprint, every line of code traces back up the cascade to the company vision. No orphan work. No "we built it because someone important asked for it." No drift.

We're a strategy-to-execution company. It would be embarrassing if we didn't have our own house in order. So here's exactly how we do it, and here is our Product Strategy.

The cascade: six layers, one system

Think of the Product Strategy Cascade as a series of questions, each answered at a different altitude. The CEO operates at the top. The delivery team operates at the bottom. And everyone in between can look up or down the cascade and see exactly how their work connects.

Layer 1: Product Vision

"What does the product look like when we've won?"

This is the 3–5 year aspirational state. Not a feature list. Not a roadmap. A picture of what Zontally looks like when we've achieved what we set out to achieve — derived directly from the company vision.

The product vision doesn't change quarterly. It shouldn't even change annually. It's the fixed point on the horizon that everything else orients towards. If the vision is changing every six months, you don't have a vision — you have a mood board.

Layer 2: Product Principles

"What beliefs guide every product decision?"

These are 5–7 non-negotiable rules that resolve trade-offs before they become arguments. When two smart people disagree about what to build or how to build it, principles break the tie.

Good principles are opinionated. "We value simplicity" is a poster, not a principle. "We will ship fewer features with deeper workflows rather than broad features with shallow coverage" — that's a principle that actually changes decisions.

Our principles are the guardrails. They prevent us from drifting into building something that looks like Zontally but doesn't feel like it.

Layer 3: Product Strategy

"How do we win?"

This is where we declare our strategic bets. Where we're investing. Where we're deliberately not investing. Our differentiation thesis. The sequencing logic that explains why we're doing A before B.

Strategy is about choices. If your strategy doesn't explicitly say "we are NOT doing X," it's not a strategy — it's a wish list.

At this layer, we're answering questions like: What gives us an unfair advantage? Where can we be category-defining rather than category-following? What must be true for our product to win against the status quo?

Layer 4: Strategic Themes

"What big problems are we solving this year?"

These are 3–5 themes per year, tied directly to customer outcomes — not internal engineering ambitions. They're stable for quarters, not weeks. If your themes are changing every sprint, you're confusing tactical reactions with strategic intent.

Themes are where the product strategy gets translated into language that the whole company can rally around. Sales should understand them. Marketing should be able to message around them. Customer success should see them reflected in what customers experience.

Each theme should answer: "What customer problem does this solve, and why does solving it now matter more than solving something else?"

Layer 5: Roadmap

"What are we building, in what order, and why?"

This is where strategy becomes tangible. Initiatives prioritised using a clear framework — we use RICE (Reach, Impact, Confidence, Effort) — with rolling horizons:

3 months: Detailed. Committed. The team knows exactly what they're building.
6 months: Directional. High-confidence initiatives that are sequenced but not yet broken into stories.
12 months: Aspirational. Where we think we're heading, but with the intellectual honesty to acknowledge that it will change.

The roadmap is not a promise to stakeholders. It's a current-best-thinking plan that reflects the cascade above it. If a roadmap item can't trace back to a strategic theme, which traces back to the strategy, which traces back to the vision — it doesn't belong on the roadmap.

Layer 6: Delivery

"What ships this sprint?"

GitLab issues. Stories. Pull requests. The daily work of building software. This is where the cascade meets reality.

But here's what makes it different when you have the cascade in place: every engineer can look at their current sprint and trace the work back up through the roadmap, to the theme, to the strategy, to the vision. They know why they're building what they're building. Not because someone told them — because the system makes it visible.

That's not micromanagement. That's context. And context is the difference between a team that's executing and a team that's just busy.

Why we work this way

It's a decision-making tool, not a planning artefact

Most product frameworks produce beautiful documents that sit in Confluence and gather dust. The cascade isn't a document — it's a decision-making system.

When someone asks "should we build X?" we don't debate opinions. We check it against the cascade. Does it fit within a strategic theme? Does it align with our principles? Does it move us towards the vision? If yes, it goes into the prioritisation framework. If no, it's a clear, defensible "not now."

That takes the politics out of prioritisation. It's not about who shouts loudest. It's about what the cascade says.

It's a communication tool across altitudes

One of the most common dysfunctions in product organisations is that people at different levels speak different languages.

The CEO talks about vision and market positioning. The CPO talks about strategy and themes. The CTO talks about architecture and delivery. And everyone ends up in meetings where they're all technically talking about the same product but somehow not understanding each other.

The cascade gives everyone a shared framework with clear altitudes. You talk about the layer that's relevant to your audience, and everyone can look up or down to see how it connects. Board conversations happen at the vision and strategy layers. Sprint planning happens at the delivery layer. And the cascade is the connective tissue between them.

It enforces top-down thinking

We build top-down: vision first, then principles, strategy, themes, roadmap, delivery. Never the other way around.

This sounds obvious, but it's the opposite of how most startups work. Most startups work bottom-up — someone has an idea for a feature, it gets built, and then someone retro-fits a strategy narrative around it. That works when you have five people and one customer. It collapses when you scale.

Top-down doesn't mean command-and-control. The delivery team has enormous autonomy in how they build. But what they build is guided by the cascade. That's the discipline that lets a small team punch above its weight.

We practise what we preach

Zontally is a strategy-to-execution platform. We help organisations align effort to outcomes and close the gap between ambition and results.

If we didn't have our own rigorous system for doing exactly that with our product, everything we say to customers would ring hollow.

The Product Strategy Cascade isn't just how we build product. It's proof that the principles we're asking our customers to adopt actually work — starting with us.