Giving smart products the right idea

Why defining product principles is crucial for designing smart products. And how to get it right from the get-go.

Smart digital products are everywhere. The routing service in your GPS, Siri on your iPhone, and the recommendation services identifying relevant content for you on Netflix, all deliver seamless and intuitive solutions to complex problems every day. Fellow programmers and digital innovators know that at the backend of these amazing solutions is a myriad of tech wizardries like machine learning, mathematical optimisation, and endless lines of code. That’s what makes designing digital solutions so exciting – to use technology and programming to deliver solutions that are almost human in nature.

At Maersk, we develop smart products that address logistical problems on a daily basis from network design and inland delivery planning to pricing and vessel load planning. However, designing smart products comes with its challenges. A recent experience during product development for the inland transportation planning engine at Maersk illustrated some of these challenges and offered valuable lessons on defining product principles when developing smart solution products.

Lost in translation – The developer and user dichotomy

It’s important to understand that the logic that runs a smart product works very differently from how a smart product user solves a problem. Take a simple container routing solution. Developers can program a product to consider all possible potential routing solutions and execute the selected ones based on set parameters like cost efficiency. But a user who manually solves a problem relies on a rule of thumb, wherein they consider more flexible parameters like cargo and order type before assigning a job.

What makes it even harder for a smart product user is the challenge to adjust and improve a product when only developers can fully understand why it makes particular decisions in edge case scenarios. This could be as simple as the product not behaving as expected or making surprising suggestions without qualifying them. In the long run, the result is the same the user’s trust is undermined, which risks the success of the product.

Developing articulated product principles to guide smart product development is a good tool to address challenges and ensure the product is in line with user expectations.

So, what is a product principle?

Product principles are guidelines for the development team that define what to focus on and the kind of ‘experience’ a product needs to deliver. Essentially, they define the values of a product – how the product should behave and prioritise, much in the same way company values describe how a company wants to operate.

For example Etsy, the craftmanship marketplace has as a core principle: to side with sellers over buyers in case of a dispute. This allows the developer teams to guide their solution designs while providing a unified experience across the platform.

Lessons learned from developing our inland transportation engine

Lesson 1: Make a strong effort to define your product principles upfront

Smart products solve problems differently from how a human would, so getting the principles aligned is key to making the product exhibit the right behaviour. This helps the product team to create a solution that behaves as users expect which also increases the likelihood of user adoption.

Teasing out the right product principles can be challenging because users find it difficult to articulate all their needs and expectations. Typically, the more complex the situation being addressed with the product, the harder it is to get the principles right through just conversations and observations. This is bad news for smart products, and sometimes nothing teases out missing principles better than a product launch. However, correcting misaligned principles in-flight can pose a significant challenge for smart products because it can simply be scientifically impossible to reconcile all principles.

For the team involved in building our planning engine, two principles had been agreed upon with users and senior business leaders, and which had deeply shaped the technical solution design for the product:

• Deliver the product as sold
• Minimize the overall cost of transportation

At this time, there was a third principle we were considering known as business shares a logistics industry response to supply chain disruption, wherein shippers such as Maersk agree to give a certain percentage of cargo space to a specific vendor, while the vendor agrees to prioritise their jobs under all circumstances (periods of low as well as high demand). However, we agreed to launch the planning engine with a manual solution for maintaining business shares. All signs pointed to this being a perfectly fine solution during development and user testing.

Lesson 2: Your product principles are context dependent

In case of significant changes such as market conditions, new principles may need to be adopted, and they may conflict with your original principles.

Historically, the market for inland transportation has proven to be quite volatile, as we have been reminded in many instances over the last few years, though none more severe than the trucking shortage in the UK.

Soon after the team had launched our planning engine for inland transportation, the onset of the trucking shortage meant that business shares quickly became a top priority, and we learned that the manual solution was simply not good enough. Without automatically honouring business shares, users had to manually reassign a significant portion of the jobs. The intended benefit of automatically awarding the job to the best vendor switched to a downside, making it harder for the users to do transportation planning than before the engine was introduced.

What made matters worse was that honouring business shares is in direct violation of our second product principle of minimising cost. In other words, it is simply not mathematically possible to find the overall cheapest solution while also promising to give a certain share of the jobs to a particular vendor no matter the cost.

It should be clear that introducing business shares had the potential to undermine the entire way the planning engine worked, potentially putting us back to square one and having to do it over. An automated solution was required to provide benefits, but it was becoming clear that identifying the principle(s) for reconciling business shares with cost minimisation would not be straightforward.

Lesson 3: Defining product principles are as much a technical concern as a business concern

The engineering team must be involved in defining and iterating product principles, especially for smart products.

Through iterative discussions and proofs of concepts with users, senior functional stakeholders and the engineering team, it was discovered that a solution could be developed which was desirable, viable and feasible. To do so, we needed to introduce a new principle by prioritising business shares ahead of cost minimisation. The new set of product principles became (in prioritised order):

• Deliver the product as sold
• Honor business shares (new)
• Minimize the overall cost of transportation

Another problem that needed to be solved was the daily variation on the actual volume of cargo given to a vendor. Sometimes business shares cannot be met as container numbers would not allow for it. While Maersk and its supplier were in alignment on how to handle these fluctuations, how did the product need to behave to reflect this understanding between them? As part of the business share solution, the engineering team had an answer and created a ’memory mechanism’ to carry over to subsequent days any deviations on business shares due to rounding.

A crucial thing to remember is that all solutions and tweaks to the smart product could be implemented without having to start over from scratch on defining the core logic of the optimization.

Without the technical understanding of the engineering team in the discussions on redefining the principles, it would not have been possible to find a solution that reconciled the previous version of the planning engine with the new principle and thereby allow us to find a solution in the appropriate time. Had the technical voices not been the key stakeholders when redefining the principles, these would have not been vetted with a view to the current solution design; instead, we were able to create co-ownership of the outcomes and develop a solution that did not require a full re-architecting of the advanced mathematics.

There is no doubt that principles in product design define the purpose of a product, allowing it to deliver on clear benefits. However, briefing a developer is paramount too. Thus, product teams need to have an in-depth understanding of the business environment in which the product will function. We need to keep track of market dynamics, be on the lookout for roadblocks, and factor all this information in before we sit down to discuss a product’s principles. Only then can we begin to develop smart products and applications that are as robust and as flexible as logistics solutions need to be today.

Learn more about product engineering and product management at Maersk on our careers pages.