Reading time 8 min

Laurens Slechten

When building products, there is a growing recognition that success isn’t just about delivering features or hitting deadlines. Instead, it’s about delivering real value to customers and achieving business impact. This requires a shift in mindset from output-driven to outcome-driven thinking. In this post, we'll explore why prioritizing outcomes over output is essential for building successful products, and how you can adopt this approach in your own work. What does “outcomes over output” mean? In the world of business, the terms outcome and output are often used interchangeably, causing a bit of confusion. However, it is important to have a clear understanding of the distinction between these two terms . Although they may seem straightforward, let's define them to ensure we are all on the same page. Let’s imagine you’ve been feeling exhausted lately, so you start working out in the gym to feel more energized. Some people might say that the outcome of your gym routine is the hours you’ve spent working out and the amount of weight you’ve lifted. But the real outcome of your routine is much more significant than that . The outcome is that you feel stronger, more confident, and healthier. The outcome is the way in which your hard work (the output) has translated into a better quality of life and a more positive self-image. The outcome is the way in which your problem was solved by the output. In a business context, an outcome refers to the impact your product has on the organization and its customers and stakeholders, while an output refers to the tangible things your (development) team produces, like documents, software, and tests. Focusing on outcome over output means defining success based on achieving a specific outcome and measuring progress based on how close you are to reaching that outcome. The goal of your team is not to produce outputs; it’s to reach a specific outcome. A successful team strives to maximize the desired outcome while minimizing the amount of work produced. The benefits of an outcome-driven approach 1. It helps you escape from the build trap The first Agile Principle states that your top priority is to make your customers happy by delivering valuable software as early and consistently as possible. As agile practices are adopted in various fields, people have rephrased this principle to emphasize the importance of delivering value to customers quickly and consistently. When you measure success based on an outcome-driven metric, like “ increasing newsletter click-through rates by 15% within six months ”, you immediately connect your team's efforts to the value for your organization and customers. This helps you understand the impact you're making and when you're truly making a difference. In contrast, when you measure success by looking only at the things you produce, such as “ the number of features delivered ” or “ the number of completed points in a scrum sprint ”, you risk running into what Melissa Perri (product management expert, speaker and author) refers to as “the build trap”. This trap involves focusing solely on creating features without considering the desired outcomes. When organizations prioritize output over outcomes, they risk getting caught in a cycle of building more and more features without truly understanding if they are solving customer problems or driving business value. By fixating on feature delivery as a measure of success, you may lose sight of the bigger picture. It doesn't tell you if you're building the right things. So, it is essential to shift your focus to the outcomes that matter. This requires a mindset shift that places the customer's needs and desired results at the forefront. By defining success based on outcomes, your team can escape from the build trap . 2. It helps you focus on learning and iterating When you start thinking critically about value delivery instead of feature delivery, you quickly run into the problem I’ve addressed previously: how can you be sure that the features you’re building are actually going to deliver value? An outcome-driven approach recognizes that you may not have all the answers from the start and that learning is an important part of the process. This is why, when working with outcomes, you need a companion tool: the experiment. When you combine outcome-driven thinking with a process that’s based on running experiments, you really start to unlock the true potential of agile approaches. This is especially valuable in situations where there is a lot of uncertainty. For example, when creating a new software product, you may not be sure if it will have the desired impact on your business or if all the fancy features you came up with are necessary. By focusing on outcomes, you can set goals that allow your team to experiment and try different solutions until they find what works best. In an agile context, we treat each step as a hypothesis and an experiment aimed at achieving a specific outcome. This is where the concept of an MVP, or Minimum Viable Product , comes in. Think of MVP as the smallest thing you can do or the smallest thing you can build to learn if your hypothesis is correct. This iterative process of testing, learning, and adapting allows teams to experiment, to try different solutions, until they hit on the one that works. 3. It helps your team reach more autonomy Employees often find it challenging to feel a profound sense of purpose and motivation solely from the output they produce. What truly drives individuals to show up at work each day is not the specific tasks they engage in day by day, but rather the meaningful outcomes their work will ultimately contribute to . An emphasis on outcomes helps align your team around a common purpose and shared goals. By providing clarity on what needs to be achieved, you can motivate and empower your team to work together towards clear goals that the product should achieve. This allows your team to prioritize their work, and build features that contribute to achieving those goals. Allowing them to make decisions about the features they build, will give a greater sense of ownership over the work they do. Defining the outcomes for your product and implementing them By now, you might agree that focusing on outcomes sounds like a good idea, but actually implementing them in our business practices is not as straightforward . Every methodology has its drawbacks. One challenge is that outcomes are less easily measured and quantified compared to outputs. Secondly, many companies face pressure to quickly move on to the next project once one is completed . Unfortunately, the iterative process of testing, learning, and adapting is still not commonly practiced. Finally, one thing that makes it hard is that we often set goals that are too high-level . For example, when you ask the team to make the business more profitable or reduce risk, it is too complex because those challenges consist of many variables to influence. These impact-level targets are too complex for teams. Instead, you should focus on smaller and more manageable targets . To do this, you need to ask your team to concentrate on changing customer behavior in ways that drive positive business outcomes. In his book “Outcomes Over Output: Why Customer Behavior Is The Key Metric For Business Success”, Joshua Seiden presents three magic questions that can help you identify suitable outcomes: What are the user and customer behaviors that drive business results? (This is the outcome that you’re trying to create.) How can we get people to do more of those behaviors? (These are the features, policy changes, etc that you’ll do to try to create the outcomes.) How do we know that we’re right? (This uncovers the experiments and metrics you’ll use to measure progress.) Let me provide you with an example of how this works. Imagine that you run an e-commerce clothing store, and you’re facing tough competition from a rival company. Your objective is to improve customer loyalty, so you set a broad goal to the team of increasing the frequency of customer visits from once a month to twice a month. To achieve this impact, you need to identify specific customer behaviors that correlate with visiting your site. For instance, you observe that customers tend to visit the site after opening the monthly newsletter showcasing new items. Therefore, one possible outcome could be to increase the newsletter click-through rates. Additionally, you notice that customers also visit the site after a friend shares an image of one of the items on social media. Hence, another outcome to consider is encouraging customers to share images of items more frequently. By focusing on these customer behaviors that drive the desired outcome of site visits, you ensure that your goals are both observable and measurable. This is crucial as it allows you to effectively manage and track progress. I hope this example highlights how outcomes can be specific and easily broken down. Remember, an outcome is a behavior exhibited by customers that directly influences business results. By understanding these behaviors, you can align your efforts with the outcomes that truly matter to your business. Takeaways An outcome refers to the impact your product has on the organization and its customers and stakeholders, while an output refers to the tangible things your team produces, like documents, software, and tests. The goal of your team is not to produce outputs; it’s to reach a specific outcome. A successful team strives to maximize the desired outcome while minimizing the amount of work produced. By fixating on feature delivery as a measure of success, you may lose sight of the bigger picture. It doesn't tell you if you're building the right things. So, it is essential to shift your focus to the outcomes. An outcome-driven approach recognizes that you may not have all the answers from the start and that learning is an important part of the process. This is why, when working with outcomes, you need a companion tool: the experiment. When you’re planning work, be clear about your assumptions. Be prepared to test your assumptions by expressing work as hypotheses. Test your hypotheses continuously by working in small iterations, experimenting, and responding to the data and feedback you collect. Don’t mistake impact—high-level aspirational goals—for outcomes. Impact is important, but these targets are too complex for teams as they consist of many variables to influence. Use these questions to define outcomes: what are the human behaviors that drive business results? How can we get people to do more of these things? How will we know we’re right? 👀 Want to know more about our services ? Click here to find out!

Reading time 6 min

Christophe Senesael

Mobile development today vastly outpaces that of a decade ago in complexity and functionality. What once began as simple projects with a few features have now evolved into sophisticated systems incorporating everything from biometric authentication and AI to advanced camera integrations. This growth necessitates an architectural strategy that effectively manages complexity while maintaining high-quality codebases. In this article, we'll explore a robust architectural solution to this challenge: a modular or composable architecture in mobile development, inspired by the microservice architecture prevalent in backend development. What is a Modular Architecture? Similar to microservices, we decompose a large application into small focused mobile libraries, each addressing a specific domain or functionality. This modular architecture allows for constructing multiple applications using these reusable components, ensuring that each module remains loosely coupled. This maximizes flexibility, testability, and adaptability for each component. Let’s delve deeper into the benefits of a modular architecture in mobile development. Why Use a Modular Architecture in Mobile Development? Enforce Separation of Concern with a Modular Architecture Adopting a modular architecture in mobile development establishes a clear separation of concerns. This extends beyond the underlying code to the project's organizational structure. Each module functions as a self-contained unit, representing a distinct responsibility domain, developed and maintained separately. This not only enhances project readability and manageability but also streamlines collaboration and debugging. Consequently, the modular architecture design philosophy creates a cohesive system where component boundaries are immediately apparent, even without delving into the codebase. Modular Architecture Promotes Code Reusability and Maintainability A modular architecture clarifies project structure and significantly promotes code reusability and maintainability. By compartmentalizing the app into modules, we create reusable components that can be integrated across different parts of the application or even in entirely new projects. This reuse of code minimizes redundant work, enabling developers to focus on innovation rather than reinventing the wheel for each new feature. Moreover, a modular architecture simplifies the maintenance and updating of apps. Modules operate independently, allowing enhancements or fixes to be applied to one module without inadvertently disrupting others. This separation simplifies testing, enabling targeted validation of changes, which ensures a more stable and reliable application. As a result, the modular approach provides a codebase that is not only sturdier but also more flexible, allowing the app to adapt swiftly to new requirements or technological advancements. Modular Architecture Enhances Testability One of the greatest advantages of adopting a modular architecture in large mobile development projects is improved testability. In large monolithic mobile projects, build times can be significant, often resulting in inefficient workflows. For instance, imagine you’re working on a large Xamarin application without hot reload capability. Any UI misbehavior would require building the entire application and going through the entire flow. And if this flow is dependent on web calls maintained by a client team, you know you are facing an incredibly time-consuming and inefficient process. Advantages of Modular Architecture in Mobile Testing Using a modular architecture for your mobile development projects provides a series of important advantages in terms of testing: Isolated Testing With a modular architecture, you can mock all data dependencies of a module and test it as a standalone app. This isolation allows focused testing on specific functionalities without the overhead of running the entire application. Reduced Build Times Building the entire application for every change is unnecessary, significantly reducing end-to-end testing times. This efficiency leads to faster development cycles and quicker iteration, crucial for maintaining high productivity. Stable Testing Environment Decoupling modules minimizes the risk of one component affecting another, ensuring more reliable tests and easier bug tracing. Parallel Development and Testing Teams can develop and test different modules concurrently without waiting for a shared codebase to stabilize, accelerating the development process and enabling dynamic, flexible workflows. A modular architecture results in a more efficient, reliable, and scalable mobile development process, mitigating risks associated with monolithic architectures. By focusing on modularity, we enhance both the development and testing phases, leading to better overall software quality. Defining Modules in Mobile Development When developing application modules, collaboration with domain experts is crucial to fully grasp the various functions within an organization. This partnership enables a clear understanding of how to segment the application logically. Documentation of roles, coupled with domain-specific requirements, should be solved as an iterative process, allowing ongoing refinements that align with evolving organizational needs, ensuring each module is sharply defined and purpose-driven. The Base Module In our modular architecture, we employ a foundational base module. Think of this as the genetic code of the application — the core from which every other module inherits. This base module contains all shared, domain-agnostic features, including universal design elements and controls. Centralizing these common aspects establishes a consistent look and feel throughout the app. Each specialized module, built upon this base, inherently adopts these shared traits, streamlining development and ensuring that changes to fundamental aspects need only be made once, cascading throughout the entire application. Creating Our First Module Once the base module is in place, the next step is creating the first composable module. The structure mimics the classic layered architecture (Data, Domain, and Presentation projects), with an additional Test project to facilitate module testing. This Test project directly calls the module. It's a straightforward mobile application, typically consisting of a button to boot the component. Its role is to provide mock definitions for all the required dependencies of the module, allowing it to be deployed on a device or emulator for testing. Project Structure for Modular Architecture Data Project: Defines data entities and required data interfaces. Domain Project: Contains core business logic and domain models. Defines use cases and business rules operating on the data. Presentation Project: Manages UI components and presentation logic. Includes views and UI-related utilities. Test Project: Standalone project interacting directly with the module. Provides mock implementations for dependencies. Facilitates isolated testing of the module's functionality. Defining Data Dependencies in Modular Architecture For every composable library, defining data dependencies through contracts (e.g., interfaces) rather than hard-coding data sources is crucial. This ensures the library remains agnostic about data origins, whether from a local database or a web API. Dependency injection supplies the appropriate data implementations to the module. This approach allows consumers to decide the data source. By ensuring the composable library is only concerned with the type of data it requires, rather than the origin of the data simplifies the mocking of data contracts and the emulation of expected functional scenarios. This modular and testable approach significantly enhances codebase flexibility and maintainability. Consuming a Module or Component in Mobile Development Integrating a developed module into your application is straightforward due to clearly defined interfaces and dependencies: Import the Module: Include the module in your project. This often involves adding a dependency to your project’s build configuration. Inject Dependencies: Use dependency injection to provide necessary data sources and services required by the module. This keeps the component agnostic about the origins of its data, promoting flexibility and reusability. Initialize the Module: Set up any initial configurations or states needed for the module, such as initial data or specific settings. Use the Module’s API: Interact with the module through its public API, typically including methods to start flows that return data or integrate views with your application. Conclusion: the Future of Mobile Development Lies in Modular Architecture Embracing modular architecture in mobile development offers numerous benefits, enhancing both the development process and the final product. By decomposing applications into smaller, manageable components, we enforce separation of concerns, promote code reusability, and significantly improve maintainability. Modules enable isolated testing, reduce build times, and create a stable testing environment, ultimately leading to a more efficient and reliable development workflow.

Reading time 5 min

Kamen Zhekov

Today’s web applications and websites must be available 24/7 from anywhere in the world and have to be usable and pleasant to use from any device or screen size. In addition, they need to be secure, flexible and scalable to meet spikes in demand. In this blog, we introduce you to the modern web application’s architecture and we brush a bit on different back-end and front-end frameworks and how they work together. When people compare solutions used for building web applications and websites, there usually is a sort of pitting one against the other. Here, we will go against this flow and try to frame the differences, so that you can decide whether one, the other, or both fit the use case you have in mind. An essential concept that must be noted is that back-end frameworks, such as Flask or FastAPI , and front-end frameworks, such as React or Vue JS , are two fundamentally different technologies that solve different, although related, problems. Setting them against one another is therefore not a good approach. These days, when you are looking to build a slightly more complex web application or website solution, you often need solid frameworks that address bits of both front-end and back-end sides to achieve what you’re looking for. The specifics of your application will determine what those bits are and whether it’s worth investing in using only one of the two technologies, or both in tandem. Purpose of a back-end framework A back-end framework is the “brains” of your web application. It should take care of most, if not all, computation, data management and model manipulation tasks. Let’s take the example of FastAPI. While this back-end web framework is primarily used for developing RESTful APIs, it can also be applied for developing complete web applications if coupled with a front-end engine such as Jinja2. Using only FastAPI and some templating would be ideal if you want a standalone API for other developers to interact with. Another good purpose would be a website or web app that offers dashboards and insights on data inputs (charts based on files that you upload, etc.) without functionalities that depend on quick user interactions. Below you find an example of an application built entirely with a Python back end and Jinja2 as a templating engine. Click here to get some more information about the project, source code, etc. The issue you might find when creating a complete web app or website with FastAPI is that the entire logic of the program is pushed to the back-end, and the only job for the browser and the device on the client’s side is to render the HTML/CSS/JS response sent to it. The time between when the request from the browser is made for displaying something and when the user sees it, could then vary wildly based on a lot of factors. Think of server load, the speed of the user’s internet, the server’s memory usage or CPU efficiency, the complexity of the requested task, ... Purpose of a front-end framework So far, the back-end can take care of all the operations that we might want our web app to have, but there is no way for it to really interact with the user. A front-end framework takes care of the user experience - UI elements like buttons, a landing page, an interactive tutorial, uploading a file - basically any interaction with the user will go through the front-end framework. Taking a look at React or Vue JS — these are front-end frameworks for developing dynamic websites and single page applications. However, they need some back-end technology (like FastAPI, Flask or NodeJS) to provide a RESTful API so that what they show can be dynamic and interactive. Using only React would happen in situations where there are already existing data sources that you can interact with (public APIs, external data providers, cloud services, etc.) and all you want to create is the user interaction with those services. But we can already see here that, in theory, combining the strengths of a solid back-end framework – such as Flask, FastAPI, or NodeJS – with a good front-end framework is an option, and a very good one on top of that. Examples of that combination are the BBC World Service News websites rendered using a React-based Single Page Application with a NodeJS back-end (Express). Click here for a detailed breakdown of the project’s GitHub page. In these cases, front-end frameworks attempt to delegate some (or a lot) of the tasks of the back end to the client-side. Only the computationally heavy parts remain on the server, while everything that is left and fast to execute is done in the browser on the client’s device. This ensures a good user experience, “snappiness” and is basically a sort of decentralization of parts of the web application’s execution, lowering the load and responsibilities of the server. Combining the two 🤝 Today, the architecture of well-built and scalable web applications consists of a client-side framework that maintains a state, comprising a state of the user interface and a state of the data model. Those states represent respectively UI elements that form the visual backbone of an application, and data elements linked to what kind of data or models (for example a user) are used throughout the application. Any change in the data model state triggers a change in the UI state of the application. Changes in the data models are caused by either an event coming directly from the user (like a mouse click) or a server-side event (like the server saying there is a new notification for the user). Combining all these factors makes for a great user experience that gets closer to a desktop application rather than an old-school, sluggish website. Ready for more? In our next blog , we explain the strengths of Python and NodeJS, and how you should choose between them.