SCQA Framework in Practice: A Product Prioritisation Example

In this fictional (or maybe not so much) story, you might recognise some common patterns. Alex, a Senior Product Manager, has just over 50 items on the roadmap. Seven of them are marked as urgent and important. Three stakeholders want different but arguably the most important things to ship by the end of the quarter (as they have different incentives and different goals), and the engineering team lead has just asked, politely but firmly, for the team to stop being pulled in many directions at once.

This is the part of the job that no one really talks about.

Frameworks look clean on slides. The room where decisions actually happen isn't. Everyone is trying to fight for product and engineering time.

Here's how the SCQA framework cuts through it.

Situation: Before anything gets prioritised, Alex anchors on what's real. Not the plan or the roadmap. What the data says, what customers are pushing for, and where the market is actually moving.

It's always tempting to jump straight to the features everyone's asking about. Resisting that instinct is probably the most important part of the whole exercise but of course it's a bit scary becuase it might lead to some conflic.

Complication: There's limited product and engineering capacity. Perhaps, a bit of technical and product debt, a lack of data points. There was a roadmap inherited from a previous PM that nobody fully believes in anymore. The SCQA framework helps smooth tensions and name them clearly.

Question: Then Alex cross-references the key points, what the business is trying to achieve, talks to the wider teams, looks at drop-off data, and asks the question: What should we do next and why?

Answer: A set of bets with reasoning attached. (As a PM, always provide your rationale even if you think it's wrong. If it is, it's probably because you were missing some context, so use it as an opportunity to learn.) Alex lands on 3 things she can defend in a room, each with a clear line back to a specific customer pain and/or business outcome. Some things get cut not because they're bad ideas but because a half-built feature is worse than nothing.

The SCQA structure gives Alex something to return to rather than starting from scratch each time - which is probably the most practical thing about it, though I'm not sure that's obvious from the outside looking in.

If you want a one-page version to work from, the SCQA cheat sheet has the template.