GSE Blog 

Designing, building, and launching products in any industry is perhaps the purest test of a company’s core competencies. With a multitude of factors at play, and an unmistakable talent requirement, innovating for success is a challenge most firms are not equipped to achieve. GSE is a relatively small firm for its industry footprint and reputation, and in its 16-year history, has proven itself on multiple occasions to have the special sauce required to engineer and design for success and growth. With small teams and big brains, GSE manages to stay ahead of its peers by focusing its internal operations on designing for growth.

Expertise is critical

Understanding user trends

GSE’s team of sales professionals, engineers, and senior leadership constantly monitor the market for changes to the behaviors and drivers of purchasing decisions. As those dynamic external levers move, GSE maintains a trend analysis to confirm permanence, and adjusts its product strategies to accommodate as necessary. Most firms require an annual CapEx meeting summary and dozens of follow up meetings just to make a single strategic iteration, and those companies often find themselves designing in a reactionary way. Agility is key when it comes to capitalizing on user trends, and that comes from having a large organization with small, fully autonomous teams, or a smaller company like GSE.

Understanding technology changes

Tools evolve over time, and in a digital era, their power expands at an exponential rate. Incorporating technological changes at the rate at which they occur is a capability reserved almost exclusively for platform products that allow for modular changes. When designing for growth, GSE considers the extent to which a product’s modularity can allow it to incorporate new tools as they become available. GSatTrack is a perfect example of a GSE product that can accommodate new technologies almost immediately, because of the way we’ve built the product to work with new data tools, APIs, hardware devices, and protocols. The GSatMicro Series has an OEM product as well, which gives it the adaptability to be a modular component of a satellite-enabled solution involving other hardware and new technologies as they emerge.

Understanding capability changes

Similar to technology improvements, capability changes represent the changes that occur to technology infrastructure, and how those changes can be incorporated into new and existing products and leveraged for growth. These kinds of changes can be at the component level for hardware devices, such as new modems, stronger cameras, smaller storage, faster processors, and so on. Capability changes can also refer to network improvements, like the 5G rollout for terrestrial networks or the launch of new constellations like Iridium NEXT. Being aware of these changes and how they affect product design decisions is an important part of any company’s ability to design for growth.

Drawing Actionable Insights

Actionable insights are what really separates an innovative organization from a reactive one, and gets to a single question that most companies tend to ignore in their product process:

“What new business opportunities can this trend, new technology, or new capability create?”

This may seem like a question that your business does examine somewhat regularly, but if you’re not asking with the intention of opening new markets, then you’re not designing for growth. Most organizations are revenue-focused, and with good reason, but when they have a new technology or capability, they look only at ways to sell their existing products in their existing markets as new or improved versions of what already exists.

Truly designing for growth means that when a new modem comes out, for example, organizations focus on exploring markets that were previously out of reach due to capabilities. Yes, low hanging fruit is pretty important, and selling a new hardware device to existing markets because it is faster is definitely an effort worth making. Growth, however, comes from exploring the things you can do to your existing product that didn’t previously make sense. For example, maybe previous versions of a piece of hardware didn’t include certain sensors because the modem wasn’t strong enough to send the data it collects, but the new modem makes that a possibility, and there are wide open markets in demand of a product that meets that specification. Designing for growth in that instance would mean using the new modem and also adding I/O ports to the new product to accommodate sensors that were previously left out.

Solving the Problem

Once an organization has actionable insights with regard to trends, new technologies, and new capabilities, the next step in designing for growth is to make sure that the new products or product iteration decisions are actually going to solve a problem that exists in the real world. Solutions in search of problems, or products that exist because they are cool and because they can are very often the ones that lead to disappointing sales figures.

GSE uses a problem-oriented design framework that has been discussed in previous articles and in some of our feature guides. If you have seen this already, please feel free to skip to the next section.

What is Problem-oriented Design?

Problem-oriented Design (POD) places emphasis on users and their specific needs when making UI and UX decisions in product design. Rather than building a solution in search of a problem, the POD framework employs proactive and reactive responses to actual problems in a given market. Anticipation of needs is a critical component of successful POD, but for the majority of POD casework, there is a well-defined problem with a determinate set of solution parameters from which a product manager can construct a strong and well-positioned product or feature.

The process of POD involves identifying the design scenario, which is typically a somewhat niche use case or user demand that has limited available solutions. From this design scenario, a product manager can define the goals of a successful product, and then create the set of product requirements necessary to deliver a working solution. These solution requirements can be any combination of must-have feature functionality, compliance measures, compatibility restrictions, cost considerations, and a multitude of other factors.

Each POD process results in a solution theory and product or feature proposal that includes success benchmarks and performance metrics that can be tested and iterated as necessary. Also included in POD solution theories is a viability assessment that will include analysis of efficiency, effectiveness, and investment requirements. Any product or solution borne of the POD process is one that can be expected to deliver on users’ needs in a way that makes sense and represents a suitable and comprehensive option for solving the design scenario.

Iterating

Gathering data about product usage

The final piece of designing for growth is the understanding that “growth” does not just refer to revenue, sales, and business growth, but rather, that it is actually more about product growth, especially where software is concerned. The only software products that should have “final versions” are perfect products, of which I can think of exactly one: Microsoft Excel. Beyond that, every software product should be iterating constantly, and making changes based on the factors mentioned in the first section of this article. A commitment to doing that, however, requires a strong product design that includes tools to help product managers create strong roadmaps.

Analytics are expensive and important

Building a robust backend to your software product is a daunting and relatively expensive task, because for the most part, backend processes cannot be monetized as part of the product. Their value has to be extracted in other ways, and that means they have to be built in a way that allows them to provide the kind of usage data that leads to the development of better front end experiences and leads to more sales.

Product managers should be able to look at aggregated data about your software product’s usage (like clicks, time spent, and pages viewed) and identify under-used features, over-complicated features, poorly-educated features, or work-arounds that are common. For example, GSE noticed with GSatTrack that many people were running mini reports for periods of asset history and then taking screenshots of the map interface in history mode to send to people. The frequency of these behaviors produced the Shared Views and Journeys features, which allow users to save segments of history as map objects that can be displayed at any time, and Shared Views allow users to send those and anything else they wish to share to people without giving out login information.

For hardware products, iterating means modularity. Instead of adding sensors, add the ports to give users the ability to add the sensors they want and modify their units as needed. Releasing components might not be ideal for every hardware manufacturer, but creating the adapters to work with the best third party components is just as effective and provides a strong commitment to users that the product they buy will still be viable as technology improves.

Designing for growth in your organization

The first step for making an organizational shift to designing for growth is to make sure product teams understand what the goals are, and that they consciously work toward them. Share articles like this one with leadership teams, product teams, and engineers. Develop a culture of innovation, and focus on the ways in which your organization can incorporate new technologies or new capabilities to solve problems you couldn’t previously solve.