14 June 2026 · Helen Beckford
Frameworks Don't Prioritise. Behaviours Do. (6/6)
This is the final part of a 6-part series on the behaviours that make prioritisation actually work. Catch up on earlier parts: Part 1: The "No, Not Yet" Muscle | Part 2: Urgency Is Not Importance | Part 3: The Art of the Challenge | Part 4: The Leader's Blind Spot | Part 5: ROI Isn't a Spreadsheet Exercise
The Issue: A roadmap shouldn't be finalised until the resources to deliver it are confirmed, and that includes the creative alternatives.
Over the last five weeks, I've unpacked the behaviours that make prioritisation stick; from saying "not yet" with confidence, to filtering urgency from importance, holding the line, navigating emotional attachment, and reframing ROI so every team has a voice. However, there's one final behaviour that separates businesses that deliver from businesses that stall: the willingness to get creative about how something gets delivered before the roadmap is locked.
Too many businesses finalise their roadmap based on what and when, then discover how doesn't work once delivery begins. The creative problem-solving that should happen during roadmap creation gets skipped. And by the time the resource gap becomes visible, the team is already committed and the options are limited.
The instinct when capacity falls short is to hire. But hiring takes months. There might not be budget. And critically, even if there were, the business might have already maxed out its capacity for change. More hands doesn't always mean more delivery. Sometimes it means more complexity, more onboarding overhead, and more pressure on a business, its people, and its technology that simply cannot absorb more change right now.
What I see everyday: "We can't do it" replacing "How else could we do it?"
The behavioural trap here isn't about resources. It's about mindset. When a team hits a capacity wall, the default response is binary: "We need to hire" or "We can't do this right now." What's missing is the third option, explored during roadmap creation, not after: "The priority is right, so how do we deliver it differently within our current constraints?"
I covered this in depth in a previous newsletter, Right Plan, Wrong Headcount, where I shared how creative resourcing should be built into roadmap creation and finalisation. But what I want to focus on in this final part of the series is the behaviour behind creative problem-solving. Because having the ideas isn't enough if the culture doesn't support them.
Sometimes the simplest solution is the best one and the most technical one is the worst.
There's a temptation in scaling businesses, especially those investing heavily in technology, to assume every solution needs to be technical. A platform. An integration. A SaaS tool. But the most creative solutions I've seen are often the least technical.
A recent example. A client had a platform already in development that included a user registration flow for participants joining a training session. Additional testing of the registration feature would have been useful but when I looked at the actual use case, it simply wasn't needed. The entire USP of this particular session was that it was face-to-face. Students were physically together in a classroom. One tutor was facilitating in the room. One tutor was joining online.
So why introduce unnecessary technology into the room? Why add registration steps for end users who are already sitting in front of you? The simplest solution was to capture emails with pen and paper in the room and send a single Google Meet invite to the online tutor. Not even the students needed the invite, it was being facilitated for them.
No additional development. No registration flow testing. No user friction. The face-to-face experience, the thing that made the session valuable, was protected. And the team's capacity was freed for work that genuinely required technical effort.
The lesson? Just because you're building a technical solution doesn't mean every problem within it needs a technical answer. Sometimes the creative move is to step away from the platform and ask: "What does the end user actually need in this specific scenario?"
This isn't an isolated case. In previous engagements, I've built creative solutions directly into the roadmap during the planning phase:
Redeployed a full-stack developer to focus exclusively on front-end work: unblocking multiple roadmap items without a single new hire. Agreed during roadmap creation, not as a firefighting decision.
Authorised a 3PL partner to absorb additional operational steps: freeing internal capacity for higher-value work by expanding the role of a partner already embedded in the process.
Brought in temporary call centre staff to bridge a known spike: rather than rushing a software implementation when there was already too much technical and business change happening simultaneously. Even with unlimited resource, the business couldn't have absorbed another implementation at that point.
Descoped initiatives to MVP: where the strategic outcome could still be achieved with a leaner first version, buying time and reducing pressure without losing momentum.
Each solution started with the same question during roadmap creation: "The priority is right. The default route isn't available, or isn't sensible. So what else could work?"
What needs to happen: Build the creative problem-solving muscle into your roadmap process.
Creative resourcing isn't a last resort. It's a behaviour that needs to be embedded into how you build and finalise your roadmap. No roadmap should be signed off until the how has been stress-tested alongside the what and when.
Here's how I approach it:
Challenge the assumption that every solution is technical. Before any initiative enters development, ask: "Is there a simpler, non-technical way to achieve the same outcome for the end user?" If the answer is yes, even partially, you've just freed capacity for work that genuinely needs a technical build.
Stress-test capacity for change, not just capacity for work. Headcount isn't the only constraint. Ask: "Can our business, our people, and our technology absorb this change right now, alongside everything else that's in flight?" If the answer is no, more people won't fix it. You need to sequence differently or find a creative alternative.
Reframe "constraint" as "catalyst." When a team hits a resource wall during planning, the natural reaction is frustration. But constraints force creativity. The question "How might we deliver this with what we have?" often produces better, leaner solutions than unlimited budget ever would.
Expect, and welcome, initial resistance. Not every stakeholder will embrace a creative workaround immediately. Some will see it as a compromise. Some will push for the "full" solution regardless of capacity. This is where the behaviours from Parts 1-4 come in, the confidence to say "not yet" to the full build, the data to justify the interim approach, and the empathy to bring the stakeholder along.
Always define the bridge and the re-entry. A creative solution is temporary by design. Make the interim nature explicit: "This buys us X months. Here's what needs to be true before we invest in the full solution." This prevents the workaround from becoming permanent, and gives stakeholders confidence that the long-term vision isn't abandoned.
Celebrate creative wins as loudly as "full" deliveries. If a team saves three months of development time by redeploying skills or simplifying an approach, that's a strategic win. Recognising it publicly signals to the organisation that creative problem-solving is valued, not a sign of cutting corners.
A final reflection on this series.
Over six weeks, we've covered the behaviours that sit underneath every successful prioritisation framework: saying "not yet," filtering urgency, challenging drift, navigating emotional attachment, reframing ROI, and getting creative with delivery.
Here's why I believe this matters more than ever. In an age of AI-generated frameworks, automated dashboards, and instant prioritisation templates, the tooling has never been more accessible. But tools don't prioritise. People do. And people bring fear, ego, bias, habit, and emotion into every decision.
The framework isn't enough. It never was. What makes prioritisation stick is the human behaviour wrapped around it, the willingness to have uncomfortable conversations, the discipline to hold the line, and the creativity to find a way forward when the obvious path is blocked.
That's what I've tried to capture in this series. Not a prioritisation methodology, but the behavioural operating system that makes any methodology actually work.
The Behaviours That Make Prioritisation Stick — Your Cheat Sheet:
The "No, Not Yet" Muscle: Build the confidence to protect what's agreed. Frame every "no" as "not yet, with conditions."
Urgency Is Not Importance: Before anything jumps the queue, it must survive three questions: What's the impact today? Why this deadline? What's the evidence?
The Art of the Challenge: Keep agreed priorities visible. Challenge drift with data, not opinion. Expect to do it repeatedly.
The Leader's Blind Spot: Acknowledge emotional attachment. Separate the idea from the timing. Build bridges, not walls.
ROI Isn't a Spreadsheet Exercise: Teach every team to articulate the cost of doing nothing. Give non-commercial teams a voice in the boardroom.
Creative Solutions Over Default Headcount: Challenge the assumption that every solution is technical. Stress-test capacity for change, not just work. Define the bridge and the re-entry.
I work directly with leadership teams to facilitate alignment, challenge the behaviours that undermine good prioritisation, and build governance structures that fit a fast-moving business, not a corporate playbook. My approach is embedded, not advisory-from-a-distance.
Curious how your business scores on prioritisation and governance? Take my 3-minute leadership quiz to find out where your strengths are, and where the blind spots might be hiding. Take the quiz here.
Curious about how we could work together? Book a 20-mintue intro call - no pitch, just pattern matching.
Get the next one in your inbox
