Innovation through Customer Proximity: Solar-Log WEB Enerest™ 4

by Vivian Bullinger | 03.02.2021

How do I develop a product further? How do I break away from entrenched processes? How do I enable more creativity in product development while always keeping the user of the product in mind? These were the questions the Solar-Log team addressed last year. The relaunch of the Solar-Log WEB Enerest™ was on the agenda. With the relaunch, the existing product was to meet the complex requirements of a powerful PV monitoring system even better. The challenge was to critically question established solutions and implement new ideas. All this with a focus on the requirements of the different target groups!

Classic way of product development. Disadvantage very lengthy and not sufficiently customer-oriented.

The 1st Realization: Standard Ways do not necessarily Lead to the Goal.

It quickly became clear that the established processes do not necessarily lead to the desired goal. The standard procedure, from requirements gathering to specifications to development, takes too long for a dynamic software product and does not sufficiently involve the customer. In the worst case, the development would already be outdated by the time it reached market maturity and would not meet the customer's needs 100%.

Customer-Oriented Product Development with the Solar-Log WEB Enerest™ 4

Once it was clear that the standard route was out of the question, the first key question for the Solar-Log team was: do our ideas of the new product match those of the customer?

1. Clearly Define the Requirements for the Product

When it comes to requirements and especially their implementation, there are often differences between the product management's ideas and the customer's actual needs. The following example illustrates this problem:

I would like to drive from A to B:

  • Fast
  • Steerable
  • Black color
  • Fresh air
  • With wheels

The elaborated requirements do not give a clear picture of the final product. Almost everyone will have a different picture in mind when reading the requirements. For example, one possible solution is:

It makes sense to deliver a functional product already in the first development step and to develop this further with the customer.

The defined requirements are the basis of every product, which is why special attention must be paid to this area. In addition, with the new Solar-Log WEB Enerest™ 4, the customer groups are included in the definition of the requirements. 2.

2. Implementing the Requirements in a Solution-Oriented Manner

The product is therefore built on the basis of the previously defined requirements. The aim here is to be as close as possible to the customer's needs. The customer should already be given a product after the first development steps, with which he can work and test it. This means not starting with a wheel, as in the following example, but with a vehicle that can be driven. This functional basis is then used as a basis for further development. This has the advantage that the customer immediately has an operational product in front of him, which can then be further optimized or adapted to his requirements.

Schematic of an "Agile product development" in which customers are actively involved.

The Path to the new Solar-Log WEB Enerest™ 4

Once the path had been defined, the next step was implementation and the question of how to involve the customer most effectively in the development process.

Before the actual start of development, the precise analysis of customer requirements was on the agenda. This requires more than a simple customer survey. In agile product development, the customer is involved at various points. The following diagram shows the various steps that build on each other and which the development team of Solar-Log WEB Enerest™ 4 followed.

With this procedure, product development does not lose sight of the customer's needs. The customer receives each solution step in the form of a prototype for testing.

Different perspectives of customers and the development team can only be brought to a common denominator together.

1. Identifying Needs: Learning to Understand the Customer

First, a lot of time was spent on collecting and jointly analyzing the customer's requirements. Then the resulting requirements catalog had to be critically scrutinized jointly, i.e. by the development team and the customer. During this process, not only did a clear picture of the requirements portfolio develop, but a mutual understanding of the sometimes differing views or positions also emerged.

Personas reflect the customer groups and must be clearly defined. These were worked out in several workshops with the customers

2. Not all Customers are the Same: Defining Target Groups

In the next step, the team defined individual customers who represent a customer group, so-called personas. The Solar-Log sales team and selected customers developed these personas in various workshops. The group and the individual personas reflected a colorful mix of customers. Since Solar-Log products cover a very broad target group, it was also important that each target group was reflected in the personas. For example, PV systems and their operators as well as installers from small rooftop systems to 2 MW industrial plants had to be included.

The old and complex ticket system was transformed into a to-do list that required less programming and met the requirements of the target group.

3. Align Customer Requirements with the Product

This was followed by the requirements portfolio, and was developed by the Solar-Log team from the customer's requirements for the new software.

These requirements turned out to be:

  • Find errors quickly.
  • Track errors.
  • Flexible system for analyses.
  • Flexible system for displays.
  • Categorizable plant groups.
  • Offer interfaces to other systems.
  • Suitable for mobile devices.

The example of the ticket system showed how far apart the customer and the manufacturer can sometimes be. For the Solar-Log team it was clear that the tried and tested ticket system also belonged in the new product. In the customer discussions, however, it turned out that the larger customers were already working with a separate ticket system and would not switch. For the smaller installers, on the other hand, a simple to-do list is sufficient. With this realization, it was clear that the ticket system in its old form was no longer needed.

The new navigation should help to find information faster. With the use of Post-it notes, various variants were played through in order to work out the best one.

4. Involving the Customer in the Active Development Process

With the requirements catalog and the defined functions which the new software should fulfill in hand, details were discussed. Accordingly, the following question was asked: how does the customer envision the navigation and which elements are important to him?

Good navigation often determines how good the product is in daily use. One more reason to involve the customer in the design of the navigation. In further workshops, the customers were confronted with what actually lies behind the structure of a "simple" navigation. With the help of Post-it notes, the various solutions were discussed together. Each variant and combination had more or less advantages and disadvantages. The task was to work out the best possible structure. After an intensive collaboration, the "ideal" navigation for the customer was created.

Solar-Log WEB Enerest™ 4

The Solar-Log WEB Enerest™ 4 on the Test Bench

After the theoretical setup, it was time to implement the jointly developed solutions. A demo portal was created, which is accessible to all customers. This simultaneously created a very large independent test group for the new software. Everyone who registered for the new demo portal was able to pass on their feedback directly to Solar-Log.

This continued the development process. The feedback received was evaluated and incorporated into further fine-tuning where necessary.

You can find the new Solar-Log WEB Enerest™ 4 here.

We continue to look forward to your constructive criticism.

Back to the overview