Designing B2E Software: Discovery Phase

General Considerations

The discovery phase is one of the phases of the software development lifecycle. It begins first and aims to understand project requirements and objectives clearly. So, what is the difference between B2C, B2B, and especially B2E approaches to the discovery phase?

Let us start with several important notes that we’ll be relying on:

• As the customers of a B2E product are the employees of one organization, it is easier to get access to the end users and closely research their working routines, pain points, and desires.
• There is no direct competition between B2E products, as it is in the organization’s interest to keep a “monopoly” of products, thus increasing complexity and costs.
• Revenue is not a part of a B2E product, while the organization plays a significant role as one of the beneficiaries of the well-performing application.

Objectives of the Discovery Phase

Let us start with the straightforward list of objectives product managers should achieve during a Discovery Phase.

1. Identify User Needs: It is paramount to understand what employees need from the software. This objective involves gathering insights into their pain points, preferences, and expectations.
2. Define Business Goals: Aligning the software's functionalities with the organization's strategic goals ensures that the project delivers tangible business value.
3. Assess Technical Feasibility: Evaluating the technical requirements and constraints helps in planning the project realistically.
4. Estimate Resources and Timeline: Providing a clear picture of the needed resources, including time, budget, and personnel, helps set realistic expectations.

To achieve those objectives, product teams take the following key steps.

User Research

Conducting user research is essential to gather detailed insights into employee workflows and behaviors. Product teams need to involve multiple stakeholders, which are internal employees, department leaders, and internal IT teams, in the process of understanding the employees’ needs, pain points, and workflows. The main difference here is the fact that legal and compliance requirements should be included as soon as possible. The common mistake is to involve a person from the legal and compliance side in a later stage after the software is designed or built. Unlike in B2B or B2C space, requirements on data warehousing, information access, and sharing may have a direct impact on the result of a discovery phase.

Conducting user research is essential to gathering detailed insights into employee workflows and behaviors. Methods such as surveys, focus groups, and observational studies can be employed to collect qualitative and quantitative data. This research helps create user personas, which represent different segments of the employee base and their specific needs.

In this phase, workshops seemed to be the most efficient way to get a solid understanding of users’ behavior. In B2B, the team involves external stakeholders, mostly executives and department heads, in such workshops. However, in the B2E context, it makes more sense (and is much easier) to involve a significant number of end-users. This approach shifts the focus of a workshop from vague business objectives and operational needs to improving the internal employee experience and aligning with organizational goals. It may look counter-intuitive, but the ultimate goal of a workshop is to come up with a solid vision of a solution, and not with a variety of options and opportunities. So, an employee-centered approach yields better, long-lasting, tangible results compared to a generic workshop suitable for B2B and B2C segments.

Additionally, the list of users is narrower, so each user's feedback is more significant. Sometimes, you may gather all the users of a module in a room, so there is no need to think about hypothetical users and pay attention to actual employees, their thoughts, and opinions.

Competitive Analysis

One reason the B2E segment exists and companies decide to design and build their own software applications is that no such product suits the existing needs. So, there are no direct competitors (or they are inaccessible from the outside), and there is no easy way to draw inspiration or analyze what others have done. However, the team should focus on the other tools and approaches that face the same challenges but in different industries. And, of course, thinking outside the box (even if it sounds like a cliche) is crucial in such analysis.

For instance, if the team is willing to build an external-caused risk analysis tool in the financial vertical, product managers and designers could draw inspiration from weather forecasting and analysis tools. Even though the verticals are not even close, the challenge is somewhat similar. There are some factors that the team doesn't control over (inflation rate or fed-funds rate change in a financial world and sun activity in a weather forecasting world), but the team needs to build hypotheses and plan in both worlds.

Also, in the B2E world, it looks like there is no competition among platforms, as the organization is designed that way, so the internal toolset is homogeneous. This argument is not true if we look at employees’ activity, especially what employees do if the tool that the company provided is not adopted. Well, they use something they used to use previously. In most cases, it would be Excel for all data-related processes, email for all feedback-related activities, and PowerPoint to store the knowledge about the organization. Those are the real competitors of most B2E systems, as employees would.

Excel is so flexible that we've seen that employees were using it to store, share, and rotate passwords (highly insecure!), design user interfaces, and even play games!

Requirements Definition

Based on the insights gathered, a comprehensive list of requirements is drafted. This list includes functional requirements (specific features and functionalities) and non-functional requirements (performance, security, usability). Prioritizing these requirements is crucial for effective project planning and scope management.

The definition of requirements may involve methods such as creating user personas, defining user stories, and mapping journeys to ensure the software enhances employees' daily work lives.

Teams should be aware that in the process of translating the needs into requirements, stakeholders lean towards overcomplication and overestimation of future needs. In the B2B segment, the more features a product has, the easier it is sold and the wider audience it suits, so B2B solutions prioritize functionality, scalability, and return on investment. User experience (UX) is essential indeed, but it works as a good addition. However, it does not work the same way in the B2E segment. User experience is paramount in B2E. The software must be engaging, easy to use, and designed to fit seamlessly into the employees’ daily routines. A positive user experience can significantly boost employee satisfaction and productivity.

Another cornerstone is the way how unique needs are translated into requirements. For a B2B software solution, those requirements are mostly achieved by introducing a robust customization system that enables employees to tailor their interface and features to suit their individual preferences and work styles without the need for complex adjustments. While it is also important for a B2E system, it is advised to focus on a personalization system when such adjustments are made seamlessly based on a better understanding of user groups.

The importance of documentation is lesser in comparison to the B2B approach, which has a rigorous and formal process involving detailed documentation, specifications, and, often, a request for proposal (RFP). Documenting requirements is still crucial, but the documentation should not serve as a formal agreement or some kind of “protection.” Instead, it serves as an “alignment manifesto” and declaration of a future state.

Prototyping and Feedback

Creating low-fidelity prototypes or mockups allows for early visualization of the software. These prototypes can be shared with stakeholders and end-users to gather feedback. Iterative refinement based on this feedback ensures that the design aligns with user expectations.

We describe methods, tips, and nuances in the following article solely dedicated to the Design Phase.

In most cases, the prototyping step is the most valuable, as stakeholders find it easier to react and respond to something visual like a wireframe or a prototype than a written user story or a diagram. Product managers and designers could verify hypotheses on a daily basis and get a solid understanding within two weeks of the discovery phase.

Technical Assessment

In collaboration with the IT team, a technical assessment is conducted to evaluate the feasibility of the proposed solution. This process includes reviewing existing infrastructure, identifying potential integrations, and assessing any technical risks. Unlike in B2B or B2C realms, the team could precisely define the necessary list of integrations and all integration details. However, this step looks similar to the assessment of any other type of project.

Project Planning

The final step of the discovery phase is detailed project planning. This step includes defining the project scope, creating a timeline, estimating costs, and identifying the team members who will be involved in the development. A clear project plan sets the stage for a smooth transition into the design and development phases. This step is the same, regardless of whether this is a B2B project or a B2B one.

Summary

The discovery phase is crucial in the successful development of B2E software. It lays the groundwork for a product that truly meets users' needs and aligns with the organization's strategic goals.

The main takeaways from the B2E approach of the discovery phase are:

• The discovery process for B2E applications is somewhat similar, but several essential nuances exist and should be considered.
• User research should be conducted more precisely, as there is better access to future users.
• User experience plays a significant role in designing B2E systems, while scalability and documentation play secondary roles.
• Standard methods of competitor analysis may not work in B2E, so a different approach should be taken.
• Prototyping and quick turnarounds yield reliable, tangible results compared to other methods of requirements gathering.