The benefits of shifting from technology-driven to product-driven development

Former chef and soldier, then turned developer. I love outdoorsmanship, and all things technology.


I am a backend developer with 20 years of development experience, starting when .net 1.0 was released. But throughout the years, I have been working full stack one way or another. Back then, there was no difference between backend, frontend, or QA engineers. You were just a developer. You were expected to know and understand HTML and various web standards like PHP or Javascript and how to test your code. With the internet boom in the mid-nineties, the web was hot and continuing to impact the tech industry. We were taught frontend and backend technologies in universities back then, all the technologies needed to prepare us for what we were expected to do as developers. Landing my first job in development, I had to dive in and write both backend and frontend for an online job application system providing automated applicant lists, ordering them based on set criteria for the employers. 

Over time, the shift between front-enders, back-enders, and QAs has siloed, and we no longer speak the same language. It is a “them vs. us” mentality. There may be many reasons for this change. It can often come down to maturing technologies and the fact that people usually want to specialize in an area they like, are comfortable in or know particularly well. I also know this differs with teams, culture, and other aspects. But the overall feeling is that time has separated us in a way where it is easy to push blame back and forth. 

What am I exploring in this blog post? 

In recent months, I have found myself in a position where we are transitioning our development from being purely siloed and very tech-oriented toward product-driven development. After spending years doing technology-driven development, I am super excited to be part of a company willing to take a step back and start focusing on the customers over technology-based decisions.

So what does it mean, and why does it excite me? Let us start with some definitions.

What is technology-driven development?

In the development world, we have many definitions of how we work as developers, product managers, designers, QAs, etc. We also have definitions for our procedures and our processes. It is a mesh of abbreviations and acronyms. So, let’s talk about technology-driven development.


At its core, technology-driven development is an approach where technology and/or tools drive the direction of a project. It is all about pushing boundaries, innovating, and building something that is technically impressive, emphasizing utilization, or even showcasing a particular technology, framework, or method. 

The focus on building general, scalable solutions

A significant advantage of technology-driven development is the broad perspective it provides. Development teams might prioritize creating a generalized solution that can be applied to various problems. The emphasis often lies on scalability, performance, and leveraging the latest technological trends. For instance, at Mews, it can be seen in how we have focused on the functional way we do backend code. It can also be seen in many decisions that have been made previously: perfection over ease of use, generic naming, and generalization. These serve a purpose, and this approach is often how startups work before they realize their scope and focus areas.

Common pitfalls of technology-driven development

While the technology-driven approach can lead to innovations and breakthroughs, it has challenges.

  • Losing touch with end users is the primary risk – developing something technically impressive but needing real-world utility. By focusing too heavily on technology, there’s potential to overlook the actual needs and problems of end-users.
  • Overengineering! It is the allure of cutting-edge technology and can lead to solutions that are way more complex than necessary. Overengineering can increase costs, lengthen development times, and make maintenance more challenging. 
  • Feature creep. Another drawback of technology-based decisions is that we build it to create it, thinking that customers will come without grounding it in actual market needs. 

To avoid the pitfalls of technology-driven development, it is crucial to have a well-balanced strategy for the development department.

Brainstorming engineers around a coffee table
Photo: Karolina Kramkova

What is product-driven development?

In contrast to the technology-driven approach, product-driven development (PDD) places the end product, specifically the user, at the forefront of the development process. Instead of being led by the capabilities of technology, PDD emphasizes creating a product that users will love, use frequently, and recommend to others.

PDD is fundamentally about solving real-world problems that users face. The primary goal isn’t just to build a product but to ensure that the product aligns perfectly with users’ needs, preferences, and behaviors. It’s about empathy, understanding, and, above all, creating tangible value.

Emphasis on user needs and desires

With PDD, every feature, every design choice, and every development decision springs from a deep understanding of the users. Not only from the product manager or customer success people but also from the perspective of the engineers.

When you focus on user-centric design, you get involved in understanding user personas, creating user journeys, and leveraging feedback to refine the system. You also incorporate feedback loops both with beta users and user interviews, and this feedback becomes the cornerstone for refinements and iterations of your product. 

Benefits of embracing product-driven development

At its best, PDD should lead to a product that resonates deeply with users and offers an intuitive user experience. Development guided by a keen understanding of user needs ensures market fit, success, and longevity. It also drives user loyalty, which sets the product apart from its competitors. User loyalty is often the best market strategy you can have as they will promote and even demand your product.

In a nutshell, product-driven development is not merely a methodology but a mindset. It challenges development teams to step into the shoes of their users, ensuring that technology serves genuine needs rather than just showcasing its prowess. In the rapidly evolving software world, where user choices abound, PDD can be the differentiator that sets successful products apart.

Cons of product-driven development

A con of product-driven development is that in its extreme, you can end up with a lot of scope creep as the users need “everything,” even though the idea is to have a quick and direct feedback loop to prevent that. The balance is hard to get right. However, the cause of this might not stem from PDD but from poor management of priorities, scopes, and other factors. Thus, this can be a problem that arises in many different development strategies. But with PDD, you might be more likely to run into scope creep issues unless you are specifically aware, and the product side is focused on priorities. 

You also find that when moving towards more product-driven development, your developers and teams have initial resistance. Especially the ones that have been heavily technology-driven. 

Lastly, there is potential for a lot of tech debt. With a product focus, you start rushing to bridge the market gap and focus heavily on immediate product needs, leading to shortcuts and unfinished features.

Do you find the blog interesting?

Would you like to be the author of the next one at Mews R&D?

Tips and tricks for a smooth transition

The most important thing a company can do when transitioning into product-driven development is to maintain and emphasize collaboration, both vertically and horizontally. 

Vertical collaboration is when you take a slice of the vertical stack in the company from the customer, user, customer success team, support team, designers, and product engineers. It is vital to ensure that collaboration and all layers are represented when designing and building the product. Horizontal collaboration in a company is typical across teams on the same level, pushing for cross-team cooperation to achieve a unified touch, look, and feel of the product. 

We also need to stay adaptable to change, as being product-focused, your scope or task may pivot quickly, and being agile will be necessary to deliver whatever brings the customer the most value.

One thing that we need to consider is still keeping a technological backbone. Going fully product-oriented does not excuse poor code. However, it pushes a good enough mindset, which can be challenging to balance. Nevertheless, this balance is necessary to reach the proper and expected outcome. 

As a company, we need to encourage our developers to take the steps to become more versatile and broaden their knowledge – to become more of a T-shaped developer rather than an I-shaped one. But we also need to be aware of the cultural differences of our teams and respect their backgrounds, thus encouraging rather than pushing the changes within the development department. 

The rise of the product engineer

When we start to talk about product-driven development, one of the critical aspects is that engineers will adapt to become more product-oriented. It does not mean we need to swap out all staff and only hire so-called full-stack engineers. The product engineer’s definition is floating. The important part is that we get better at knowing more than just the area of our expertise, knowing the product better, the domain better, the customers better, and our users better. 

The benefit of such a transition is more streamlined development, a greater understanding between departments, and a holistic view of the product. You also get a set of product engineers who can unblock themselves. Imagine a QA that can fix a minor bug, a front-ender that can add a simple API, or, as in my case, a back-ender that can make a small frontend change and provide test cases to release a feature without relying on or waiting for anyone else with a much lower risk than what we have today.

There are, of course, some challenges with this approach. Balancing the many hats you can wear in a project, for instance, doesn’t stop at backend, frontend, or QA. It also ties into product management, design, and user experience. How do we stay updated on all the tech and product trends? 

Well, that’s for us as a company to figure out. 

Engineers in a room discussing a miro board
Photo: Karolina Kramkova

Frontend-first vs. domain-driven vs. product-driven development

Frontend-first (FF) is a term you will hear when discussing the changes ahead. What does that mean? Frontend-first, also known as design-first or UI-first, is a development methodology that starts with design and user experience. It goes hand in hand with product-driven development as PDD incorporates backend and market strategies. But this is toned down in Mews terms as FF still separates front and backend. In the Mews Multi Property Tribe, we will try to remove silos and perceive the whole product development as sliced along vertical increments or iterations that get delivered together.  

Domain-driven development (DDD) focuses more on core domain logic, bridging the gap between developers and domain experts and ensuring a common (ubiquitous) language. It also helps to define a bounded context, providing internal consistency. 

Now that we understand the terms, how do they intersect?

When it comes to the intersection or interaction of these methodologies, I will sum it up with an example.

In my team, we have a design-first or a frontend-first type of development where we start with some discovery, which leads to a design before we dive into development and deliveries. 

We fail today because we need a proper end-to-end scope for our efforts and some processes that define what, how, and when we should do things when we create a new feature. Starting with one or another, like we do now, will inevitably result in one being ahead of another in day-to-day delivery and overall quality. Doing one vertical slice at a time, individually or as a team, will significantly enhance our ability to consistently and rapidly deliver what we need.

So, breaking this down in terms of PDD, DDD, and FF, it could look something like this:

  1. Begin with domain knowledge: Start the development process with a deep dive into domain knowledge, collaborating with domain experts to establish a ubiquitous language.
  2. Prototype with PDD and FF: With domain understanding in place, transition to a product-driven approach. Identify user needs and how they fit into the domain. Develop frontend prototypes to visualize and validate domain concepts and user interactions.
  3. Iterate with feedback: Gather user feedback on the prototype using the PDD mindset. Simultaneously, engage with domain experts to ensure domain accuracy.
  4. Backend development: With a frontend prototype as a guide and deep domain knowledge from DDD, develop backend logic that upholds domain principles while meeting user needs.
  5. Continuous refinement: As the product evolves, use PDD for user-centric improvements and DDD for domain-centric refinements.

While DDD, PDD, and FF have distinct priorities, they can be combined for a comprehensive and holistic software development process. The product thus created can achieve a harmonious balance between domain accuracy, user needs, and an intuitive interface.

John speaking
Photo: Karolina Kramkova

Personal reflection and conclusion

In reflecting on my experience, I recognize a significant and promising shift in the development landscape within our company. While Mews initially operated with a technology-driven ethos, the past two years have seen a notable pivot towards product-centricity. This shift, propelled by our expanding sales, CX teams, and growing customer base—particularly in the midmarket segment—dictates a heightened emphasis on product improvements over pure technological innovation within R&D.

I wholeheartedly embrace this evolution, firmly believing that the broader tech sphere should delve deeper into the domains it serves. After all, we’re not just an industry in isolation; we’re the catalysts poised to reshape other industries. I urge our developers, product experts, designers, and other stakeholders to share their perspectives and insights on this paradigm shift.

I suggest you approach this with a renewed, product-driven spirit. Cheers to a future shaped by domain-focused innovation!

Former chef and soldier, then turned developer. I love outdoorsmanship, and all things technology.