A three-question filter you can apply to every feature request, every sprint review and every stakeholder conversation to keep your software project focused on outcomes that matter.

‍You've secured executive approval for your software project. The budget's signed off. The team is ready. But somewhere between kickoff and delivery, features pile up, priorities blur, and three months later, nobody can say whether any of it is moving the needle.

"Value is not measured in how many features you ship or the speed of delivery," says Jaco van Schalkwyk, Director and Head of Design at Kohde. "It's measured in business outcomes."

Here's a simple filter we use at Kohde to keep projects tied to those outcomes. Every feature request, at every stage, has to pass three questions. They're simple enough to remember, but difficult enough to enforce that many teams struggle to apply them consistently.

Here's how each one works in practice:

Question 1: Does this contribute to the goal we agreed on?

This sounds obvious, but it rarely happens because most teams never properly align on the goal in the first place. Walk into any project kickoff and ask the room what "value" means. You'll get a different answer from every person at the table.

"The design team wants a great user experience," Jaco explains. "The CFO defines value as cost saved or revenue protected. Operations want fewer manual processes. And the dev team wants clean, scalable architecture, which matters a lot but rarely makes it into the boardroom presentation."

When those definitions are different or unstated, the project defaults to building for whoever has the loudest voice.

"If everything is a priority, then nothing is a priority. You have to ask: what problem are we actually trying to solve? And almost more importantly, how will we know we've solved it?"

How to apply this: Before any development starts, get every stakeholder in the room and agree on one sentence: "This project succeeds when [specific outcome]." Write it down. Put it on every sprint review slide. Every feature request gets measured against that sentence. If it doesn't contribute, it goes on the backlog.

Watch for the urgency trap

Every feature request feels urgent when it comes from the right person. Legal wants full compliance from day one. Marketing wants a redesign before the next campaign. The CEO saw a competitor's launch and wants it replicated.

None of these is wrong. But they can't all be first. And urgency is not the same as alignment with your goal.

"Instead of 'we're not building that,' it becomes 'what's the smallest thing we can build that still gives you what you need, without spending six months on something that doesn't add value yet?'" Jaco says.

That reframe, focusing on the smallest thing that still delivers value, prevents the kind of scope expansion that derails timelines without shutting stakeholders down.

Question 2: How will we measure whether it delivered value?

If you can't measure it, you can't prove it worked. And if you can't prove it worked, you can't justify the next phase of investment.

"We'll all agree that this thing is going to deliver value. But then you have to ask: how are we going to determine that it actually did? That's where it falls flat. Nobody checks afterwards."

Without measurement, projects drift. The original goal gets forgotten after a month as new requests pile up.

How to apply this: For every feature that passes Question 1, define the metric before you build it. Cost reduced. Conversion improved. Manual hours saved. Processing time shortened. If the team can't name a metric, the feature isn't ready to be built yet.

Case in point: the auction company that didn't need an auction platform

"The client wanted an online auction platform," Jaco says. "We sat down and asked them to tell us how their business actually works. And we realised online auctions weren't going to solve their problem."

The real bottleneck? The company was sending 6,000 WhatsApp messages a week. Manually. Three staff members spent their entire working week messaging customers in batches of five.

"They had no visibility on what happened to those messages. Were people opening them? Blocking them? They were just throwing money into the air."

The measurable problem wasn't "we need an auction platform." It was: three full-time staff members are spending 100% of their working hours on a manual communication process with zero visibility on results.

Kohde built a lightweight communication tool instead. Investing in the right solution meant the same team now sends 15,000 to 20,000 messages in five minutes, with full visibility on delivery and engagement.

"Two years later, we still haven't built them an online auction platform. Because they don’t need one."

If the team had skipped Question 2 and just built what was asked for, the client would have an auction platform and still have three staff members stuck on WhatsApp all week.

Question 3: What happens if we don't build this?

This is the question that kills the most features and saves the most budget.

Every feature comes with three costs: building it, maintaining it, and the opportunity cost of what you didn't build instead. Understanding these trade-offs is essential to optimising how you invest.

"Ask yourself: what happens if I don't build this?" Jaco says. "Sometimes the answer is nothing. No missed opportunity. No risk. That tells you everything about whether it should be a priority."

How to apply this: Before approving any feature for a sprint, ask the team to answer: "If we don't build this, what breaks? What opportunity do we lose? What gets worse?" If nobody can give a concrete answer, the feature isn't a priority. Move it to the backlog and spend the time on something that passes all three questions.

Someone has to own this filter

A filter only works if someone is responsible for enforcing it. Jaco's definition of that person is simple: "The primary purpose of a product owner is to determine what the next most valuable piece of work is."

Not a project manager. Not a liaison. A person who decides what gets built next based on what delivers the most value to the business.

"That person ideally sits on the client side. They need to be embedded in the business, the culture, the values. A vendor can't do that from day one."

When that ownership is unclear, projects fail. Not because of technical problems, but because nobody is accountable for running every request through the filter. 

How to apply this: Before kickoff, agree on who owns prioritisation. Not who manages the project; who decides what gets built and what doesn't. That person needs to be close enough to the business to understand the goal, and empowered enough to say "not now" to a senior stakeholder when a request doesn't pass the filter. A well-established team with clear roles makes this significantly easier.

Both sides have to use it

One honest admission: staying focused on value isn't just a client challenge. Vendors drift too.

"We like to solve problems, and not all problems need solving," Jaco admits. "I was recently pushing one of the guys to fix something, and I stopped and thought: I'm doing exactly the thing I tell everyone else not to do. I'm asking him to fix something because it annoys me, not because it adds value."

The filter works both ways. Clients can use it to evaluate vendor recommendations. Vendors can use it to challenge client requests. When both sides commit to running every feature through the same three questions, projects stay lean, budgets stay intact, and the software you ship is the software your business actually needs.

Keeping your project focused on what matters

For most organisations, the hardest part of a software project isn't the technology; it's maintaining focus on the outcomes that justified the investment in the first place. This is where having the right development partner makes a difference. A team that doesn't just build what's asked, but challenges assumptions, validates priorities against business goals, and helps maintain the discipline of only building what earns its place.

If your organisation is planning a software initiative and wants to make sure it stays tied to real business outcomes, Kohde works with transformation leaders to keep projects focused on the things that matter.

Speak to Jaco and the team now.