Ever feel like your software development team is the rope in a corporate tug of war? On one side, customer projects are pulling for urgent enhancements and changes with fixed deadlines. On the other side, product management wants to push new revenue-generating concepts into the roadmap. And somewhere in the mix, you’ve got legal requirements, bug fixes, and a whole list of “must-haves” from various departments—all competing for the same developer hours.
If this sounds familiar, you’re not alone. Many software companies struggle to balance multiple priorities. The result? Missed deadlines, internal and external frustration, last-minute scrambles, and half-baked requirements. In this post, we’ll explore why everyone’s fighting for development time—and the things you are in your approach to stop the chaos.
Multiple demands, limited time
It’s common for companies to have to juggle multiple work streams. They fall into two categories: the things that you want to do and the things you have to do.
Customer projects come with tight deadlines you’ve promised to meet in a contract or statement of work. Your product management team has a powerful internal vision with the potential to unlock significant business value, generate new revenue streams, and revolutionise the industry through industry-leading customer satisfaction. If you only could get to the work that would make it a reality.
Then, there are the laws and changes in legislation in the country or countries you serve that you need to stay on top of. Plus the operational incidents and special requests from customers that threaten to drop you product at the end of the month.
Meanwhile, the development team has a finite amount of hours, story points, or sprints they can devote to each project. It is your fixed cost asset that seems to continuously deliver variable results. You don’t understand why this product building machine made up of humans just can’t get anything done predictably. The answer is simple but you won’t want to hear it: your setup is delivering exactly the results it’s design to produce.
Let that sink in.
Why the current approach isn’t working
You might already be using a task management tool like Jira or a prioritisation method like WSJF (Weighted Shortest Job First). So what? Jira is just a task management tool and WSJF is just a formula. What you put into Jira and how you come up with the numbers for WSJF is where the magic happens. It’s the hard stuff you are unable to do well: content.
Let’s start with the elephant in the room: unclear requirements and an inconsistent approach to requirements management. If developers don’t understand what they have to build (or they have to spend a lot of time to understand it) estimations will be guesswork. Mistake number 1: document what you want to build in Jira tickets. To be clear, you can work like this, you can build a product. It’s just really really expensive and hard. Imagine you were tasked with painting the sunset. You are sitting at the beach facing west but can only look at the sunset through a straw. You can see something beautiful through that 0.5 cm circle, but it takes more cognitive effort to imagine what the whole sunset looks like and, therefore, how the sunset looks as a whole. With one Jira task you see one piece of the puzzle but you don’t see the whole.
Mistake number 2: no standardised set of artefacts to describe what you want to build. Product management at Clark Germany was metrics driven while I was there, I imagine it still is.Every new feature needed to describe how usage analytics would be collected for every new development. This was important for building but it was also important to know and understand what each of the collected metrics meant years later. So that we, product manager, wouldn’t forget to specify which metrics were to be collected, the product requirements template had a section for analytics.
If your requirements process is suboptimal, that will lead to a second problem, no common understanding of what has to be built and why we are doing it in that order. Customer projects, product features, and legal tasks might live in the same backlog, but no one agrees on the order of execution. It is the role of product management to keep everyone aligned and make it easy for stakeholders to see how their requests stack up against others. But if it’s hard to understand what we have to build (requirements management) and why we have to build it, it’s hard to understand why one thing is more important than another. The result: everything seems equally urgent.
You might have a prioritisation formula like WSJF, but if the details or scoring are not well documented for everyone to see, analyse and question, people lose confidence and escalate until they get an answer from the “top”. You have opaque, as opposed to transparent, prioritisation. No one’s truly sure why certain features get bumped ahead, leading to more conflict, discussion and last-minute escalations.
Even if you measure how many tickets or story points your teams can finish each sprint, you might not have a forecast that matches upcoming demands. Without a simple way to compare supply and demand, your sales team will commit to deadlines that will create chaos a few months later.
The result is frustration, both external and internal. Customers are frustrated. Delays or incomplete features harm customer relationships—especially if they’ve been promised a tight turnaround. Your precious software development team is frustrated. It’s become a demotivated team of developers that feels constantly behind, working from half-baked specs. Product owners scramble to patch holes in requirements, undermining your strategy based in excellent execution throughout your value chain.
Inefficiency, obscurity and confusion lead to time wasted and waste leads to lost opportunities. Potential revenue-driving features get sidelined by chaotic project scheduling or firefighting. The show must go on. Everyone does their best, but given the circumstances, shortcuts must be taken and these lead to technical debt. Shortcuts pile up when the team rushes to meet deadlines without enough clarity or time for quality assurance.
The missing pieces: content
To resolve this tug of war, you need a unified approach that answers these key questions:
- How do we capture requirements in a way that’s consistent, complete and systematic?
- How do we prioritise transparently, so every stakeholder trusts the process?
- How do we track the development team’s capacity and plan ahead for upcoming projects—whether from customers or internal ideas?
- How can we keep everyone aligned throughout the process, so important details don’t fall through the cracks?
A single, integrated framework can offer one backlog that consolidates all potential work—customer, internal, legal, or otherwise. The order of the backlog items reflect priorities and the inputs that lead to that order are transparent, anyone can understand exactly why one request might outrank another. The work to be done is clear. Requirement artefacts that help visualise end-to-end processes (storyboards, flow diagrams, etc.) are created for every new development to reduce misunderstandings and rework. When work on an enhancement is likely to start and end, is visible. Capacity planning that shows how many features you can realistically deliver in the next sprint, month, or quarter is in place.
What’s Next
Over the next few posts, I’ll introduce a practical way to coordinate customer projects, product ideas, and legal demands within a single system. We’ll call it “The Compass Method” (though the name might still be up for debate!). Think of it as a compass that points everyone in the same direction—helping your company navigate the complex journey of software development without losing sight of deadlines or strategic goals.
In the next post, we’ll dive into the key concepts that form the foundation of this method: clearer requirements, a unified backlog, and transparent prioritisation. Then we’ll explore how to visualise capacity, incorporate customer-driven features, and ensure deadlines aren’t just met but managed in a way that keeps your dev team sane.
If you’ve been caught in the tug of war for development time—constantly juggling conflicting demands—stay tuned. By the end of this series, you’ll have a blueprint to keep priorities clear, requirements robust, and everyone rowing in the same direction.
Join the Conversation
Have a story? Feel free to share how your company handles (or struggles with) conflicting requests. Questions about the approach? Drop them in the comments or shoot me a message. Until then, brace yourself for the next post, where we’ll break down the essential building blocks for a less stressful, better aligned software development experience.
Thanks for reading! If you find this topic valuable, share it with a colleague who might be caught in the middle of their own development tug of war. Let’s end the chaos and replace it with a system that works for everyone.