After working in the Australian market for several years, I noticed a stark contrast to my experience in the Netherlands. Beyond the obvious differences between B2C and B2B products, one thing stood out above all else: there was a much stronger focus on services than on products.

Looking around and hearing about the experiences of colleagues and friends, it seemed that software development in Australia faced some significant headwinds compared to the larger European market I was accustomed to. The biggest difference was the service-led approach and the prevalence of building customer-specific solutions.

My theory is that this largely comes down to market size.

Although the Netherlands has a smaller population than Australia, Dutch businesses operate within the broader European market. They have immediate access to hundreds of millions of potential customers. In Australia, the total addressable market (TAM) for many software businesses is much smaller unless they successfully expand overseas—which is exactly what most of our unicorns eventually do.

This creates an interesting dynamic. Software companies often struggle to justify large upfront product investments because the local market alone may not be large enough to generate a strong return. Venture capital can help, but investors are typically looking for businesses that can address a significant market opportunity from the outset.

As a result, many Australian software organisations naturally drift toward a service-based model.

There is absolutely nothing wrong with this approach. In fact, it works very well in many situations. Customers request functionality, software companies work closely with them to build it, and everyone is happy. Sometimes those hours are billed directly. Sometimes the work is absorbed into a SaaS agreement. Either way, the customer gets what they need.

However, if you've spent any time in the software industry, you'll quickly discover the limitations of this model. When you design something around the needs of a single customer, it can be difficult to apply that same solution elsewhere. Scaling becomes challenging because the original design assumptions were made with one specific use case in mind. Whether that solution is suitable for other customers becomes a gamble.

This is often the point where service-led companies begin a product-led transformation.

Instead of accepting billable hours from a single customer to build a specific feature, product-led organisations invest in understanding the broader market. Product leaders conduct research, speak with multiple customers, identify common problems, and design solutions that can serve many organisations at once.

As I mentioned earlier, smaller markets and limited investment often push companies into the service-led trap. That's where I think many Australian businesses find themselves today.

Throughout my career in Australia, I've helped organisations navigate the transition from service-led businesses to product-led businesses. The process itself is actually the easy part. The difficult part is the mindset shift.

It's a fundamental DNA change that organisations must go through. Teams need to stop thinking about fulfilling requests and start thinking about solving problems. That's uncomfortable for employees, leadership, and, perhaps surprisingly, customers as well.

Customers who have spent years receiving bespoke solutions often need to adjust their expectations. Internal teams that are used to estimating work and billing hours need to learn how to validate demand, measure impact, and prioritise based on broader outcomes. While the process changes can be documented in a few slides, the behavioural changes take much longer.

The first step in moving away from a quote-to-build model and toward a product-led model is having the right process and tooling.

Let me start with a confession: I don't particularly like any product management tool I've ever used.

I've worked with Aha!, Productboard, and several others. They all seem to have the same flaw: an overwhelming focus on features. Feature requests. Feature ideas. Feature roadmaps.

This is where I think many organisations go wrong. By the time you've defined a feature, you've already narrowed your thinking. You've effectively laid down the train tracks before fully understanding where you're trying to go.

The process I use is designed to foster discovery and experimentation while keeping customers at the centre of decision-making.

Here's another confession: I've never written a PRD, and I've worked in product for over ten years.

The reason is simple. Understanding, defining, and aligning around problems is far more valuable than documenting solutions. When teams align around problems instead of predetermined features, they can collaborate to design better outcomes.

Engineering, sales, support, leadership, and product can work together to identify solutions that are architecturally stronger, strategically better aligned, able to solve multiple problems simultaneously, and lower effort to implement. Most importantly, it keeps options open.

The framework I use begins with pains and problems. The only place where a solution is mentioned is within a hypothesis section.

Unfortunately, most product management tools don't have a dedicated concept for this, so I often end up repurposing features, ideas, or insight records. Every piece of customer feedback—whether it comes from meetings, emails, support tickets, or feedback portals—is linked back to a specific pain point.

Over time, something powerful happens. You begin to see how frequently certain pain points appear across your customer base. One thing I've learned is that pain points shouldn't exist as a flat list. They should be grouped around the jobs customers are trying to accomplish throughout their lifecycle with your product. Whether it's onboarding, managing products, processing orders, reporting, or growth, organising pain points around these interactions helps you identify where friction exists in the customer journey and where investment will have the greatest impact.

This becomes incredibly valuable when it comes to prioritisation. Rather than debating individual feature requests, you're evaluating which customer jobs are creating the most friction and which improvements will create the most value across the widest audience.

Of course, customers rarely communicate their problems clearly. More often than not, they present a solution rather than the underlying issue. That's why it's important to dig deeper.

Ask questions like:

• How long have you been dealing with this problem?
• What workarounds are you currently using?
• How often does it occur?
• How much time does it cost you each week?
• Who else is impacted?

All of this information becomes incredibly valuable later. By the time you've collected enough evidence, you'll have a much clearer understanding of the problem, its impact, and whether it's worth solving.

My approach follows the Double Diamond framework. The first diamond focuses on Discover and Define, and everything I've described so far sits within that phase.

The second diamond covers Develop and Deliver. When I enter the development stage, I bring a problem to the engineering team—not a feature request. At that point, I already know the problem is worth investigating because I understand how many customers or internal users have experienced it. That doesn't automatically mean we'll build something, but it gives us confidence that the discussion is worthwhile.

Together, we explore multiple possible solutions.

One example stands out. I was once asked to deliver TOTP (Time-Based One-Time Passwords). At face value, that seemed straightforward. The customer wanted TOTP, so that's what we should build.

But when I dug deeper and spoke to the customer, I discovered their real problem wasn't authentication. Their problem was that bots were scraping their eCommerce site, collecting pricing information, and republishing it elsewhere. They requested TOTP because they thought it would stop bots.

Once we understood the actual problem, the solution became obvious. Instead of implementing TOTP, we deployed reCAPTCHA. It was significantly lower effort, solved the customer's problem directly, and avoided introducing unnecessary complexity into the platform.

That's the power of problem-led thinking. When you focus on understanding the underlying pain rather than immediately implementing the requested solution, better options often emerge.

The design phase often happens during refinement sessions, but ideally customers should also be involved. Before moving into delivery, you want confidence that the solution genuinely solves the problem, represents the lowest reasonable effort, aligns with your long-term strategy, and has support from critical stakeholders.

Only then should development begin.

The delivery phase itself could easily fill an entire blog post, so I'll leave that for another day. Instead, I want to finish with one observation about the Double Diamond framework itself.

I think the Double Diamond framework is missing something.

After Deliver, there should be another half diamond: Divulge.

Too many product teams spend months building something valuable only to quietly release it and move on. Once you've shipped a feature, get out there and tell people about it. Talk to customers. Train your sales team. Update your support team. Create marketing content. Share success stories.

Because if nobody knows you've solved the problem, you haven't really solved it at scale.

Building great software is only half the job. The other half is making sure people know it exists.