From User to Product – Balancing Value Creation for the Application User

The Product Owner in a Scrum team (in addition to the obvious responsibility for the overall product) is primarily interested in maximizing the value for the user during their use of the developed applications. This role is, in our view, absolutely paramount, because without delivering value to the customer, we will not have a product that enjoys a good reputation and is eagerly used. This is, after all, a universal truth that applies to all types of products or services, not just those built in the IT world.

The biggest challenge is, therefore, finding the functionalities of the application that will make the customer want to choose our solution rather than a competitor's, or stick to their old ways and habits... (for example, in business settings, this is most often email communication or filling out paper versions of documents). Thus, every time a new product idea arises, the question that constantly echoes in our minds is: how can we maximize the value of the built application while keeping costs in check, especially in terms of building potentially unnecessary functionalities?

The software development methodology in agile frameworks provides us with many tools to help answer the above question. Today, we will focus on the key stage of creating the first version of the product. We begin by determining who the future user will be, what their conscious and—more importantly—unconscious needs and problems are in performing the tasks for which the application is intended, and then we validate through a prototype how potential users perceive our proposal.

All of this seems obvious and easy to execute, but unfortunately, reality presents us with many fundamental challenges in implementing such an approach. We operate in a rather specific area of business clients, namely banks and other non-banking financial institutions, so it is not easy to conduct large-scale, multi-stage user research. The biggest challenges we face in the project are:

• A small client base in our field – financial institutions for which we build applications;
  
• The lack of a homogeneous target audience for the tool – the user could be any employee of the client company. Different institutions, depending on their type and size, have their own rules and procedures, as well as different structures, making it difficult to define a "persona," its needs, or typical behaviors;
• Decreasing willingness on the part of the client to test different solutions, answer surveys, or participate in co-creating the product (we cannot use any "incentives" due to regulations);
• The opacity of solutions available in the market, making it difficult to verify how competitors are solving the problem we want to automate, or the complete absence of similar solutions.

For this reason, we rely on the help of our colleagues from Vienna, who work in various teams, including sales, sales support, and customer service, as well as those verifying customer experience, where all customer feedback regarding product and service quality should be directed. At the same time, the last mentioned Customer Experience team is responsible for coordinating research with customers to ensure that their rather limited base is not constantly "bombarded" with surveys and research invitations.

Let’s return to the methods used to properly select the scope of the MVP (Minimum Viable Product) – the first version of the product, which will address the most important needs of future users and contain only key functionalities.

We begin by creating a concept for the entire product/large functionality, which typically arises through collaboration between part of the Scrum team: the product owner, business analysts, and UX designers with internal stakeholders. At this stage, many discussions and more or less structured expert interviews take place. Sometimes we use workshop methods to better understand the current business process and the issues that arise in it, both from the clients' side and the internal users’ side.

At the same time, the first sketches – wireframes – are created, which give a high-level illustration of the potential functions of the application/features. At this stage, we do not focus yet on the graphic layer and exact representation of the real interface elements. What matters here are primarily the functionalities and user flow – showing what the user will be able to do step by step. We do not limit ourselves in ideas, striving to capture all possible proposals, both those we already feel will be “must-haves” and those that are “nice to have.”

The second artifact created at this stage is the user story map. User story mapping helps in naming and grouping functionalities and is used by us for high-level estimates with the development team. Thanks to this, we can estimate the time and cost needed to implement various elements of the new application at the outset. In later stages of the project, the user story maps continue to “live” and are useful for the team even during development, as they make it easier to break them down into individual user stories and tasks, which can serve as concrete material for the development team to work on before deciding to implement them.

The third artifact, which we validate with users, is the “clickable” prototype. These are created after the main sponsors of the new functionality approve the estimated time and cost for software creation. At this stage, the team’s experience in high-level estimation plays a significant role, especially for new functionalities (never built by the team before). These prototypes are created based on the previously prepared wireframes but contain much more detail and better replicate the potential look of the application. They also allow us to simulate real user interactions with the product.

Since, due to the previously mentioned limitations, we are not often able to conduct "textbook" user research at various stages of the design process, interviews with customers typically consist of two parts:

• An exploratory part, where we try to understand how the current process works, what habits the client has in this regard, what bothers them, and what problems they encounter.
  
• Prototype testing, during which we observe how the client reacts to our product proposal, how they use it, whether everything is clear to them, whether they find and use the features we proposed, what they think about them, what questions they have, and if they feel anything is missing.

Since we cannot determine the importance of each functionality or know how a user typically behaves when using the application, user research is an extremely valuable tool that helps prioritize built features and significantly reduces the costs of creating the actual product. Gathering early feedback from customers allows us to verify whether our product concept is correct and whether we missed any important aspects that we were unaware of earlier.

Of course, the final scope of the first version of the application will not always result directly from prototype verification. For us, the development of technology and functionalities also plays a huge role, through which certain features of the application begin to be considered a norm. For example, consider the functionality of automatically saving data when filling out extensive forms or the ability for several logged-in users to work on the same form simultaneously. In the current world and in the applications we build, these are expected as a minimum, whereas just a few years ago, they might have been considered "nice to have" or evoke a "wow" effect.

In conclusion, selecting the functionalities of the product that will ultimately be built as its first version is incredibly important. With a good MVP, we can deliver a product to users that meets only the most essential expectations and does not turn them off “right away”; at the same time, we give ourselves the opportunity to continue observing how the product is used and gather feedback. Based on this, we can assess which additional functionalities should be built to ensure our application provides the highest value for the user and expands the base of satisfied customers.