You’ve probably heard the classic project management mantra: “Good, fast, cheap—your choice of two.” It’s catchy, it’s neat, and it makes you sound like a seasoned professional when you drop it in meetings.

But let’s be honest—it’s also a half-truth. Sure, it reveals something valuable, but it conveniently skips over a couple of key points for a work that addresses modern IT projects. Let’s dig in.

There is one crucial, but brutal reality check in the classic mantra. If someone insists on perfect quality, lightning-fast delivery, and rock-bottom costs - either expectations are low enough that whole phrase may be just not relevant or more likely, we’re walking headfirst into disappointment

When this happens, we usually step in with the intervention: “Okay, let’s optimise two dimensions and break the bad news about the third.” Truth is that framing this in such a way rarely gets applause. But hey, reality checks aren’t supposed to be fun - rather you know, real…

Why it’s useless in tech

The slogan on the same time oversimplifies and obscures various areas of development work. Just a few samples:

Cost does not resonate with developers - Like what was the list time team lead talked about price of a given user story? They talk about time and scope
Cost rarely works with product owners - At least not in a way assumed by this triangular relation. PO’s often work with fixed cost. Team of X developers, X licenses and here you go - deliver it on time with as good scope as you can.
It’s not always a tradeoff - And for sure not linear. Upping quality often reduces rework, waste, and delays, which can save time and money. But overdo quality above the expectations and no-one will notice the artwork you created, only higher budget or delayed delivery.
It originates from fixed work - whole concept works best (or only) for fixed-scope tasks. If you want 10 hand made cups that will set u back X$ and take 14 days. I can do it cheaper, but they will be less polished if you like - all works. Software doesn’t play by these rules. Developing software means figuring out what the real work is as you go.

The valid quality practice

As a title suggest - only practice that I believe makes sense in modern tech product management is scope. Instead of obsessing over speed or cost, focus on the one variable you can control. What you include and, crucially, what you leave out (for now) from the product.

But there is a the catch: managing scope well assumes your team has mastered two critical skills. Although sounding technical they are actually more social/soft ones:

1. Planning Incrementally

Every week, the team should be ready to decide what gets tackled next. Sounds simple, right? Except for teams used to excruciating planning processes that require endless sign-offs from overworked stakeholders. Not every task can fit into 2 week long sprint. Often you have to find a fay how to cut then feature requested into smaller pieces that would allow the stakeholder to raise crucial feedback earlier in the process. That feedback is a must if you want to nail the customer satisfaction. Some tips & tricks I use to achieve that:

Use mockups. Learn basic Figma skills or any other prototyping tool. We’re a visual creatures and often it’s better to materialise ideas in a concept that remove the cognitive load needed to share any opinion.
When mockups are obvious - consider decoupling frontend & backend development. Frontend tend to move on a bit quicker so while backend integrates on security and efficiency - we can nail down where given button should go.
Think in action flows. User stories. Individual interactions. Delivering whole page is cheeky as it contains a lot of functionality. What would be a single, individual user interaction that could bring us closer to the full experience though?

But my main tip here, you sometimes hard to swallow:

Most often it’s better to deliver something shitty, but quick & start improving, than spending weeks to polish the feature that’s not what user wanted.

Change is unavoidable so don’t fight it. Release according to your quality of done and keep on improving as you go.

2. Delivering Incrementally

Planning incrementally is one rail that you can run your Product Train on, but you need another to move anywhere. Shipping incrementally doesn’t just mean frequent releases - it means thinking in terms of impact. A new feature is only valuable if it reaches users without breaking what’s already there. Some strategies I use to achieve this:

Feature flagging. Not everything needs to go live at once. Wrap new functionality in feature flags so you can release it gradually, test it with a subset of users, or roll it back without deploying a hotfix.
Trunk-based development. Avoid long-lived feature branches that drift apart from the main codebase. Regularly integrate changes to minimize merge hell and keep things production-ready.
Prioritizing debt payback. Bugs and tech debt accumulate over time. The trick is not to wait until they become unbearable. Treat them like credit card debt—small, regular payments are better than a massive bill later.
Meaningful telemetry. For any system more complex than calculator you can rely on It looks good to confirm if it works well after new version went live. Response time, average number of non-success responses, resource usage - thanks to that you know right away if the deployment changes the app footprint in expected or unexpected way.
Automated checks, but don’t overdo it. CI/CD pipelines are your best friends, but they’re not a substitute for common sense. Too many flaky tests or slow pipelines kill momentum rather than help.

Most importantly, remember:
Your job is not just to deliver, but to keep things running while doing so. If your team can’t release quickly without breaking things, the process is broken, not the team.

Why It All Comes Back to Scope

Here’s the golden rule: in software, scope is your primary control variable.

Quality? Set it high, but reasonable. To quote Kent Beck from Tidy First:

Damn near the best we can do” usually works—unless lives are on the line, then it’s “better than the best we can do.”

Time and money? They’ll sort themselves out if you manage scope well enough.

The catch? Theory only takes you so far. In practice, people with decision-making power often act like they can lock down all dimensions at once. (Spoiler: they can’t.) You’ve probably seen this before:

“We need this feature in full by next month, and it has to be flawless.”
“We can’t add resources, but we also can’t drop anything from the scope.”
“Can’t we just work harder?”

This kind of thinking leads straight to burnout, missed deadlines, and a pile of half-baked features. By focusing on scope, you can offer real transparency and keep things from spiralling out of control.

Some practical ways to keep scope in check:

Make trade-offs explicit. If something new comes in, something old has to go. Keep a clear backlog of what’s being pushed out to make room.
Push for prioritization, not just additions. Everything feels important until you force a choice. Ask, “What can we live without right now?”
Deliver in layers. A feature doesn’t have to be all-or-nothing. What’s the simplest version that still provides value? Build that first, then improve.
Educate stakeholders. Many assume scope is elastic. Walk them through the reality: faster means smaller, bigger means later, and perfect means slow.

At the end of the day, managing scope isn’t about saying "no"—it’s about ensuring that when you say "yes," you can actually deliver.

Scope check is the best quality practice

Table of contents